京東虛擬業務多維訂單系統架構設計
當年白居易初到長安,拜見大儒顧況,老先生見名曰“長安米貴,居大不易”,當讀到白居易所詩“野火燒不盡,春風吹又生”時不禁贊嘆“有句如此,居天下有甚難”。
京東平臺隸屬虛擬平臺下基礎平臺組研發的公共基礎服務平臺,上承復雜非標品商品模型,下接海量個性化訂單數據,為虛擬平臺內外設計的所有非標準結構商品提供結構個性化定制、發布、促銷、虛擬資產支付、結算、退款及訂單匯聚、流動、統計、展示等豐富解決方案,大大降低了電商行業非標準商品的業務開發復雜度。
本期為大家介紹京東平臺的重要產品之一虛擬訂單中心。
同主站常規實物訂單中心一樣,京東虛擬訂單中心定位于訂單數據的匯聚、變更及狀態維護等,目前已經聚合了手機充值、加油卡、機票酒店、景點門票火車票、點卡頁游等大量虛擬商品和部分非虛擬商品的訂單詳情數據,同時為京東主站訂單中心提供訂單展示,對接風控、營銷等業務方提供訂單數據分析應用等。
虛擬訂單中心的核心功能主要圍繞數據搬運工(Hamal)產品運行, Hamal是京東依托開源項目研發的MySQL數據庫binlog監聽產品,在保證高可用的前提下實現了高指標的監聽轉換過程。
預備小知識1-Binlog
binlog是mysql數據庫開啟Row模式時提供的二進制日志,以binlogEvent形式記錄對數據發生或潛在發生更改(事務開啟)的SQL語句和數據,類似于oracle數據庫的歸檔日志,可以用來查看數據庫的變更歷史、數據庫增量備份和基于時間點的恢復及Mysql的復制等。
預備小知識2-同步監聽原理
簡單說就是模擬mysql的主從復制過程,先偽造成slave向master庫發送COM_REGISTER_SLAVE命令注冊客戶端,這樣master才會發送binlogEvent;接著發送COM_BINLOG_DUMP命令,并指定binlog文件和Position信息,即可從Master庫獲得包含詳細數據的binlogEvent二進制流,binlogEvent包含了所有數據庫的事件類型(DDL、DML、TCL、授權等)、庫表信息、字段信息和行數據,余下的工作經過過濾、解析、協議反序列化得到想要的訂單數據。
COM_BINLOG_DUMP命令格式如下:
- -COM_BINLOG_DUMP
- -4byte binlog-pos
- -2byte flags (BINLOG_DUMP_NON_BLOCK see sql/mysql_priv.h)
- -4byte slave-server-id
- -nul-term binlog name
- DML的binlogEvent類型如下:
- enumLog_event_type {
- /* ...... */
- WRITE_ROWS_EVENT = 23,
- UPDATE_ROWS_EVENT = 24,
- DELETE_ROWS_EVENT = 25,
- INCIDENT_EVENT= 26,
- HEARTBEAT_LOG_EVENT= 27,
- /* ...... */
- };
虛擬訂單中心的主要架構如下:
Hamal作為虛擬訂單中心數據管道的入口,其首要的任務是保證數據庫數據變動的精準消費,因此必須謹慎設計binlog的消費記錄和異常消費后續處理機制等。
健壯性和高可用 Hamal使用zookeeper集群管理監聽實例和記錄binlog的消費位置信息。對于目標庫,多個Hamal實例在啟動時搶占該庫的映射節點以獲取監聽權限,落選的實例則以熱備份形式監聽zk對應節點binlog位置信息,在遭遇服務不可用或宕機時,迅速通過搶占接力監聽服務和binlog信息;Hamal也支持同時監聽目標庫的多個目標從庫,冪等的消費binlog以防止目標庫單節點宕機故障。由此,多重防災機制力保服務的72小時高可用及數據的完備性,目前穩定提供日監聽千萬行記錄,從未拋棄過一條訂單。
快消費
Hamal采用類似TCP滑動窗口的binlogEvent消費的Get和ACK機制:每次接收批量binlog記錄,并行解析數據的變更,發送JMQ消息后確認消費(ACK),以窗口長度作為binlogPosition的增長步調。Hamal通過自產自銷MQ消息方式繼續驅動訂單數據的后續業務處理,后續過程包含數據變更的去重、DML過濾、存儲等,同時也可以為風控、營銷、訂單交易等系統提供個性化數據訂閱服務。這樣即可以解耦binlog消費環節以加速消費,又可以隔離同步監聽服務和業務邏輯。
讀寫分離
Hamal采集的訂單數據轉換成訂單模型后繼續流向虛擬訂單中心的三重存儲介質中:傳統Mysql數據庫作為原始數據的第一重存儲,ES和緩存系統用于數據索引和分析,以實現讀寫分離。存儲訂單數據上,DAO模塊同樣使用消息隊列解耦,訂單數據存儲到數據庫后,以自產自銷JMQ的形式推送訂單數據到ES和緩存系統以輕量化存儲過程,減少多級存儲間耦合又能夠均衡集群負載。
多級搜索
作為數據管道出口,訂單網關系統(GW)對外提供了可定制模版數據或消息數據訂閱、數據分頁查詢、訂單搜索統計等服務,是對接數據應用的關鍵環節。網關系統實現了非常完備且強悍的多級平滑搜索過程,當訂單搜索超時或失敗時立刻跳轉到下級搜索,降級搜索的結果反補上級數據源;如果虛擬訂單中心檢索失敗,搜索會落地到產品線數據庫做最終檢索,檢索成功則會反補該訂單到訂單中心的各級存儲中,檢索失敗則必然是單號有誤;當虛擬訂單服務完全不可用時,網關搜索將直接降級到原產品線生產數據庫拉取訂單數據。多級檢索方案,保證最完善的用戶體驗!
如今,歷經兩次技術版本演進和多次618、雙十一大促考驗的虛擬訂單中心,接入的虛擬業務達30+,穩定承載了虛擬平臺的核心訂單數據,累計訂單數據已近10億,并不斷挑戰新高,正逐漸成為虛擬商品以及其他非標準商品融入京東電商主體系的重要通道。
【本文是51CTO專欄作者“張開濤”的原創文章,作者微信公眾號:開濤的博客( kaitao-1234567)】