오토바이 배달대행/퀵서비스, 화물, 대리, 택시 등 배차순위 해설

• 주의
  이 글에서 쓰이는 수치는 모두 예제
  1초, 0.1초/ 100개, 200개... 이런식은 모두 임의로 하는 얘기임.
• 요약

  시스템상 동시통신은 없다.

  사람 눈으로는 동시로 보여도 모든 게 1:1이다.
  1:1 이기 때문에 플랫폼 서버와 기사간의 통신에서 순서를 어떻게 정할 것인가 하는 문제가 발생한다.

  AI 배차는 지수 순으로

  주문 하나하나마다 거리지수 + 기사지수를 합산하는 연산이 필요하다. 당연히, 이 연산을 거절했을 시 서버의 보복이 있음.

  일반배차는 시간순으로

  그냥 리스트에 쌓인 순서대로 일정 시간마다 보내는 것이라 서버가 신경쓸 것은 넷트웍트래픽.
• 설명
  엄격한 의미의 동시통신이 불가능한 이유
  컴퓨터는 엄밀히 말해 모든 게 시분할이다.진짜로 동시통신 은 없다.
  이더넷이나 IP 공부할 때 나오는 브로드캐스팅이나 멀티캐스팅도 송신 시스템이 특별한 목적지 주소로 한 번 전송한다 뿐이지 일단 전송해 놓으면 중간에 있는 스위칭허브에서 시분할이 일어난다. 즉 24포트 스위칭허브면 허브의 프로세서에서 24번의 패킷복사-포트전송이 일어남.
  이건 ARP 에 쓰이는 맥브로드캐스팅/IP에 쓰이는 IP브로드캐스팅(전자는 항상 쓰이고 후자는 거의 막혀있음)의 예이고 멀티캐스팅은 주소범위가 있으니까 24번은 아니지만 어쨌든. 컴퓨터 전문가 딸배의 포스가 느껴지나?
  
  따라서 서버는 1대고(예제다) 여기에 기사 여럿이 있으면 반드시 대기열이 생기게 마련인데 오더창에 리스트가 쌓이듯 서버의 대기열도 리스트형식으로 버퍼에 쌓이는데.
  예제를 위해 주문은 하나도 없는 상태에서 접속한 기사가 1000명이라(대기열 버퍼에 리스트 1000개) 가정해보자
  
  이 시점에서 서버에 치킨배달 주문이 딱 1개 접수되면
  1000명에게 동시에 주문을 뿌리는 건 불가능하다 했으므로 순서대로 이 주문을 뿌리느냐? 말도 안 되는 소리.
  버퍼는 리스트 개별이 아니라 몇개의 리스트를 묶어서 블럭단위로 처리된다.
  기술적으로 무한루프를 돌면서 1초마다 한 번씩 버퍼를 처리하는 프로세서/스레드가 있는데 이게 한 번에 100개, 200개 등으로 잘라서 처리한다는 말.
  이렇게 되면 1~ 100 번까지 순번에 걸려있던 기사들간의 시간차는 시스템 최대 속도(0.1초도 안 걸림)로 처리되지만 100번 기사와 101번 기사 사이에는 한끗차로 1초의 딜레이가 발생
  그럼 901번째에 줄 서 있는 기사는? 9초 딜레이.
  AI 배차는 이 버퍼 순서를 무시한다.
  당신이 1번에 있든 900번에 있든 지수배차 는 버퍼의 리스트를 기사지수 순위로 재정렬함.
  재정렬한 뒤 블럭단위가 아니라 1번부터 순서대로 1:1로 보내서 1번이 거절치면 2번에 다시 보내고...물론 AI 배차 프로그래밍을 구현한 프로그래머라면 그보다 훨씬 단순한 일반배차도 구현했기 때문에, 예를 들어 재수없게도 1번부터 트라이하는데 10명 20명이 계속 거절을 때리면 어케 할 것이냐...1000명한테 1:1로 트라이를 시도한다면 날밤새겠지?
  따라서 적당히 5명 쯤 트라이해보고 1~5번기사가 다 거절 때리면 이 오더는 일반창에도 보임.
  지수배차에서 오더 들어오면 일명 도한이 라고 부르는 패널티가 있는 이유 이해가 가나?
  1초마다 100개씩 처리하는 건 단순하단 말이야. 그에 반해 1:1로 트라이하고 기사의 승인/거절 을 몇 초간 기다렸다가 거절되면 다시 2번에게 트라이하는 건 서버로서는 부담이 크지. 서버에 주문은 치킨 하나만 있는 게 아니므로 주문 하나 꺼내고 정렬한 뒤 1:1로 보내고 이 짓을 하는 프로세서/스레드 분기가 생기고...따라서 거절때리면 반드시 패널티를 줄 수밖에 없는데 컴퓨터를 모르는 기사들이 거절도 권리인 줄 알고 함부로 남발하니까 알아먹기 쉽게 과도한 이란 패널티로 표현한 것일 뿐
  내부적으로는 훨씬 심각한 기사지수 감점 패널티가 부여됨.
  야! 개소리하지 말라! 그렇게 따지면 난 지금까지 과도한 1000번도 넘게 맞았으니 기사지수 마이너스 백만점이겠네?
  라고 할 사람 있을지 모르겠는데 현재는 이 지수배차가 초기단계라 기사들도 제대로 이해 못하고 다들 고만고만하니까, 즉 전체적으로 다 같이 마이너스를 맞으니까 평균지수가 내려가서 자기에게 쌓이는 패널티를 실감하지 못하는 단계임.
  이걸 실감하지 못하고 있는 기사들이 답답한데 플랫폼에서는 너 지금 몇등이고 몇 점인데 몇 점 까인다!! 하고 대놓고 말은 못 하겠고 정말 짜증나니까 쿠팡은 한 때 계정 정지까지 때렸다면서?
  물론 계정정지까지 나가는 건 엄청난 무리수이고 지수배차의 설계를 벗어나 사람의 입김이 개입했다는 건데 그만큼 답답하다는 거다.
  내가 배민/쿠팡/요기요 프로그래머라면 거절 패널티만큼은 어떤 이벤트로도 복구 안 해줌.
  일반배차에서 미묘한 시간차의 이유
  여기서 일반배차는 배민의 일반배차(몰라, 내가 배민할 때는 모두 일반/추천배차라 모르는데 요즘은 이 창이 따로 있다고 그러네)만을 특정하는 게 아니라 보다 광의의, 지수배차가 아닌 모든 부류, 생각대로/인성퀵 및 그 아류작들...화물/대리/택시 등 모든 플랫폼의 배차시스템을 의미한다.
  
  일반배차에서 100개씩 잘라 처리한다는 예제에서도 당연히 1번과 99번은 아주 미세하나마 약간의 시간차가 존재한다. 동시통신은 절대로 불가 하니까.
  일반배차에서 기사들 대기버퍼는
  
  오더리스트를 요구하는 대기
  특정 오더의 고유ID 를 클릭(오더 찍는)하는 대기
  두가지 유형이 있겠지만 원리는 같으니까 대충 섞어서 얘기하는 게 쉽겠다.
  
  서버가 기사 대기열 버퍼에서 100개를 뽑아왔으면 여기 순서의 초기값은 넷트웍 시간차.
  이 100개를 순서대로 뿌리기 전에.... 정말 아이큐 100인 프로그래머라도 여기서 한 번 정렬을 한다. 해야 정상이다. 어떻게?
  픽업지와의 거리
  
  애초에 1000명 모두를 대상으로 픽업지와의 거리순으로 정렬하면 좋을텐데 왜?...물론 그러면 좋겠지만, 치킨오더 달랑 1개라면 이게 가능하지만 오더가 2개 이상만 되면 뭘 기준으로 가장 가까운 놈부터 정렬해야 하는가 하는 문제가 발생함과 더불어 100명씩 잘라온 것보다 10배의 시스템 부하가 걸리니까 안 됨.
  
  다시 말하지만 그나마 프로그래머라고 부를 정도 되는 한에서
  어떤 픽업지를 기준으로 할 것인가의 문제에서 서버의 오더 리스트 중 가장 접수한 지 오래된(안 빠진 콜) 오더 1개만 가져와서 이걸 기사 100명 리스트에 대고 가장 가까이 있는 놈이 누구인가로 리스트 정렬을 함.
  이건 프로세싱 낭비가 되지만 그만한 의미가 있는 게 안 빠진 오더, 고객으로부터 항의가 올 수 있는 오더는 100명 중 제일 가까이 있는 놈이 잡는 게 그나마 낫거든.
  1000명 모두를 상대로 이렇게 정렬할까? 내가 인성퀵을 관찰한 바로는 안 하는 것 같음.
  사실 실전에서는 1000명이 아니라 리얼 기사가 몇만단위인데 몇만이라도 사실 현대 컴퓨터는 할 수 있다. 문제는 몇만 X 지지기 = 몇십만 단위가 되니까 못하는 것.
  뭐... 몇십만이라도 할 수는 있는데 이 프로세서/스레드만 있는 게 아니니까 제약사항은 분명히 있을테고
  만약 이걸 한다면 1번에 있는 기사와 999번에 있는 기사간의 오더리스트 순번이 바뀔 수 있으니까 지지기의 의미가 줄어듦.(999번이라도 내가 서버의 주문 중 가장 마이너스 걸린 픽업지에서 100번 이내로 가깝기만 하면 100등 안에는 들어감)
  지지기의 의미가 줄어든다 뿐이지 없어지지는 않는다.
  그 이유.
  
  지지기는 이를테면...블랙핑크 콘서트 매표소에 줄서기 알바를 10명 고용해서 한사람을 10명으로 뻥튀기하는 것과 같으므로 1 ~ 1000명의 리스트 안에 같은 사람 10명이 포함되어 있음.
  따라서 10명의 GPS 를 조작한 새로운 유형의 지지기가 활개칠 것.
  앞선 글 지지기의 원리 에서 업자들이 오더리스트 요구를 0.1초마다 보내는 예제를 보였는데 이 경우 1000개의 오더리스트 요구 버퍼 안에 3번에도 내가 있고 110번에도 내가 있고 200번에도 내가 있고... 또 다른 10개의 내 CID 가 꽂혀 있기 때문에 서버가 1초마다 100개씩 잘라서 처리를 해도 지지기가 일반기사를 무조건 이기게 설계되어 있는 것.