訂單中心數據查詢需求分析
還是那句話，任何脫離業務的架構設計都是耍流氓，在進行架構討論之前，首先要對業務進行簡要分析，看看錶結構上有哪些查詢需求。
根據業務經驗，訂單中心往往有以下幾類業務需求：
（1）用戶側，前臺訪問，最典型的有三類需求
訂單實體查詢：通過oid查詢訂單實體，90%都是這種需求。
用戶訂單列表查詢：通過buyer_id分頁查詢用戶歷史訂單列表，9%流量屬於這種需求。
商家訂單列表查詢：通過seller_uid分頁查詢商家歷史訂單列表，1%流量屬於這類需求。
前臺訪問的特點是：吞吐量大，服務要求高可用，對一致性要求較高。其中商家對一致性要求較低，可以接受一定程度的延遲。
（2）運營側，後臺訪問。
根據產品、運營需求，訪問模式各異：按照時間，架構，商品和詳情來進行查詢
後臺訪問的特點：運營側的查詢基本上是批量的分頁查詢，訪問量低，對可用性一致性的要求不高，允許秒甚至十秒級別的查詢延遲。
訂單中心數據查詢需求解決方案-運營側
後臺運營側的查詢需求各異，基本是批量的分頁查詢，計算量和返回數據量較大，比較消耗數據庫性能。
此時如果後臺業務和前臺業務共用一批服務和同一個數據庫。有可能會導致後臺少數幾個請求的批量查詢的低效訪問造成數據庫服務器cpu瞬時100%，影響前臺用戶的正常訪問。
對這一類業務，應該採用“前後臺分離”的架構方案：前臺業務架構不變，站點訪問，服務分層，數據庫水平切分。
訂單中心數據查詢需求解決方案-用戶側
明確了訂單中心的訪問需求後，問題轉化爲，前臺的oid，buyer_id，seller_id如何來進行數據庫的水平切分呢？
需要同時滿足以下條件：
1.根據buyer_uid%n，可以定位到數據庫
2.根據oid%n，可以定位到數據庫
3.根據seller_uid%n，可以定位到數據庫
以上業務是一個
- 1：N（1個買家：N個訂單）和
- N:N（1個買家：N個賣家， 1個賣家：N個買家）的業務場景，
- 對於“多對多”的業務，水平切分應該使用“數據冗餘法”。
訂單中心數據庫切分方法--數據冗餘法
• 當有訂單生成時，通過buyer_uid分庫，oid中融入分庫基因，寫入DB-buyer庫
• 通過線下異步的方式，通過binlog+canal，將數據冗餘到DB-seller庫中
• buyer庫通過buyer_uid分庫，seller庫通過seller_uid分庫，前者滿足oid和buyer_uid的查詢需求，後者滿足seller_uid的查詢需求
爲什麼要冗餘數據？
互聯網數據量很大的業務場景，往往數據庫需要進行水平切分來降低單庫數據量。
水平切分會有一個patitionkey，通過patition key的查詢能夠直接定位到庫，但是非patitionkey上的查詢可能就需要掃描多個庫了。
此時常見的架構設計方案，是使用數據冗餘這種反範式設計來滿足分庫後不同維度的查詢需求。
- 例如：訂單業務，對用戶和商家都有訂單查詢需求：
Order(oid,info_detail);
T(buyer_uid,seller_uid,oid);
如果用buyer_uid來分庫，seller_uid的查詢就需要掃描多庫。
如果用seller_uid來分庫，buyer_uid的查詢就需要掃描多庫。
此時可以使用數據冗餘來分別滿足buyer_uid和seller_uid上的查詢需求：
T1(buyer_uid,seller_uid,oid)
T2(seller_uid,buyer_uid,oid)
同一個數據，冗餘兩份，一份以buyer_uid來分庫，滿足買家的查詢需求；一份以seller_uid來分庫，滿足賣家的查詢需求。
訂單中心數據庫切分方法|如何實現數據冗餘
1.服務同步雙寫
服務同步雙寫，即由服務層同步寫冗餘數據。
流程如圖：
（1）業務應用代用服務層，寫入數據
（2）服務層將數據寫入DB1
（3）服務層將數據寫入DB2
（4）服務層返回新增數據成功給業務應用
- 優點：
- 簡單，服務層由單寫，改爲兩次寫人
- 數據一致性較高，雙寫成功後才返回
- 缺點：
- 因爲由單寫變爲了兩次寫入，請求時間增長
- 數據仍有可能不一致（數據寫入DB1後，服務宕機或重啓，則數據無法寫人DB2）
2.線下異步雙寫
爲了屏蔽“複雜性”，數據雙寫由線下服務或者任務來完成，不再由服務層完成。
流程如圖：
（1）業務應用代用服務層，寫入數據
（2）服務層將數據寫入DB1
（3）服務層返回新增數據成功給業務應用
（4）數據會被寫入到數據庫的log中
（5）線下服務或者任務讀取數據庫log
（6）線下服務或者任務插入T2數據
- 優點：
- 數據雙寫與業務完全解耦
- 請求處理時間短
- 缺點：
- 返回業務新增成功時，會存在一個數據不一致的時間窗口，但能保證最終一致性
- 數據一致性依賴於線下服務或者任務的可凹陷
原文：https://blog.csdn.net/sunhuiliang85/article/details/78418546
參考：https://blog.csdn.net/qq_18145031/article/details/77867853