Didi Taxi, Meituan Crowdsourcing과 유사한 프로젝트를 수행하려면
실제로는 시내 배송이다. 새로운 테이크아웃 주문이 들어오면 실시간으로 주문 장소 근처의 배달 직원에게 푸시되고, 배달 직원은 주문을 받은 후 배달을 해준다.
아주 간단해 보이지만 web开发
어디서부터 시작해야 할지 모르겠습니다.
배달원의 휴대폰
APP
이 서버WebSocket
에 직접 연결되어, 지리적 위치, 경도, 위도가 실시간으로 서버에 업로드됩니다. 위치를 저장(redis/mongodb
)한 후 일정한 주기로 지속적으로 감지합니다. 신규 주문의 경우 신규 주문 근처에 배달원이 있는지 지속적으로 계산하여 해당 배달원에게 푸시합니다.
아이디어는 매우 간단하지만 몇 가지 문제가 있습니다.
여기에는 어떤 지식이 필요한지 모르겠습니다.
배달직원이 어떻게 실시간으로 위치를 파악해서 서버에 전송하는 걸까요?
ajax
와는 다른데 좀 더 안정적으로 만들고 싶어요. . 배달 직원이 항상 자전거를 타고 돌아다닙니다.WebSocket
- 서버에서는 배달원의 위치정보를 저장하기 위해 메모리 데이터를 사용하는데,
는
redis
을 지원하나요? 주문하다.地理位置索引
- 이렇게 하면 데이터가 많이 생성되나요?
가능할까요
内存数据库
1:
, 인메모리 데이터베이스nosql
2: 실시간 통신, 다중 프로세스, 다중 -스레드, 동시성
3:
, 队列
, 定时程序
, 백그라운드 상주 서비스 CLI
4: 공간 인덱스, 공간 계산, 지리적 위치 인덱스 계산
5:
, Socket编程
, 소켓 푸시, Socket通信
H5 Socket
6: APP 개발 중
의 web H5
을 사용할 수 있나요? Socket
만 안정적이면 배달원은 APP
을 사용하지 않아도 됩니다( 아무리 약하게 물어봐도) 한 문장, WebSocket
OK or not) ajax
보충사진(벌새 크라우드소싱/다다배송) :
답글 내용:
Didi Taxi, Meituan Crowdsourcing과 유사한 프로젝트를 수행하려면
실제로는 시내 배송이다. 새로운 테이크아웃 주문이 들어오면 실시간으로 주문 장소 근처의 배달 직원에게 푸시되고, 배달 직원은 주문을 받은 후 배달을 해준다.아주 간단해 보이지만
어디서부터 시작해야 할지 모르겠습니다. web开发
배달원의 휴대폰아이디어는 매우 간단하지만 몇 가지 문제가 있습니다.이 서버
APP
에 직접 연결되어, 지리적 위치, 경도, 위도가 실시간으로 서버에 업로드됩니다. 위치를 저장(WebSocket
)한 후 일정한 주기로 지속적으로 감지합니다. 신규 주문의 경우 신규 주문 근처에 배달원이 있는지 지속적으로 계산하여 해당 배달원에게 푸시합니다.redis/mongodb
- 배달직원이 어떻게 실시간으로 위치를 파악해서 서버에 전송하는 걸까요?
서버에서는 배달원의 위치정보를 저장하기 위해 메모리 데이터를 사용하는데와는 다른데 좀 더 안정적으로 만들고 싶어요. . 배달 직원이 항상 자전거를 타고 돌아다닙니다.
ajax
WebSocket
- 는
이렇게 하면 데이터가 많이 생성되나요?을 지원하나요? 주문하다.
redis
地理位置索引
- 이룰 수 있나요
여기에는 어떤 지식이 필요한지 모르겠습니다.
1: nosql
, 인메모리 데이터베이스
2: 실시간 통신, 다중 프로세스, 다중 -스레드, 동시성
3: 队列
, 定时程序
, CLI
, 백그라운드 상주 서비스
4: 공간 인덱스, 공간 계산, 지리적 위치 인덱스 계산
5: Socket编程
, Socket通信
, 소켓 푸시, H5 Socket
6: APP 개발 중 web H5
의 Socket
을 사용할 수 있나요? APP
만 안정적이면 배달원은 WebSocket
을 사용하지 않아도 됩니다( 아무리 약하게 물어봐도) 한 문장, ajax
OK or not)
경험이 풍부한 전문가들이 나에게 조언을 해주고, 포기하라고 말하지 않았으면 좋겠다. 지식이 이해가 안 될 수도 있지만, 적어도 하나씩 공부해 나가는 것이 좋겠다. 어떤 지식이 필요한지 알 수 있습니다.
보충사진(벌새 크라우드소싱/다다배송) :
모두들 감사합니다^_^
우선 답변에 초대해 주셔서 감사합니다.
이러한 프로젝트에는 서버측, 클라이언트측
클라이언트측
클라이언트가 H5를 사용하는 경우 내장된 웹소켓 대신 소켓.io를 사용하는 것이 좋습니다. 이전 솔루션은 많으며 연결을 끊었다가 다시 연결할 수 있습니다. 프런트엔드에는 별다른 논리가 없습니다. 정기적으로 좌표를 얻은 다음 사람들이 지도에서 이동하는 동안 서버로 이동하는 것 이상입니다.
서버
웹서버
socket.io 서버
웹 서버의 언어는 제한이 없습니다. 웹 서버는 복잡한 계산을 사용하지 않습니다. 웹 서버는 데이터베이스 데이터 표시만 담당합니다.
메시지 큐, 위치 계산 등 많은 양의 계산이 필요하고 백그라운드에 배치되어야 하는 백그라운드 프로그램이 많이 있습니다.
실제로 구현하는 것은 복잡하지 않습니다.
먼저 긴 연결을 설정하고(긴 연결을 설정할 수 있는 한 모든 네트워크 기술, 모든 네트워크 프레임워크가 가능함) 주문이 들어오면 서버가 클라이언트에게 지리적 위치가 전송되었음을 알리는 메시지(지도 API에 따라 획득), 서버는 이를 주문한 고객의 지리적 위치와 비교합니다(지도에서 제공하는 경우 직접 비교할 수 있음). API 비교를 사용할 수 있으며 가장 가까운 사람들 그룹을 선택한 다음 주문을 발송합니다(일반 프로그래밍 논리).
그러면 첫 번째 단계에서는 주문 추적 기능을 구현할 필요가 없으며(즉, 직원의 궤적 데이터를 저장할 필요가 없음) 나중에 주문 추적, 위치 정보를 구현하면 됩니다. 몇 초마다 전송해야 하며(캐싱되거나 지속될 수 있음) 향후 분석에 필요한지 확인하고 원하는 대로 캐싱을 위해 redis 또는 mongodb를 사용할 수 있습니다. 그러면 서버가 위치 정보를 업데이트합니다.
실제로 사용되는 기술을 선택할 수 있습니다. 이제 위치 정보와 위치 비교는 기본적으로 지도의 API를 호출하여 얻을 수 있습니다. 원리를 알고 싶다면 프로젝트 완료 후 직접 조사할 수 있습니다.
논리는 간단하고, 첫 번째 단계에서 사용된 기술은 필터링에 균등하게 사용됩니다. 너무 복잡하게 생각하면 과잉 설계가 됩니다. 금기.