場(chǎng)景
不知道大家看到數(shù)據(jù)一致性梅惯，第一時(shí)間想到的是什么? 我第一時(shí)間想到的是緩存和數(shù)據(jù)庫的一致性，或者是一個(gè)數(shù)據(jù)庫內(nèi)的多個(gè)表的數(shù)據(jù)一致性。
關(guān)于緩存和數(shù)據(jù)庫的一致性大家肯定都已經(jīng)很熟悉了卖擅，無非是先改數(shù)據(jù)庫還是先改緩存，分別會(huì)對(duì)應(yīng)什么樣的問題墨技，我這里便不再一一贅述了惩阶。
同一個(gè)數(shù)據(jù)庫內(nèi)多個(gè)表的一致性也好解決，一般用事務(wù)足以扣汪。
那么這里請(qǐng)大家想一下断楷，一個(gè)調(diào)用鏈路下來，一共十幾個(gè)甚至幾十個(gè)系統(tǒng)崭别，如何保證他們各自系統(tǒng)的數(shù)據(jù)一致性冬筒。如何保證整個(gè)鏈路的連續(xù)性呢。
我舉一個(gè)具體的場(chǎng)景茅主，用戶使用優(yōu)惠券選擇商品下單舞痰。這里面的資金流包括券資產(chǎn)的核銷、用戶實(shí)際的資金從第三方支付渠道比如支付寶诀姚、微信或者銀行卡支付劃撥到平臺(tái)匀奏；用戶確認(rèn)收貨后，資金根據(jù)商品的性質(zhì)劃分到商家学搜、平臺(tái)、推廣傭金等等论衍、用戶方賬單和商家方賬單的更新、對(duì)應(yīng)物理資金的流轉(zhuǎn)，每一步都不能錯(cuò)冠场，即使一分錢對(duì)不上就是資損秆麸、就是事故。
解決方案
數(shù)據(jù)量大了之后蜒蕾，難免會(huì)因?yàn)榫W(wǎng)絡(luò)抖動(dòng)稠炬、數(shù)據(jù)庫抖動(dòng)、云服務(wù)商抖動(dòng)等原因咪啡，導(dǎo)致出現(xiàn)一些異常數(shù)據(jù)首启。這種情況既然無法避免，就要想辦法能及時(shí)快速的排查出來撤摸，確保整個(gè)調(diào)用鏈路的最終一致性毅桃。想達(dá)到這樣的效果褒纲，要怎么做呢？要防止這些小概率事件钥飞，只能多做冗余保護(hù)措施莺掠。
一般分為實(shí)時(shí)核對(duì)和離線核對(duì)兩種思路。
實(shí)時(shí)核對(duì)
目前最常用的數(shù)據(jù)庫當(dāng)屬M(fèi)ySQL读宙，我們便以MySQL為例彻秆。通過監(jiān)聽MySQL產(chǎn)生的binlog，解析出特定類型的DML語句作為觸發(fā)點(diǎn)來進(jìn)行某些操作结闸。比如可以將 DML語句中牽扯到的字段作為參數(shù)來發(fā)送MQ唇兑、調(diào)用RPC由接收方負(fù)責(zé)具體的業(yè)務(wù)核對(duì)邏輯“蚬溃或者將表的關(guān)聯(lián)規(guī)則和具體核對(duì)業(yè)務(wù)規(guī)則都寫在負(fù)責(zé)實(shí)時(shí)核對(duì)的平臺(tái)幔亥，解析出來后由平臺(tái)進(jìn)行統(tǒng)一的核對(duì)操作。 這里推薦一下 Aviator 腳本語言察纯，業(yè)務(wù)用起來很方便帕棉。
離線核對(duì)
為了保證數(shù)據(jù)的準(zhǔn)確性，還可以每日將數(shù)據(jù)庫中的數(shù)據(jù)同步到HBase等離線表中饼记，根據(jù)業(yè)務(wù)需要同步全量或者增量香伴，然后通過寫Hive SQL將多個(gè)離線表Join在一起，核對(duì)數(shù)據(jù)有無缺失具则、不一致即纲。
總結(jié)
凡事必有代價(jià)，技術(shù)方案總有取舍博肋，一般來說在比較重要尤其涉及到錢的部分低斋，會(huì)通過實(shí)時(shí)核對(duì)和離線核對(duì)兩種方案來保證數(shù)據(jù)的一致性，這背后的代價(jià)就是成本匪凡，包括離線表的儲(chǔ)存使用成本膊畴、核對(duì)規(guī)則的編寫成本、數(shù)據(jù)的同步成本等病游。 第一次創(chuàng)作唇跨，文筆略微有點(diǎn)生疏，請(qǐng)大家多多指教衬衬，一起討論有沒有更好的方式买猖。
我是星辰與日暮之間，希望在掘金和大家一起進(jìn)步成長滋尉。
本文由博客一文多發(fā)平臺(tái) OpenWrite 發(fā)布玉控！
