如何搞定分庫後數據冗餘

概述

當單個數據庫數據量達到必定程度後，咱們能夠採用多個從庫解決讀請求的系統瓶頸。 而寫請求的系統瓶頸每每須要經過分庫解決。

問題

以用戶訂單場景爲例，用戶會有查詢訂單需求，因此訂單的分庫須要基於userID作切分。

商家對訂單統計緯度也一樣有需求，因此單一的基於userID作切分的場景不知足這個場景了。

因而咱們須要採用反範式設計來知足兩種場景的需求。 採用兩份數據冗餘，即一份數據基於UserId，一份數據基於PoiId。

數據冗餘實現

既然咱們有了方案，需求指定具體的技術方案了。

作數據冗餘常見有三種方案：

• 應用層同步雙寫。
• 應用層異步雙寫。
• 基於底層中間件數據同步。

應用層異步雙寫

這是最簡單的實現方式，在用戶下單後，基於分庫規則一份請求按userId劃分入庫，一份請求按poiId劃分入庫，數據落庫才進行下一步請求，數據一致性強。

可是整個請求耗時的時間是兩個入庫時間的總和，若是在業務高峯期，每每形成時延升高問題，不適用於對時延敏感的系統。

應用層異步雙寫

將兩個同步入庫修改成異步入庫，採用MQ異步消息投遞方式實現，這樣能夠解決兩次寫入庫帶來的時間損耗，可是會引入MQ中間件，系統複雜度有必定的提高。

既然存在了異步隊列，兩個庫之間存在數據不一致時間窗口，不適用於對數據一致性敏感對系統。

基於底層中間件數據同步

引入數據同步中間件，屏蔽了業務層實現數據同步，數據冗餘的細節，而是交由底層同步中間件實現，使得開發人員專一於業務開發。

與第二種方案相比，中間件方式基於mysql的binlog實現，因此數據一致窗口更短，可靠性更高。

數據一致性

固然以上三種方式的後兩種方式都是異步方式，在分佈式場景下都會存在數據一致性問題，強一致性很難，通常業務系統都採用最終一致性。

爲保證數據一致性能夠採用：異步檢測，異步修復。

異步檢測

採用離線工具，或定時任務，定時對離線數據源進行掃描，如發現數據不一致進行補償修復。

數據源掃描粒度視對一致性要求的強度而定。可是大量的數據掃描，耗時較長，效率較低。

爲下降全量數據掃描的效率問題，能夠設計增量數據掃描方式，設置更適合系統負載的掃描時間窗口，提升掃描檢測效率。

若是想更實時掃描，可引入同步掃描方式，引入MQ推送消息，在訂閱者接收到消息時，觸發數據掃描，掃描時間窗口期內數據，同時進行修正。