firestore에서 실현하는 랜덤 매칭을 생각해 보았다(미실장)

생각해 보았을 뿐입니다만, 만약 의견등 있으면 코멘트 받을 수 있으면 다행입니다! 자신도 정답을 잘 모르기 때문에 논의하고 싶습니다!

전제

1 : 1에서 랜덤 매칭하여 대전 등을 실시하고 싶다

피크시에는 상당히 요청이 튀어 초당 1000 요청이라도 대응하고 싶다

클라이언트는 네이티브 앱

waitingUsers: Collection

documentID

userID로 설정

status: string

대기 상태

WAITING, MATCHED

updatedAt: timestamp

대기 사용자 발판

roomID?: string

참가가 정해진 방의 ID

rooms

userIDs: array

참여할 사용자의 ID

participants: Collection

참여할 클라이언트 목록. 참여하는 사용자가 명시적으로 씁니다.

사실은 순서도로 하고 싶었지만 귀찮았기 때문에 일단 글머리표입니다, 죄송합니다.
PlantUML로 순서도 썼습니다! 우선 글머리 기호도 남겨 둡니다.

매칭을 원하는 사용자는 waitingUsers 에 status = WAITING and updatedAt = now 에 문서를 만들거나 업데이트

사용자는 자신의 문서를 모니터링 (시간 초과 설정 필요)

waitingUsers 의 업데이트를 훅한 CloudFunctions가 기동한다 (어떤 제한 걸리는가…

waitingUsers에서 status == WAITING and updatedAt > 1分前(適当)의 데이터 가져오기

임의의 1건을 얻어온다

transaction에서 다음을 실행

취득한 데이터와 갱신을 훅한 데이터를 getAll한다

각 데이터가 status == WAITING인지 확인

안된다면 3-1.에서 다시 시도

각각 status = MATCHED, roomID = uniqueID 에서 업데이트

/rooms/uniqueID userIDs = [userID1, userID2] 에서 생성

일치하는 사용자는 문서 변경을 받고 roomID를 얻습니다.

room을 얻고 room.participants를 모니터링합니다

room.participants에 자신의 사용자 정보 쓰기

2 명의 파트너가되면 대전 시작

CloudFunctions 호출 수의 상한선에 걸리지 않습니까?

제대로 10명이 WAITING이라면 5조 할 수 있을까(이론상은 괜찮을 것이지만…)

이 문제에 관하여(firestore에서 실현하는 랜덤 매칭을 생각해 보았다(미실장)), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/_mogaming/items/f521d6b27810c2edc3d0

텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.

우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)

개발자 우수 사이트 수집

개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다