建站
咨詢
售后
建站咨詢
新聞中心
本文旨在總結(jié)沉淀工作中問題的解決經(jīng)驗(yàn)，整理解決跨系統(tǒng)數(shù)據(jù)不一致問題的經(jīng)驗(yàn)方法。
創(chuàng)新互聯(lián)主營(yíng)陽春網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,APP應(yīng)用開發(fā),陽春h5微信小程序搭建,陽春網(wǎng)站營(yíng)銷推廣歡迎陽春等地區(qū)企業(yè)咨詢
1、為什么會(huì)有跨系統(tǒng)數(shù)據(jù)一致性問題?
提到數(shù)據(jù)一致性，我們很容易想到的就是數(shù)據(jù)庫(kù)中的事務(wù)操作。
事務(wù)的原子性和持久性可以確保在一個(gè)事務(wù)內(nèi)，操作多條數(shù)據(jù)，要么都成功，要么都失敗。這樣在一個(gè)系統(tǒng)內(nèi)部，我們可以很自然地使用數(shù)據(jù)庫(kù)事務(wù)來保證數(shù)據(jù)一致性。但是在微服務(wù)的今天，一項(xiàng)操作會(huì)涉及到跨多個(gè)系統(tǒng)多個(gè)數(shù)據(jù)庫(kù)的時(shí)候，用單一的數(shù)據(jù)庫(kù)事務(wù)就沒辦法解決了。
另外常見的一種情況就是：存在依賴情況的系統(tǒng)服務(wù)，例如業(yè)務(wù)端與用戶端(業(yè)務(wù)端負(fù)責(zé)生產(chǎn)數(shù)據(jù)，用戶端負(fù)責(zé)展示數(shù)據(jù))，需要數(shù)據(jù)同步來保障跨系統(tǒng)服務(wù)的數(shù)據(jù)一致性，很多時(shí)候采用何種數(shù)據(jù)同步方式，來保障數(shù)據(jù)應(yīng)用的時(shí)效性至關(guān)重要。
2、一致性問題的難點(diǎn)分析
為了更好的描述和理解問題，我們用一個(gè)案例來闡述：
假設(shè)存在訂單系統(tǒng)與庫(kù)存系統(tǒng)，在實(shí)際業(yè)務(wù)中訂單的創(chuàng)建會(huì)伴隨著庫(kù)存的減少。 兩個(gè)系統(tǒng)為微服務(wù)化部署，其應(yīng)用數(shù)據(jù)也存放在獨(dú)立的數(shù)據(jù)庫(kù)中，兩個(gè)系統(tǒng)間通過網(wǎng)絡(luò)進(jìn)行通信。
2.1 CAP原則
CAP 指的是Consistency(一致性)、Availability(可用性)、Partition tolerance(分區(qū)容錯(cuò)性)。
放棄 A (可用性)來保障 CP
具體表現(xiàn)為產(chǎn)生通信故障后，應(yīng)用會(huì)進(jìn)入阻塞狀態(tài)，一直嘗試與庫(kù)存系統(tǒng)恢復(fù)通信直到完成所有數(shù)據(jù)處理。這種方案是優(yōu)先保障數(shù)據(jù)完整性，但此方案用戶體驗(yàn)極差，因?yàn)樵谒胁僮魍瓿汕坝脩魰?huì)一直處于等待的狀態(tài)。
CAP 本身就是互斥的，只能從三者中選兩個(gè)，對(duì)于 CA、AP、CP 都有它們自己的應(yīng)用場(chǎng)景，要結(jié)合實(shí)際進(jìn)行選擇。
- CA 因?yàn)椴豢紤]分區(qū)容忍度，所以它的所有操作需要在同一進(jìn)程內(nèi)完成(也就是我們常說的單體應(yīng)用);
- AP 因?yàn)榉艞墧?shù)據(jù)一致性，適合數(shù)據(jù)要求不高但強(qiáng)調(diào)用戶體驗(yàn)的項(xiàng)目，如博客、新聞資訊等;
- CP 反之放棄了可用性，適合數(shù)據(jù)要求很高的交易系統(tǒng)，如銀行交易、電商的訂單交易等，就算是用戶長(zhǎng)時(shí)間等待，也要保障數(shù)據(jù)的完整可靠。
CAP 原則在實(shí)際項(xiàng)目中的運(yùn)用，對(duì)于互聯(lián)網(wǎng)應(yīng)用來說，如果為了用戶體驗(yàn)完全放棄數(shù)據(jù)一致性這也是不可取的，畢竟數(shù)據(jù)才是應(yīng)用的根本。
那該怎么解決呢?
保障最終一致性的措施有很多，主要包括：分布式事務(wù)和TCC 一致性方案。
MySQL 其實(shí)有一個(gè)兩階段提交的分布式事務(wù)方案(MySQL XA)，但是該方案存在嚴(yán)重的性能問題。
比如，一個(gè)數(shù)據(jù)庫(kù)的事務(wù)與多個(gè)數(shù)據(jù)庫(kù)之間的 XA 事務(wù)性能可能相差 10 倍。另外，在 XA 的事務(wù)處理過程中它會(huì)長(zhǎng)期占用鎖資源，所以一開始我們并不考慮這個(gè)方案。
在此，我們主要討論一下TCC一致性方案。
2.2 TCC 一致性方案
TCC 是一種數(shù)據(jù)一致性方案，我們會(huì)把原來的一個(gè)接口分為三個(gè)接口：
- Try 接口用來檢查數(shù)據(jù)、預(yù)留業(yè)務(wù)資源。
- Confirm 接口用來確認(rèn)實(shí)際業(yè)務(wù)操作、更新業(yè)務(wù)資源。
- Cancel 接口是指釋放 Try 接口中預(yù)留的資源。
在TCC中，它將分布式處理過程分為兩個(gè)階段：
- Try 是第一個(gè)階段，用于嘗試并鎖定資源;
- 如果資源鎖定成功，第二個(gè)階段開始進(jìn)行 Confirm 提交完成數(shù)據(jù)操作;
- 如果資源鎖定失敗，第二個(gè)階段就會(huì)進(jìn)行 Cancel 將數(shù)據(jù)回滾;
TCC 實(shí)施過程中有哪些注意事項(xiàng)呢?
1)在 Try 階段做盡可能多的事情
要把絕大多數(shù)的業(yè)務(wù)邏輯在 Try 階段完成，因?yàn)?TCC 設(shè)計(jì)之初認(rèn)為 Confirm 或 Cancel 是一定要成功的，因此不要二階段包含任何業(yè)務(wù)代碼或者遠(yuǎn)程通信，只通過最簡(jiǎn)單的代碼釋放凍結(jié)資源。
2)保障Confirm 或 Cancel 執(zhí)行成功
假如 Confirm 或 Cancel 執(zhí)行時(shí)出現(xiàn)錯(cuò)誤，那具體應(yīng)用時(shí)也會(huì)不斷重試執(zhí)行操作來盡量保證執(zhí)行成功，這個(gè)過程中可能會(huì)多次執(zhí)行 update 語句，因此要注意代碼的冪等性。
3)Confirm 或 Cancel 執(zhí)行失敗的兜底方案
極小概率下，Confim 或 Cancel 在多次重試后宣告失敗，便會(huì)出現(xiàn)數(shù)據(jù)最終不一致的情況，這就需要自己開發(fā)額外的數(shù)據(jù)完整性校驗(yàn)程序補(bǔ)救或者通過人工進(jìn)行補(bǔ)錄。
TCC 歸根結(jié)底是一種理論設(shè)計(jì)，需要廠商實(shí)現(xiàn)相應(yīng)的框架給予支撐。
在 Java 開源領(lǐng)域著名的 TCC 框架有：ByteTCC、Hmily、Tcc-transaction 與 Seata。
3、有效數(shù)據(jù)同步方案實(shí)踐
問題描述：我們還是以之前的案例場(chǎng)景，數(shù)據(jù)需要從訂單系統(tǒng)同步到庫(kù)存系統(tǒng)中。
解決數(shù)據(jù)一致性常用的三類數(shù)據(jù)同步方案：實(shí)時(shí)同步、定時(shí)同步、手動(dòng)同步。
3.1 實(shí)時(shí)同步
實(shí)時(shí)同步可以從數(shù)據(jù)庫(kù)、應(yīng)用處理兩個(gè)層面來解決。
3.1.1 數(shù)據(jù)庫(kù)層面
通用采用數(shù)據(jù)庫(kù)的數(shù)據(jù)同步，主從解決，當(dāng)master(主)庫(kù)的數(shù)據(jù)發(fā)生變化的時(shí)候，變化會(huì)實(shí)時(shí)的同步到slave(從)庫(kù)。
優(yōu)勢(shì)：
- 水平擴(kuò)展數(shù)據(jù)庫(kù)的負(fù)載能力。
- 容錯(cuò)，高可用，F(xiàn)ailover(失敗切換)/High Availability
- 數(shù)據(jù)備份。
如何實(shí)現(xiàn)主從一致
關(guān)于 MySQL 主從復(fù)制主要同步的是 binlog 日志，涉及到三個(gè)線程，一個(gè)運(yùn)行在主節(jié)點(diǎn)(log dump thread)，其余兩個(gè)(I/O thread, SQL thread)運(yùn)行在從節(jié)點(diǎn)，如下圖所示:
(1)主節(jié)點(diǎn) binary log dump 線程
當(dāng)從節(jié)點(diǎn)連接主節(jié)點(diǎn)時(shí)，主節(jié)點(diǎn)會(huì)創(chuàng)建一個(gè) log dump 線程，用于發(fā)送 binlog 的內(nèi)容。在讀取 binlog 中的操作時(shí)，此線程會(huì)對(duì)主節(jié)點(diǎn)上的 binlog 加鎖，當(dāng)讀取完成，在發(fā)送給從節(jié)點(diǎn)之前，鎖會(huì)被釋放。
(2)從節(jié)點(diǎn) I/O 線程
當(dāng)從節(jié)點(diǎn)上執(zhí)行start slave命令之后，從節(jié)點(diǎn)會(huì)創(chuàng)建一個(gè) I/O 線程用來連接主節(jié)點(diǎn)，請(qǐng)求主庫(kù)中更新的 binlog。I/O 線程接收到主節(jié)點(diǎn) binlog dump 進(jìn)程發(fā)來的更新之后，保存在本地 relay-log(中繼日志)中。
(3)從節(jié)點(diǎn) SQL 線程
SQL 線程負(fù)責(zé)讀取 relay log 中的內(nèi)容，解析成具體的操作并執(zhí)行，最終保證主從數(shù)據(jù)的一致性。
3.1.2 API調(diào)用
一次業(yè)務(wù)數(shù)據(jù)操作，需要調(diào)用多方API實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)的同步。
劣勢(shì)比較明顯，主要表現(xiàn)在：
1)處理耗時(shí)長(zhǎng)，需要串行調(diào)用多方API并等待響應(yīng)，用戶體驗(yàn)較差;
2)會(huì)有一定幾率出現(xiàn)數(shù)據(jù)不一致情況(個(gè)別API調(diào)用出錯(cuò)、未響應(yīng)等情況)。
3.2 異步同步
3.2.1 異步消息隊(duì)列
Message Queue(MQ)，消息隊(duì)列中間件。
MQ 通過將消息的發(fā)送和接收分離來實(shí)現(xiàn)應(yīng)用程序的異步和解偶，同時(shí)MQ屏蔽底層復(fù)雜的通訊協(xié)議，定義了一套應(yīng)用層的、更加簡(jiǎn)單的通訊協(xié)議。
應(yīng)用MQ的優(yōu)點(diǎn)：解耦，削峰，數(shù)據(jù)分發(fā)。
在業(yè)務(wù)系統(tǒng)設(shè)計(jì)中，我們常常會(huì)存在一個(gè)平臺(tái)系統(tǒng) A，它關(guān)聯(lián)同步了許許多多的系統(tǒng)的對(duì)接(系統(tǒng)B、C、D等)。
利用MQ可以很好的解決系統(tǒng)對(duì)接和數(shù)據(jù)同步問題，同時(shí)可以忽略對(duì)接系統(tǒng)的穩(wěn)定性等訴求。
3.2.2 定時(shí)同步
定時(shí)任務(wù)在系統(tǒng)中并不少見，主要目的是用于需要定時(shí)處理數(shù)據(jù)或者執(zhí)行某個(gè)操作的情況下，如定時(shí)關(guān)閉訂單，或者定時(shí)備份。
常見的定時(shí)任務(wù)分為2種：
1)第一種：固定時(shí)間執(zhí)行，保障同步并校準(zhǔn)數(shù)據(jù)
如：每分鐘執(zhí)行一次，每天執(zhí)行一次。
2)第二種：延時(shí)多久執(zhí)行，即動(dòng)作發(fā)生后，定時(shí)多久后執(zhí)行任務(wù)
如：15分鐘后關(guān)閉訂單付款狀態(tài)，24小時(shí)候后關(guān)閉訂單并且釋放庫(kù)存等。
3.3 手動(dòng)同步
在一般數(shù)據(jù)管理中，在具備了上述實(shí)時(shí)同步和異步同步的情況下，為了防止其他異常情況造成的數(shù)據(jù)不一致，可以考慮開發(fā)備用數(shù)據(jù)同步工具(腳本)來手動(dòng)方式主動(dòng)進(jìn)行恢復(fù)，將數(shù)據(jù)同步并進(jìn)行校準(zhǔn)。
其優(yōu)劣也很明顯，優(yōu)勢(shì)：隨時(shí)隨地主動(dòng)操作;劣勢(shì)：需要人工進(jìn)行干預(yù)。
數(shù)據(jù)同步最好的情況是能夠?qū)崿F(xiàn)實(shí)時(shí)同步，但是考慮到數(shù)據(jù)同步過程中對(duì)系統(tǒng)的壓力以及數(shù)據(jù)實(shí)時(shí)同步的必要性等因素有時(shí)會(huì)選擇定時(shí)同步和手動(dòng)同步。
4、應(yīng)用經(jīng)驗(yàn)總結(jié)
技術(shù)還是要解決實(shí)際問題來落地。應(yīng)用場(chǎng)景很關(guān)鍵，不要單純?yōu)榱思夹g(shù)而技術(shù)，技術(shù)歸根結(jié)底還是為應(yīng)用場(chǎng)景和產(chǎn)業(yè)落地服務(wù)。 軟件設(shè)計(jì)過程中，不需要刻意去應(yīng)用看起來高大上的解決方案，而當(dāng)需要引入時(shí)，要同時(shí)考慮開發(fā)、維護(hù)成本以及對(duì)應(yīng)性能的提升的性價(jià)比，否則得不償失。
（1）任何架構(gòu)方案都是不斷演進(jìn)的
任何數(shù)據(jù)同步本身沒有優(yōu)劣之分，都有其適合的應(yīng)用場(chǎng)景。
（2）架構(gòu)的目的是解決業(yè)務(wù)問題
能夠解決當(dāng)前問題的架構(gòu)方案，同時(shí)兼具易于擴(kuò)展及維護(hù)，那就是一個(gè)優(yōu)秀的架構(gòu)。
隨著互聯(lián)網(wǎng)的告訴發(fā)展，跨系統(tǒng)數(shù)據(jù)一致性應(yīng)用需求一定會(huì)越來越迫切，跨地域跨系統(tǒng)場(chǎng)景的真正痛點(diǎn)也會(huì)越來越清晰，希望我們?cè)诳缦到y(tǒng)數(shù)據(jù)一致性方面的調(diào)研和探索可以給大家一個(gè)思路和參考。
分享標(biāo)題：跨系統(tǒng)數(shù)據(jù)一致性問題經(jīng)驗(yàn)實(shí)戰(zhàn)
文章網(wǎng)址：http://www.dlmjj.cn/article/dpiegdg.html
