解密「達達-京東到家」的訂單即時派發技術原理和實踐
本文由達達京東到家Java工程師季炳坤原創分享。php
一、前言
達達-京東到家做爲優秀的即時配送物流平臺，實現了多渠道的訂單配送，包括外賣平臺的餐飲訂單、新零售的生鮮訂單、知名商戶的優質訂單等。爲了提高平臺的用戶粘性，咱們須要兼顧商戶和騎士的各自願景：商戶但願訂單可以準時送達，騎士但願能夠高效搶單。那麼在合適的時候提高訂單定製化的曝光率，是及時送物流平臺的核心競爭力之一。html
本文將描述「達達-京東到家」的訂單即時派發系統從無到有的系統演進過程，以及方案設計的關鍵要點，但願能爲你們在解決相關業務場景上提供一個案例參考。java
關於「達達-京東到家」：android
達達-京東到家，是同城速遞信息服務平臺和無界零售即時消費平臺。達達-京東到家創始人兼首席執行官蒯佳祺；redis
公司旗下，目前已覆蓋全國400 多個主要城市，服務超過120萬商家用戶和超 5000萬我的用戶；算法
2018年8月，達達-京東到家正式宣佈完成最新一輪5億美圓融資，投資方分別爲沃爾瑪和京東。數據庫
（本文同步發佈於：http://www.52im.net/thread-1928-1-1.html）api
二、關於做者
季炳坤：「達達-京東到家」Java工程師，負責「達達-京東到家」的訂單派發、訂單權限、合併訂單等相關技術工做的實現。數組
三、訂單即時派發架構的演進
在公司發展的初期，咱們的外賣訂單從商戶發單以後直接出如今搶單池中，3千米以內的騎士可以看到訂單，而且從訂單卡片中獲取配送地址、配送時效等關鍵信息。這種暴力的顯示模式，很容易形成騎士挑選有利於自身的訂單進行配送，從而致使部分訂單超時未被配送。這樣的模式，在必定程度上致使了商戶的流失，同時也浪費了騎士的配送時間。緩存
從上面的場景能夠看出來，咱們系統中缺乏一個訂單核心調度者。有一種方案是選擇區域訂單的訂單調度員，由調度員根據騎士的接單狀況、配送時間、訂單擠壓等實時狀況來進行訂單調度。這種模式，看似可行，可是人力成本投入過高，且比較依賴我的的經驗總結。
核心問題已經出來了：我的的經驗總結會是什麼呢?
1） 騎士正在配送的訂單的數量，是否已經飽和；
2） 騎士的配送習慣是什麼；
3） 某一階段的訂單是否順路，騎士是否能夠一塊兒配送；
4） 騎士到店駐留時間的預估；
5） ...
理清核心問題的答案，咱們的系統派單便成爲了可能。
基於以上的原理，訂單派發模式就能夠逐漸從搶單池的訂單顯示演變成系統派單：
咱們將會：
1）記錄商戶發單行爲；
2）騎士配送日誌及運行軌跡等信息。
而且通過數據挖掘和數據分析：
1）獲取騎士的畫像；
2）騎士配送時間的預估；
3）騎士到店駐留時間的預估等基礎信息；
4）使用遺傳算法規劃出最優的配送路徑；
5）...
通過上述一系列算法，咱們將在騎士池中匹配出最合適的騎士，進而使用長鏈接（Netty）不間斷的通知到騎士。
隨着達達業務的不斷迭代，訂單配送逐漸孵化出基於大商戶的駐店模式：基於商戶維護一批固定的專屬騎士，訂單隻會在運力不足的時候纔會外發到搶單池中，正常狀況使用派單模式通知騎士。
四、訂單派發模型的方案選型
訂單派發能夠淺顯的認爲是一種信息流的推薦。在訂單進入搶單池以前，咱們會根據每一個城市的調度狀況，先進行輪詢N次的派單。
大概的表現形式以下圖：
舉例：有筆訂單須要進行推送，在推送過程當中，咱們暫且假設一直沒有騎士接單，那麼這筆訂單會每間隔N秒便會進行一次普通推薦，而後進入搶單池。
從訂單派發的流程週期上能夠看出來，派發模型充斥着大量的延遲任務，只要能解決訂單在何時能夠進行派發，那麼整個系統 50% 的功能點就能迎刃而解。
咱們先了解一下經典的延遲方案，請繼續往下讀。。。
4.1 方案1：數據庫輪詢
經過一個線程定時的掃描數據庫，獲取到須要派單的訂單信息。
優勢：開發簡單，結合quartz便可以知足分佈式掃描；
缺點：對數據庫服務器壓力大,不利於項目後續發展。
4.2 方案2：JDK的延遲隊列 - DelayQueue
DelayQueue是Delayed元素的一個無界阻塞隊列，只有在延遲期滿時才能從中提取元素。隊列中對象的順序按到期時間進行排序。
優勢：開發簡單，效率高，任務觸發時間延遲低；
缺點：服務器重啓後，數據會丟失，要知足高可用場景，須要hook線程二次開發；宕機的擔心；若是數據量暴增，也會引發OOM的狀況產生。
4.3 方案3：時間輪 - TimingWheel
時間輪的結構原理很簡單，它是一個存儲定時任務的環形隊列，底層是由數組實現，而數組中的每一個元素均可以存放一個定時任務列表。列表中的每一項都表示一個事件操做單元，當時間指針指向對應的時間格的時候，該列表中的全部任務都會被執行。 時間輪由多個時間格組成，每一個時間格表明着當前實踐論的跨度，用tickMs表明；時間輪的個數是固定的，用wheelSize表明。
整個時間輪的跨度用interval表明，那麼指針轉了一圈的時間爲：
interval = tickMs * wheelSize
若是tickMs=1ms，wheelSize=20，那麼便能計算出此時的時間是以20ms爲一轉動週期，時間指針（currentTime）指向wheelSize=0的數據槽，此時有5ms延遲的任務插入了wheelSize=5的時間格。隨着時間的不斷推移，指針currentTime不斷向前推動，過了5ms以後，當到達時間格5時，就須要將時間格5所對應的任務作相應的到期操做。
若是此時有個定時爲180ms的任務該如何處理？很直觀的思路是直接擴充wheelSize？這樣會致使wheelSize的擴充會隨着業務的發展而不斷擴張，這樣會使時間輪佔用很大的內存空間，致使效率低下，所以便衍生出了層級時間輪的數據結構。
180ms的任務會升級到第二層時間輪中，最終被插入到第二層時間輪中時間格#8所對應的TimerTaskList中。若是此時又有一個定時爲600ms的任務，那麼顯然第二層時間輪也沒法知足條件，因此又升級到第三層時間輪中，最終被插入到第三層時間輪中時間格#1的TimerTaskList中。注意到在到期時間在[400ms,800ms)區間的多個任務（好比446ms、455ms以及473ms的定時任務）都會被放入到第三層時間輪的時間格#1中，時間格#1對應的TimerTaskList的超時時間爲400ms。
隨着時間輪的轉動，當TimerTaskList到期時，本來定時爲450ms的任務還剩下50ms的時間，還不能執行這個任務的到期操做。便會有個時間輪降級的操做，會將這個剩餘時間50ms的定時任務從新提交到下一層級的時間輪中，因此該任務被放到第二層時間輪到期時間爲 [40ms,60ms) 的時間格中。再經歷了40ms以後，此時這個任務又被觸發到，不過還剩餘10ms，仍是不能當即執行到期操做。因此還要再一次的降級，此任務會被添加到第一層時間輪到期時間爲[10ms,11ms)的時間格中，以後再經歷10ms後，此任務真正到期，最終執行相應的到期操做。
優勢：效率高，可靠性高(Netty,Kafka,Akka均有使用)，便於開發；
缺點：數據存儲在內存中，須要本身實現持久化的方案來實現高可用。
五、訂單派發方案的具體實現
結合了上述的三種方案，最後決定使用redis做爲數據存儲，使用timingWhell做爲時間的推進者。這樣即可以將定時任務的存儲和時間推進進行解耦，依賴Redis的AOF機制，也不用過於擔憂訂單數據的丟失。
kafka中爲了處理成千上萬的延時任務選擇了多層時間輪的設計，咱們從業務角度和開發難度上作了取捨，只選擇設計單層的時間輪即可以知足需求。
1）時間格和緩存的映射維護：
假設當前時間currentTime爲11:49:50，訂單派發時間dispatchTime爲11:49:57，那麼時間輪的時間格#7中會設置一個哨兵節點（做爲是否有數據存儲在redis的依據 ）用來表示該時間段是否會時間事件觸發，同時會將這份數據放入到緩存中（key=dispatchTime+ip）, 當7秒事後，觸發了該時間段的數據，便會從redis中獲取數據，異步執行相應的業務邏輯。最後，防止因爲重啓等一些操做致使數據的丟失，哨兵節點的維護也會在緩存中維護一份數據，在重啓的時候從新讀取。
2）緩存的key統一加上IP標識：
因爲咱們的時間調度器是依附於自身系統的，經過將緩存的key統一加上IP的標識，這樣就能夠保證各臺服務器消費屬於自身的數據，從而防止分佈式環境下的併發問題，也能夠減輕遍歷整個列表帶來的時間損耗（時間複雜度爲O(N)）。
3）使用異步線程處理時間格中對應的數據：
使用異步線程，是考慮到若是上一個節點發生異常或者超時等狀況，會延誤下一秒的操做，若是使用異常能夠改善調度的即時性問題。
咱們在設計系統的時候，系統的完善度和業務的知足度是互相關聯影響的，單從上述的設計看，是會有些問題的，好比使用IP做爲緩存的key，若是集羣發生變動便會致使數據不會被消費；使用線程池異步處理也有機率致使數據不會被消費。這些不會被消費的數據會進入到搶單池中。從派單場景的需求來看，這些場景是能夠被接受的，固然了，咱們系統會有腳原本進行按期的篩選，將那些進入搶單池的訂單進行再次派單。
* 思考：爲何不使用ScheduledThreadPoolExecutor來定時輪詢redis?
緣由是即使這樣能夠完成業務上的需求，獲取定時觸發的任務，可是帶來的空查詢不但會拉高服務的CPU，redis的QPS也會被拉高，可能會致使redis的慢查詢會顯著增多。
六、結語
咱們在完成一個功能的時候，每每須要一些可視化的數據來肯定業務發展的正確性。所以咱們在開發的時候，也相應的記錄了一些訂單與騎士的交互動做。從天天的報表數據能夠看出來，90% 以上的訂單是經過派單發出而且被騎士承認接單。
訂單派發的模式是提高訂單曝光率有效的技術手段，咱們一直結合大數據、人工智能等技術手段但願能更好的作好訂單派發，能提供更加多元化的功能，將達達打形成更加一流的配送平臺。
附錄：更多相關技術文章
《iOS的推送服務APNs詳解：設計思路、技術原理及缺陷等》
《信鴿團隊原創：一塊兒走過 iOS10 上消息推送(APNS)的坑》
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
《一個基於MQTT通訊協議的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三種方案的優劣》
《掃盲貼：淺談iOS和Android後臺實時消息推送的原理和區別》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《爲什麼微信、QQ這樣的IM工具不使用GCM服務推送消息？》
《從HTTP到MQTT：一個基於位置服務的APP數據通訊實踐概述》
《基於WebSocket實現Hybrid移動應用的消息推送實踐(含代碼示例)》
《Go語言構建千萬級在線的高併發消息推送系統實踐(來自360公司)》
《瞭解iOS消息推送一文就夠：史上最全iOS Push技術詳解》
《基於APNs最新HTTP/2接口實現iOS的高性能消息推送(服務端篇)》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-1928-1-1.html）
- 1. 解密「達達-京東到家」的訂單即時派發技術原理和實踐
- 2. 京東技術解密
- 3. 京東訂單
- 4. 面試之滿幫與達達京東到家（未完全解析）
- 5. 《京東技術解密》讀後感
- 6. Redis在京東到家的訂單中的使用
- 7. 京東資深架構強勢推薦：京東技術解密
- 8. 劉彥偉_京東實時數據平臺技術實踐
- 9. 仿京東的購物車和訂單
- 10. 仿京東訂單Deom
- 更多相關文章...
- • 數據庫涉及到哪些技術？ - MySQL教程
- • Hibernate的快照技術 - Hibernate教程
- • TiDB 在摩拜單車在線數據業務的應用和實踐
- • ☆技術問答集錦（13）Java Instrument原理
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 解密「達達-京東到家」的訂單即時派發技術原理和實踐
- 2. 京東技術解密
- 3. 京東訂單
- 4. 面試之滿幫與達達京東到家（未完全解析）
- 5. 《京東技術解密》讀後感
- 6. Redis在京東到家的訂單中的使用
- 7. 京東資深架構強勢推薦：京東技術解密
- 8. 劉彥偉_京東實時數據平臺技術實踐
- 9. 仿京東的購物車和訂單
- 10. 仿京東訂單Deom