起源

在進行架構(gòu)轉(zhuǎn)型與分庫分表之前，我們一直采用非常典型的單體應(yīng)用架構(gòu)：主服務(wù)是一個 Java WebApp，使用 Nginx 并選擇 Session Sticky 分發(fā)策略做負(fù)載均衡和會話保持；背后是一個 MySQL 主實例，接了若干 Slave 做讀寫分離。在整個轉(zhuǎn)型開始之前，我們就知道這會是一塊難啃的硬骨頭：我們要在全線業(yè)務(wù)飛速地擴張迭代的同時完成架構(gòu)轉(zhuǎn)型，因為這是實實在在的”給高速行駛的汽車換輪胎”。

為了最大限度地減少服務(wù)拆分與分庫分表給業(yè)務(wù)帶來的影響（不影響業(yè)務(wù)開發(fā)也是架構(gòu)轉(zhuǎn)型的前提），我們采用了一種溫和的漸進式拆分方案：

• 對于每塊需要拆分的領(lǐng)域，首先拆分出子服務(wù)，并將所有該領(lǐng)域的數(shù)據(jù)庫操作封裝為 RPC 接口；

• 將其它所有服務(wù)中對該領(lǐng)域數(shù)據(jù)表的操作替換為 RPC 調(diào)用；

• 拆分該領(lǐng)域的數(shù)據(jù)表，使用數(shù)據(jù)同步保證舊庫中的表與新表數(shù)據(jù)一致；

• 將該子服務(wù)中的數(shù)據(jù)庫操作逐步遷移到新表，分批上線；

• 全部遷移完成后，切斷同步，該服務(wù)拆分結(jié)束。

這種方案能夠做到平滑遷移，但其中卻有幾個棘手的問題：

• 舊表新表的數(shù)據(jù)一致性如何保證？

• 如何支持異構(gòu)遷移？（由于舊表的設(shè)計往往非常范式化，因此拆分后的新表會增加很多來自其它表的冗余列）

• 如何保證數(shù)據(jù)同步的實時性？（往往會先遷移讀操作到新表，這時就要求舊表的寫操作必須準(zhǔn)實時地同步到新表）

典型的解決方

總結(jié)

以上是生活随笔為你收集整理的基于 Kafka 与 Debezium 构建实时数据同步的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。