db에서 두개를 다른사람에게 빼앗기지 않고 픽하고 싶습니다. (내용 수정 - 1)

Question

롤이라고 가정해보겠습니다. 매치 메이킹을 만드는거죠.게임 시작을 누르고 기다리면 사용자 10명을 묶어서 하나의 게임을 만듭니다.이를 절차적으로 나열하면게임준비를 누름서버의 대기열에 들어감대기열에 등록된 사람을 조건에 따라서 10명 선택모두에게 수락여부를 요청일정시간동안 대기를 하며 10명 모두 수락하는지 확인이런식으로 이루어집니다.그런데 10명만 게임을 찾지는 않겠지요? 100명이 게임을 하려고 하면 10명씩 묶어 최대 10개의 게임이 만들어져야 합니다.대기열DB에 100명이 들어있습니다.게임A를 만들기 위해 유저ㄱ의 정보를 select하고 적합해서 이 사람은 '게임중입니다'로 update를 하려합니다.그런데 select 해서 검사하는 사이에 게임B에서도 게임 D에서도 이 유저ㄱ가 적합하다며 '게임중입니다' 라는 update를 날립니다.최종적으로는 마지막에 업데이트한 D가 이 사람을 가져가겠지요.update 후에 다시 select해서 검사를 하거나 해서 다시뽑기를 반복하다보면 제대로 되긴 하겠습니다만... 저런 상황을 회피할 수 있는 솔루션이 있을까요?로직으로 스텝바이 스텝으로 검사를 할까요?서버가 존재해서 전체 큐를 가진 상태에서 게임 하나를 뽑아서 10명에 대하여 update 한 뒤 처리가 끝나면 다음것을 뽑아 처리하는 식으로 만든다면 간단하겠지만중앙 서버 없이 유저 요청시마다 검사를 1회 수행하는식으로 개별 로직을 유저별로 독립적으로 처리되고 그렇다 보니 1회의 사이클 중에도 중간중간 변경이 발생할 가능성이 생깁니다.예시로 든 롤은 10명 규모지만 제가 하려는 부분은 대기열의 1000명 중 2명을 뽑은 뒤 다른쪽에 빼앗기지 않도록만 하면 되는 훨씬 작은 규모기는 한데요...특정 소프트웨어의 기능적 해결 방안이든 로직적 해결법이든 괜찮으니 알려주세요.현재 db는 mongodb입니다.

basscraft · Answer

이정도 설명으로는 원하시는 바를 정확히 이해하기가 어렵네요요건을 듣고 잠깐 드는 생각은...대기자 목록을 꼭 DB에 해야 하는가? -> redis 같은 메모리 DB를 이용하는 것은 어떨지?주기적으로 요청을 받아서 두명씩 반환 하는 것을 비즈니스 로직으로 요청자 , 매치자를 구분해서 조회 하는 것은 어떨지?요청자, 매치자 역시 메모리에 올려서 관리 하는 것은 어떨지?간단하지 않은 로직을 몇줄의 설명으로 이해하기는 어렵네요우선 로직 플로우를 잘 그려 보시고 거기에 필요한 객체를 먼저 그려 보시고. 어떻게 저장할 지 ...하나씩 풀어 나가시길...건투를 빕니다.

장독깨기 · Answer

저도 이해가 잘 안 가네요. ㅎ사용자 입장에서 사용 시나리오를 한 번 설명 해보세요.

요리조리이리 · Answer

낙관적/비관적 Lock에 대해서 고민하시는듯 합니다.아래 링크를 참고로, 관련된 정보를 찾아보시고 작성자분의 시스템 상황에 맞는 방식을 적용하시면 됩니다. https://sabarada.tistory.com/175

호필이 · Answer

SQL FOR UPDATE 한번 찾아보세용~

더미 · Answer

mq를 써보시죠

db에서 두개를 다른사람에게 빼앗기지 않고 픽하고 싶습니다. (내용 수정 - 1)

5개의 답변

기술 목록