數據備份之后實時性如何保證
在建立數據中台的時候，數據還是來源於各個異構的業務應用系統，實現了數據的統一，但是數據實際上是多存了一份，數據存在冗余，同時數據實時性如何來保證了？針對每個業務系統都開發數據提取接口？
數據備份的通用處理方式
能用數據層的binlog方式就用，要不就業務層拉數據，不過如果可以的話，都可以針對各個數據存儲開發類似binlog的東西。
其實，這個是三個問題。
第一，數據平台類似於數倉，一般就是基於binlog去同步的，異構數據庫可以了解下阿里雲的dts，支持多個數據庫的解析。
第二，數據同步肯定存在時延，跨數據中心的同步正常情況下在幾十毫秒左右，那么對於一些資金類的就要注意了，有些業務需要對數據強一致有要求，就只能讀主庫。
第三，數據提取接口不現實，比如rpc超時，消息消費失敗都是需要考慮的，所以最后還是做到業務無侵入性。
數據強一致場景怎么搞
阿里在處理強一致場景下也是按照讀寫主庫的方式處理的嗎？這樣的話數據庫資源需要能承載所有的請求流量？
看場景，不考慮微服務之間的強一致性的前提下。我們就探討時延導致的主從一致性。
比如，異地多活，整個鏈路調用都是單元化，那么就不會有問題，因為整個流量都在一個機房讀寫。如果上游單元化，下游沒有單元化，這種情況，就需要所有流量走中心機房，所有讀強制走主庫。如果不考慮異地多活，只有一個機房，按照讀寫主庫的方式處理。
比如訂單支付或者庫存這種場景，如果做了單元化之后，面對高並發場景時可能會通過緩存對DB進行一定的保護，但是引入緩存之后可能造成緩存和DB數據不一致的情況，由於系統業務對於強一致有要求所以是不是可以讀寫完全落到DB，這樣DB就需要承載所有的流量（不能靠緩存了），不知道支付寶oceanbase是不是通過強一致方式實現了這種思路，或者說這種思路是在阿里所有部門采用的通用強一致方案。
京東的搞法
我的項目是京東自己的彈性數據庫，因為數據量大采用分庫分表和讀寫分離。但是對於實時要求高的，查詢立馬更新狀態的，目前依然是只能讀寫主庫。
因為主從同步的數據時延隨着你的訪問量越大，時延越高。如果只是為了查詢實時數據的話，可以向梁老師說的那樣，通過binlog異步獲取數據最終狀態。
但是之后數據量繼續增加實時查詢QPS達到很高狀態，比如15k的話，那么原來16核的配置就需要繼續升級配置或者不再使用mysql數據庫。這樣場景應該也很少吧。
美團的搞法
我們目前的處理方式類似 因為對於一致性有一定的要求 采用單元化+分庫方式搞相當於都是主讀主寫，隨着流量越來越大，資源申請也變得越來越多。
所以在考慮有沒有可替代的方案（Mysql資源有限啊），公司在考慮自研類oceanbase的分布式一致性數據庫，但是可用時間還比較遠。
阿里的搞法
說說我的場景，也是依然是只能讀寫主庫。例如，我們的自動化退款業務，基於強規則的，這個時候匹配可以退款出賬，但是如果出現時延，可能下一秒就不匹配了，這種情況時延可能就有資損風險。
整體的業務場景。就是上游有退款的業務平台，是具體的資金出賬業務，然后買家發起退款的時候會先過我們服務的一層規則引擎和風控系統，這個時候所有匹配的數據都需要強時效。
應該是定時任務需要同時判斷多個庫的數據，才能判定能不能執行動作並且要及時。但是為了減輕主庫壓力，就得讀從庫。從庫又是存在延時的。所以強迫讀主庫了。
壓力大時，其實應該用實時流，更為合適。
大概想到具體的業務場景了。 就是比如退款這種業務 發貨的商品是不能直接退款的，假如用戶發起退款申請的時候去查訂單是否發貨。此時剛好發貨寫入了主庫，還沒有同步到從庫的時候如果查從庫就會有問題。 應該是類似這種業務場景吧 。
總結
雖然面對三高系統的設計我們可以找到很多文章和思路進行佐證，但是在真正的業務實踐過程中還是需要做好取舍和依據業務場景個性化設計。
面對高並發場景下，同時對於強一致性有要求的業務場景，目前業界主流互聯網阿里，美團，京東公司的搞法都差不多，還是主寫主讀來面對因為地域，多機房，主從等同步帶來的延遲，除非具有螞蟻金服一樣的研發能力自研分布式強一致的OceanBase，否則一般還是在mysql分庫角度做文章。
更多細節歡迎關注【春哥叨叨】，更多真實架構案例分享：
