考えてみただけなのですが、もしご意見等あればコメントいただけると幸いです!自分も正解がよくわからないので議論したいです!
前提
- 1:1でランダムマッチングして対戦等を行いたい
- ピーク時は結構リクエストが跳ねて、秒間1000リクエストとかでも対応したい
- クライアントはネイティブアプリ
テーブル
- waitingUsers: Collection
- documentID
- userIDにする
- status: string
- 待機状況
- WAITING, MATCHED
- updatedAt: timestamp
- 待機ユーザーの足切り用
- roomID?: string
- 参加が決まった部屋のID
- documentID
- rooms
- userIDs: array
- 参加するユーザーのID
- participants: Collection
- 参加するクライアント一覧。参加するユーザーが明示的に書き込む。
- userIDs: array
シーケンス
本当はシーケンス図にしたかったんですが面倒だったので一旦箇条書きです、すみません。
PlantUMLでシーケンス図書きました!とりあえず箇条書きも残しておきます。
- マッチングを望むユーザーは
waitingUsers
にstatus = WAITING and updatedAt = now
でドキュメントを作成または更新 - ユーザーは自身のドキュメントを監視(タイムアウトの設定は必要)
-
waitingUsers
の更新をフックしたCloudFunctionsが起動する(なんかの制限引っかかるか…?) - waitingUsersから
status == WAITING and updatedAt > 1分前(適当)
のデータを取得(limitいる気がする) - ランダムな1件を取得してくる
- transactionで下記を実行
- 取得したデータと更新をフックしたデータをgetAllする
- 各データが
status == WAITING
であることをチェック- だめだったら3−1.からやりなおし
- それぞれ
status = MATCHED, roomID = uniqueID
で更新 - /rooms/uniqueIDの
userIDs = [userID1, userID2]
で作成
- マッチングしたユーザーはドキュメントの変更を受け取って、roomIDを取得する
- roomを取得して、room.participantsを監視
- room.participantsに自身のユーザー情報を書き込む
- participantsが2名になったら対戦スタート
懸念点
- CloudFunctionsの呼び出し数上限とかに引っかからないか?
- ちゃんと10人がWAITINGだったら5組できるのか(理論上は大丈夫なはずだが…)