起源

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

為了最大限度地減少服務拆分與分庫分表給業務帶來的影響（不影響業務開發也是架構轉型的前提），我們采用了一種溫和的漸進式拆分方案：

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

• 將其它所有服務中對該領域數據表的操作替換為 RPC 調用；

• 拆分該領域的數據表，使用數據同步保證舊庫中的表與新表數據一致；

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

• 全部遷移完成后，切斷同步，該服務拆分結束。

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

• 舊表新表的數據一致性如何保證？

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

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

典型的解決方

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。