Matching login

문제

• 라이더와 드라이버의 매칭

조건

• GraphQL Subscription의 pub,sub을 이용할 수 있다.

문제상황 1

한명의 라이더로 부터 온 요청을 여러명의 드라이버가 동시에 승인한 경우 동기화 문제가 발생한다.(운행정보에 여러 드라이버가 접근하여 발생하는 문제)

해결 과정 1

• 모든 드라이버가 matching(매칭 정보에 관한) subscription을 subscribe 해서 라이더가 드라이버 매칭에 성공하면 matching subscription에 드라이버 ID와 라이더 ID를 publish 한다.
• 모든 드라이버가 matching 을 subscribe하지 말고 accept 한 드라이버만 matching을 subscribe하고, DB에서 운행정보를 한번 더 확인하면 될 것같다.

추가 문제

다음 드라이버들 중 3번 드라이버가 문제가 된다. matching이 끝나고 승인요청을 한 드라이버의 경우 드라이버와 라이더ID를 publish를 받지 못하기 때문이다.

1. 승인 버튼을 클릭한 드라이버
2. 그 이후 조금 늦게 들어온 드라이버
3. 완전 마지막에 승인요청을 누른 드라이버

해결 과정 2

• 그렇다면 운행정보의 상태(open,closed,matched)를 db와 메모리에 저장해서 publish 대신 운행정보를 직접 확인한다. -> ...운행정보를 어떤 타이밍에 저장할까.
• 먼저 라이더가 호출 할 때 driverId를 비운채로 open된 상태의 운행을 write하고(저장 데이터 field: riderId, 출발지, 목적지, 운행 상태)
• 드라이버의 승인메세지를 받고,라이더가 해당 드라이버에 대한 승인을 하면서 운행의 상태를 matched로 업데이트하고, driverId를 넣어준다.

DB에 저장할 운행정보의 현재상태 -> open(매칭이 이루어지기 전의 상태) -> matched(드라이버와 라이더의 매칭이 이루어졌을 때) -> cancel(라이더가 드라이버와의 매칭을 취소했을 때) -> onBoard(드라이버가 탑승버튼을 눌렀을 때) -> closed(드라이버가 하차버튼을 눌렀을 때)

최종 해결책

총 두번에 걸쳐 해결한다.

• 라이더가 확정된 드라이버의 ID를 드라이버 전체에게 publish하여 드라이버 가 매칭된 드라이버를 확인할 수 있도록 한다.
• 운행정보에 상태 값을 넣어서 각 드라이버가 상태를 확인하여, open된 운행만 승인할 수 있도록 한다.

---

문제상황 2

위치기반으로 드라이버를 호출하는 방법에 대하여

해결과정

• 드라이버 현재 위치를 지속적으로 db에 저장한다. 드라이버들의 위치를 지속적으로 db에 업데이트하는 것은 이상하지 않는가?

최종 해결책

아림: callRequest subscription에 라이더가 자신의 위치를 publish를하면 subscribe중인 드라이버들이 해당 pub의 라이더 위치가 자신의 위치와 가까운지 판별하여 호출을 받는다.

변경사항

위치정보 공유를 위하여 두번의 subscription을 사용하는것이 부자연스러워, 멘토님의 조언에 따라 db에 드라이버 위치정보를 저장(mutation)하고, 해당 위치정보를 기반으로 callRequst하기로 했습니다.

---

문제 상황 1의 해결책은, 여러명의 라이더가 한명의 드라이버에게 요청을 보낸 경우를 처리하기 어렵다. 한 명의 드라이버에게 여러명의 라이더가 요청을 보낸 경우에 두가지 문제가 발생한다. 해당 문제상황은 다음과 같다.

문제상황 3: db통신으로 인한 딜레이(동기화) 문제

db통신의 딜레이 때문에 운행 상태를 놓칠 수 있다.

문제상황 4: 한 명의 드라이버에 대한 여러 개의 알림처리 문제.

publish마다 알림을 띄우면, 첫번째 라이더를 놓치고 5초마다 띄우면 두번째 라이더를 놓친다. 알림요청의 큐를 만들어도 요청의 상태를 확인할 수 없다.

그렇기에 라이더가 드라이버 한 명에게 요청을 보내고 5 초 뒤에 다른 드라이버에게 요청을 보내는 방식(이후 1대1매칭)을 사용하는 것이 적합하지 않냐는 의견이 나왔다.

• '1대1매칭'으로 해결이 가능해 보였지만, 문제 4번의 상황을 해결하기 위해 매칭 요청의 상태를 관리하면, 다시 3번의 문제가 발생한다.

최종 해결책

• 드라이버 클라이언트에서는 그냥 현재 드라이버의 상태를 확인하여 요청의 승인여부를 publish한다. 그러면 db를 조회하지 않고, 문제상황3을 해결 가능하다.
• 라이더의 요청과 동시에 근처 드라이버의 배열을 만들고, 해당 배열이 빌 때 까지 요청을 보낸다.

라이더배열 드라이버 후보군이 같다 라이더 1번의 요청이 먼저 갔다. 요청이 갔을 때 드라이버의 상태를 바꾼다(팝업 여부) 라이더 2번이 드라이버 1번에게 요청이 간다면, 드라이버가 팝업상태이면 다른 섭스크립션에 난 못받는다는 pub을 보낸다.