資料備份之後實時性如何保證

在建立資料中臺的時候，資料還是來源於各個異構的業務應用系統，實現了資料的統一，但是資料實際上是多存了一份，資料存在冗餘，同時資料實時性如何來保證了？針對每個業務系統都開發資料提取介面？

資料備份的通用處理方式

能用資料層的binlog方式就用，要不就業務層拉資料，不過如果可以的話，都可以針對各個資料儲存開發類似binlog的東西。

其實，這個是三個問題。

第一，資料平臺類似於數倉，一般就是基於binlog去同步的，異構資料庫可以瞭解下阿里雲的dts，支援多個數據庫的解析。

第二，資料同步肯定存在時延，跨資料中心的同步正常情況下在幾十毫秒左右，那麼對於一些資金類的就要注意了，有些業務需要對資料強一致有要求，就只能讀主庫。

第三，資料提取介面不現實，比如rpc超時，訊息消費失敗都是需要考慮的，所以最後還是做到業務無侵入性。

資料強一致場景怎麼搞

阿里在處理強一致場景下也是按照讀寫主庫的方式處理的嗎？這樣的話資料庫資源需要能承載所有的請求流量？

看場景，不考慮微服務之間的強一致性的前提下。我們就探討時延導致的主從一致性。

比如，異地多活，整個鏈路呼叫都是單元化，那麼就不會有問題，因為整個流量都在一個機房讀寫。如果上游單元化，下游沒有單元化，這種情況，就需要所有流量走中心機房，所有讀強制走主庫。如果不考慮異地多活，只有一個機房，按照讀寫主庫的方式處理。

比如訂單支付或者庫存這種場景，如果做了單元化之後，面對高併發場景時可能會通過快取對DB進行一定的保護，但是引入快取之後可能造成快取和DB資料不一致的情況，由於系統業務對於強一致有要求所以是不是可以讀寫完全落到DB，這樣DB就需要承載所有的流量（不能靠快取了），不知道支付寶oceanbase是不是通過強一致方式實現了這種思路，或者說這種思路是在阿里所有部門採用的通用強一致方案。

京東的搞法

我的專案是京東自己的彈性資料庫，因為資料量大采用分庫分表和讀寫分離。但是對於實時要求高的，查詢立馬更新狀態的，目前依然是隻能讀寫主庫。

因為主從同步的資料時延隨著你的訪問量越大，時延越高。如果只是為了查詢實時資料的話，可以向樑老師說的那樣，通過binlog非同步獲取資料最終狀態。

但是之後資料量繼續增加實時查詢QPS達到很高狀態，比如15k的話，那麼原來16核的配置就需要繼續升級配置或者不再使用mysql資料庫。這樣場景應該也很少吧。

美團的搞法

我們目前的處理方式類似 因為對於一致性有一定的要求 採用單元化+分庫方式搞相當於都是主讀主寫，隨著流量越來越大，資源申請也變得越來越多。

所以在考慮有沒有可替代的方案（Mysql資源有限啊），公司在考慮自研類oceanbase的分散式一致性資料庫，但是可用時間還比較遠。

阿里的搞法

說說我的場景，也是依然是隻能讀寫主庫。例如，我們的自動化退款業務，基於強規則的，這個時候匹配可以退款出賬，但是如果出現時延，可能下一秒就不匹配了，這種情況時延可能就有資損風險。

整體的業務場景。就是上游有退款的業務平臺，是具體的資金出賬業務，然後買家發起退款的時候會先過我們服務的一層規則引擎和風控系統，這個時候所有匹配的資料都需要強時效。

應該是定時任務需要同時判斷多個庫的資料，才能判定能不能執行動作並且要及時。但是為了減輕主庫壓力，就得讀從庫。從庫又是存在延時的。所以強迫讀主庫了。

壓力大時，其實應該用實時流，更為合適。

大概想到具體的業務場景了。 就是比如退款這種業務 發貨的商品是不能直接退款的，假如使用者發起退款申請的時候去查訂單是否發貨。此時剛好發貨寫入了主庫，還沒有同步到從庫的時候如果查從庫就會有問題。 應該是類似這種業務場景吧 。

總結

雖然面對三高系統的設計我們可以找到很多文章和思路進行佐證，但是在真正的業務實踐過程中還是需要做好取捨和依據業務場景個性化設計。

面對高併發場景下，同時對於強一致性有要求的業務場景，目前業界主流網際網路阿里，美團，京東公司的搞法都差不多，還是主寫主讀來面對因為地域，多機房，主從等同步帶來的延遲，除非具有螞蟻金服一樣的研發能力自研分散式強一致的OceanBase，否則一般還是在mysql分庫角度做文章。

更多細節歡迎關注【春哥叨叨】，更多真實架構案例分享：

相關推薦