電商中台訂單整合

標籤：commerce   ordermanagement   

概述:

核心技術要求：不丟單，分布式訂單抓取

訂單下拉技術選擇，推送還是抓取？目前採取定時抓取的方式，抓取的方式更加合理，因為可以控制訂單流入的速度，防止超出後台系統的處理能力.  一般採取按時間分區的方法: 每次任務執行抓取一個時間段內的訂單，為了保證訂單不丟失，我們會讓每個時間片邊界有幾秒的重疊.

作為訂單中台，往往會從多個平台抓取訂單， 那麼我們可以考慮分配多個伺服器來完成訂單抓取任務，來提高輸送量，對於訂單多的平台，我們可以多分配多台伺服器，對於訂單少的平台，一台伺服器可以處理多個平台的訂單，如何高效地調度任務是一個挑戰. 尤其是當多台伺服器對應一個平台的時候，我們需要每台伺服器並行地抓取不同時間段的訂單（訂單的順序）做到不重複遺漏. 一種做法是分配一台伺服器做任務調度，那麼這台伺服器可能會成為單點瓶頸，一旦這台伺服器宕機，整個抓取進程就會停滯. 更好的做法是讓多台伺服器通過ZOOKEEPER自行協商，決定每台伺服器應該分配的時間段.

組態管理:

目前採用ZOOKEEPER做訂單抓取的組態管理. 對於組態管理，ZOOKEEPER最大的優勢是可以集中管理配置資訊，並且當配置資訊有更改的時候，所有的節點都能自動監聽到並保持一致.  目前對於所有的配置選項都支援兩級的組態管理，所有平台可以共用配置（平台編號=default） 或者針對某個平台個人化（覆蓋 預設值）

組態管理ZOOKEEPER資料結構：

ZOOKEEPER路徑	ZOOKEEPER資料	節點類型
/tasks/cfg/starttime/[平台編號]	每個平台訂單抓取任務的開始時間（精確到秒），比如抓取最近3個月的訂單，那開始時間是目前時間-3個月	PERSISTENT
/tasks/cfg/interval/[平台編號]	每個平台訂單抓取任務的時間片長度（秒數）	PERSISTENT
/tasks/cfg/timeout/[平台編號]	每個平台訂單抓取任務的逾時時間	PERSISTENT
/tasks/cfg/retries/[平台編號]	每個平台訂單抓取任務的重試次數	PERSISTENT
/tasks/cfg/retryintv/[平台編號]	每個平台訂單抓取任務出錯每次重試的間隔時間	PERSISTENT
/tasks/cfg/taskpernode/[平台編號]	每個平台訂單抓取任務在每個節點上並行線程數量	PERSISTENT
/schedulers/assignment/[平台編號]/[伺服器節點編號]	Null 字元串	EPHEMERAL

註：目前伺服器和平台的對應無法智能地自動分配，需要在啟動伺服器前手工在ZOOKEEPER中建立

任務調度演算法:

節點間通過ZOOKEEPER協調, ZOOKEEPER的資料結構如下

ZOOKEEPER路徑	ZOOKEEPER資料	節點類型
/tasks/runtime/prevcomplete/[平台編號]	任務最新執行時間片的開始時間	PERSISTENT
/tasks/runtime/inprogress/[平台編號]-[任務時間片開始]-[任務時間片結束]	實際任務的開始執行時間	PERSISTENT

  擷取任務:

1. 從ZOOKEEPER中擷取最近的執行時間/tasks/runtime/prevcomplete/， 如果最近的執行時間為空白就擷取開始時間

2. 根據時間片算出下次的執行時間

3. 儲存下次執行時間片的起始和結束時間/tasks/runtime/inprogress/  和當前平台任務新的開始時間. 注意：這裡採用了ZOOKEEPER的MULTI命令 保證兩次儲存為原子性操作（同時成功或失敗）當兩個不同的節點同時試圖擷取同一時間片時，只有第一個會儲存成功，第二個會拋出KEEPEREXCEPTION.

4. 如果儲存失敗則重新擷取最近的執行時間（重複步驟1-3），重複N次後如仍然不成功則返回擷取抓取任務失敗

  任務完成:

1. 刪除ZOOKEEPER中的任務/tasks/runtime/inprogress/

異常處理:

每次抓取任務失敗會重試一定次數 (/tasks/cfg/retries), 每次重試的間隔時間會逐漸增大（重試次數* [/tasks/cfg/retryintv]），避免頻繁重試使網路狀況進一步惡化，當重試次數超過限定時則將任務放入一個失敗隊列並通知管理員，可能需要排查原因並後續人工處理.

另外一種情況是任務擷取後在處理過程中由於伺服器宕機，抓取線程崩潰等原因導致不能刪除/tasks/runtime/inprogress/，即任務並未完成而處理狀態未知. 叢集中需要通過ZOOKEEPER選舉出一個LEADER伺服器來監控工作清單（關於ZOOKEEPER LEADER選舉在官方的RECEIPE中有詳細描述，這裡就不再贅述）, LEADER中的監控線程處於活躍狀態並定期掃描所有 /tasks/runtime/inprogress/節點下的任務，如果任務存在的時間超過一個閥值，就將任務刪除，同樣放入失敗隊列待後續處理

電商中台訂單整合