https://tech.youzan.com/trade_manage/

有贊訂單管理主要承接有贊所有訂單搜索及詳情展示功能，系統(tǒng)隨著業(yè)務(wù)的不斷發(fā)展經(jīng)歷了多次飛升之路。下面簡單介紹下有贊訂單管理系統(tǒng)的三生三世與“十面埋伏”。

第一世：凡人飛升小仙之路-分庫分表

隨著業(yè)務(wù)發(fā)展，單庫單表所能承載的數(shù)據(jù)量局限性越發(fā)嚴(yán)重。?
歷劫：單庫單表數(shù)據(jù)量承載局限?
渡劫：分庫分表?
分庫分表的維度針對系統(tǒng)買賣家查詢的需求，分片鍵為買家id和店鋪id，其余訂單擴(kuò)展信息表屬于數(shù)據(jù)組裝信息，均以店鋪id為分片鍵。?
結(jié)果：分庫分表后，數(shù)據(jù)業(yè)務(wù)量的承載質(zhì)的提升。

第二世：小仙飛升上仙之路-引入ES搜索引擎

隨著業(yè)務(wù)搜索維度的不斷添加，使得跨表查詢需求越來越多，系統(tǒng)的慢查不斷報出，為此引入了ES搜索引擎。?
歷劫：跨表查詢越來越多，系統(tǒng)慢查頻頻報出渡劫：引入ES搜索引擎?
ElasticSearch是一個基于Lucene的搜索服務(wù)器,這里主要是通過將訂單主表及輔表的索引字段同步到ES里，這些每張表單獨(dú)的索引字段，匯總成一個聯(lián)合索引，來實(shí)現(xiàn)多個表的跨表搜索。?
結(jié)果：目前運(yùn)行良好，統(tǒng)計(jì)的檢索需求響應(yīng)時間均值20ms以內(nèi)，對于命中緩存的在1ms以內(nèi)返回。由于多表聯(lián)查的流量都進(jìn)了ES,所以系統(tǒng)慢查被清0。

兩個問題需要注意下：?
1.?單Type與多Type的選擇?
ES里使用文檔存儲，一個Index可以理解為一個庫，一個Type可以理解為一張表，那么訂單及其擴(kuò)展信息面臨使用單Type還是多Type的抉擇。?
多Type優(yōu)點(diǎn)： 可以做到索引字段與表結(jié)構(gòu)一一對應(yīng), 數(shù)據(jù)同步隔離單一，直觀簡單。?
多Type缺點(diǎn)：獲取數(shù)據(jù)時候需要一次數(shù)據(jù)聚合，比如一次跨5張表索引聯(lián)查，需要先分別取出5張表的數(shù)據(jù)，然后做一次交集。性能會有影響。類似于DB的跨表聯(lián)查，而且當(dāng)數(shù)據(jù)做冷熱隔離，數(shù)據(jù)拆分時候，多Type的拆分和維護(hù)成本反而更高。?
單Type優(yōu)點(diǎn)：可以做到數(shù)據(jù)一次請求即可將目標(biāo)信息全量返回，一個Type的數(shù)據(jù)拆分冷熱隔離維護(hù)成本可控。?
單Type缺點(diǎn)：數(shù)據(jù)同步成本高一些，要做好數(shù)據(jù)聚合一致性問題。 結(jié)合業(yè)務(wù)需求場景，這里采用的單Type方案。如下圖所示。

2.索引字段數(shù)量控制?
由于訂單及其擴(kuò)展信息字段較多，將這些信息全量同步到ES會導(dǎo)致索引字段過多，索引文件也會隨之過大，檢索效率會受到影響。所以這里采用了將訂單及其擴(kuò)展信息中強(qiáng)搜索需求的索引字段同步了進(jìn)來，并沒有做全量所有字段同步。

第三世：上仙飛升上神之路-引入Hbase

隨著業(yè)務(wù)的不斷發(fā)展，對系統(tǒng)性能的要求的不斷提高，我們發(fā)現(xiàn)雖然數(shù)據(jù)檢索的效率很高，但是數(shù)據(jù)組裝的效率令人擔(dān)憂，由于需要從ES中獲取的訂單號列表到各個擴(kuò)展表去獲取具體信息，也就是一次完整的訂單列表拉取時間=數(shù)據(jù)檢索時間+數(shù)據(jù)組裝時間，而數(shù)據(jù)組裝就算是批量獲取，也要去取N（假如有N張訂單擴(kuò)展表）次，即使并行去取也不夠高效，上文討論過沒有將訂單的所有信息全部同步到ES的原因，這樣一次完整的訂單拉取時間=數(shù)據(jù)檢索時間。?
歷劫：數(shù)據(jù)組裝效率低下渡劫：引入Hbase來為詳情數(shù)據(jù)組裝 Hbase是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng)。可以通過MapReduce來處理HBase中的海量數(shù)據(jù)。?
這里將訂單基本信息及其強(qiáng)依賴的擴(kuò)展信息全量導(dǎo)入Hbase，其中歷史數(shù)據(jù)采用BulkLoad導(dǎo)入，增量數(shù)據(jù)采用消息同步寫入，以訂單號為rowKey為訂單號，這樣通過一次請求，將該訂單的基本信息及擴(kuò)展信息一次性取出。結(jié)果：訂單管理架構(gòu)被抽象成了DB+ES+HBASE的三層架構(gòu)(如下圖所示)，DB作為數(shù)據(jù)寫入源頭，ES負(fù)責(zé)搜索請求的parser解析及基本數(shù)據(jù)返回（即Es返回字段即可滿足需求的場景），而Hbase作為訂單詳情詳細(xì)信息的組裝載體，兩者配合提升整個訂單列表搜索和詳情組裝的性能。同時Hbase的數(shù)據(jù)源也可以被復(fù)用到訂單導(dǎo)出，數(shù)據(jù)統(tǒng)計(jì)等離線需求上。

寫到這里可能很多朋友都看出，實(shí)現(xiàn)這一切還有一個非常重要的劫需要去渡。那就是數(shù)據(jù)同步的實(shí)時性和一致性。感興趣的話后續(xù)文章可以重點(diǎn)寫寫數(shù)據(jù)同步以及踩過的坑和破局之道，這里簡單拋磚引玉下。

歷劫：數(shù)據(jù)同步的實(shí)時性與一致性?
渡劫：鏈路白盒+冪等性保障?
1. 鏈路白盒：整個同步鏈路是先監(jiān)聽binlog然后同步到消息隊(duì)列中，業(yè)務(wù)消費(fèi)處理同步到Es和Hbase，可以將整個同步鏈路監(jiān)控起來，比如一個消息binlogTime->addMqTime->processTime->addEsOrHbaseTime,這個差值其實(shí)就是實(shí)時性的一個指標(biāo)。一旦整個同步鏈路的白盒搭建好，那么對應(yīng)的報警監(jiān)控，失敗重試補(bǔ)償就都可以跟進(jìn)配套完成。保證數(shù)據(jù)的完整性與實(shí)時性。同步鏈路及同步監(jiān)控如下圖所示。?

2.冪等性保障：如果不能保證業(yè)務(wù)消費(fèi)的冪等性，那么消息的亂序，數(shù)據(jù)的重放監(jiān)控補(bǔ)償?shù)鹊染蜁鼙粍印＿@里簡單提供幾種冪等思路：

• 業(yè)務(wù)樂觀鎖字段：比如訂單狀態(tài)的流轉(zhuǎn)，應(yīng)該是一個正向更新，即后一次更新的state一定大于等于前一次。
• version字段：表設(shè)計(jì)時候留一個version字段，每次數(shù)據(jù)庫更新都會將該字段加1，作為樂觀鎖依據(jù)。
• sonwflake算法：可以根據(jù)業(yè)務(wù)需要定制自己的snowflake算法，比如毫秒級時間戳+binlog變更自增號
• 消息有序：對于一些強(qiáng)依賴消息有序或者業(yè)務(wù)樂觀鎖不好設(shè)定時候，消息端的有序變得尤為重要，可以給根據(jù)業(yè)務(wù)唯一鍵（如訂單號）進(jìn)行機(jī)器取模，保證同一筆訂單的變更數(shù)據(jù)會被推送到同一臺機(jī)器上消費(fèi)。 其中業(yè)務(wù)樂觀鎖使用簡單高效，無需額外存儲樂觀鎖字段，而消息強(qiáng)有序每次需要使用取模計(jì)算，性能多少會有些影響，不過經(jīng)過壓測數(shù)據(jù)顯示性能差別不大，這邊采用業(yè)務(wù)樂觀鎖+消息有序共用的方案。目前線上運(yùn)行良好。

簡單回顧了下有贊訂單管理的“飛升之路”，至于是不是上神，還有待進(jìn)一步考驗(yàn)，后面會重點(diǎn)發(fā)力在配置化編程，系統(tǒng)白盒監(jiān)控最大化及系統(tǒng)性能的不斷提升上.

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9239097.html

總結(jié)

以上是生活随笔為你收集整理的有赞订单管理的三生三世与“十面埋伏”的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。