支付類系統數據處理和數據中臺的數據處理方式有什麼不一樣？

數據備份以後實時性如何保證

在創建數據中臺的時候，數據仍是來源於各個異構的業務應用系統，實現了數據的統一，可是數據其實是多存了一份，數據存在冗餘，同時數據實時性如何來保證了？針對每一個業務系統都開發數據提取接口？

數據備份的通用處理方式

能用數據層的binlog方式就用，要不就業務層拉數據，不過若是能夠的話，均可以針對各個數據存儲開發相似binlog的東西。

其實，這個是三個問題。

第一，數據平臺相似於數倉，通常就是基於binlog去同步的，異構數據庫能夠了解下阿里雲的dts，支持多個數據庫的解析。

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

第三，數據提取接口不現實，好比rpc超時，消息消費失敗都是須要考慮的，因此最後仍是作到業務無侵入性。

數據強一致場景怎麼搞

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

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

好比，異地多活，整個鏈路調用都是單元化，那麼就不會有問題，由於整個流量都在一個機房讀寫。若是上游單元化，下游沒有單元化，這種狀況，就須要全部流量走中心機房，全部讀強制走主庫。若是不考慮異地多活，只有一個機房，按照讀寫主庫的方式處理。

好比訂單支付或者庫存這種場景，若是作了單元化以後，面對高併發場景時可能會經過緩存對DB進行必定的保護，可是引入緩存以後可能形成緩存和DB數據不一致的狀況，因爲系統業務對於強一致有要求因此是否是能夠讀寫徹底落到DB，這樣DB就須要承載全部的流量（不能靠緩存了），不知道支付寶oceanbase是否是經過強一致方式實現了這種思路，或者說這種思路是在阿里全部部門採用的通用強一致方案。

京東的搞法

個人項目是京東本身的彈性數據庫，由於數據量大采用分庫分表和讀寫分離。可是對於實時要求高的，查詢立馬更新狀態的，目前依然是隻能讀寫主庫。

由於主從同步的數據時延隨着你的訪問量越大，時延越高。若是隻是爲了查詢實時數據的話，能夠向梁老師說的那樣，經過binlog異步獲取數據最終狀態。

可是以後數據量繼續增長實時查詢QPS達到很高狀態，好比15k的話，那麼原來16核的配置就須要繼續升級配置或者再也不使用mysql數據庫。這樣場景應該也不多吧。

美團的搞法

咱們目前的處理方式相似 由於對於一致性有必定的要求 採用單元化+分庫方式搞至關於都是主讀主寫，隨着流量愈來愈大，資源申請也變得愈來愈多。

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

阿里的搞法

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

總體的業務場景。就是上游有退款的業務平臺，是具體的資金出帳業務，而後買家發起退款的時候會先過咱們服務的一層規則引擎和風控系統，這個時候全部匹配的數據都須要強時效。

應該是定時任務須要同時判斷多個庫的數據，才能斷定能不能執行動做而且要及時。可是爲了減輕主庫壓力，就得讀從庫。從庫又是存在延時的。因此強迫讀主庫了。

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

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

總結

雖然面對三高系統的設計咱們能夠找到不少文章和思路進行佐證，可是在真正的業務實踐過程當中仍是須要作好取捨和依據業務場景個性化設計。

面對高併發場景下，同時對於強一致性有要求的業務場景，目前業界主流互聯網阿里，美團，京東公司的搞法都差很少，仍是主寫主讀來面對由於地域，多機房，主從等同步帶來的延遲，除非具備螞蟻金服同樣的研發能力自研分佈式強一致的OceanBase，不然通常仍是在mysql分庫角度作文章。

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