簡介： 本文介紹了雙寫場景的一致性問題，詳細介紹了三種解决方案，並針對DB->Binlog->Kafka方案給出了Lindorm數據訂閱的最佳實踐。
雙寫問題介紹
雙寫問題（Dual Write Problem）是指：需要同時修改兩個獨立系統的場景，比如Database和Kafka，再比如Database和緩存，那麼如何保障兩個系統的數據一致性？
以Database和Kafka這種常見的場景為例，我們可以有這麼幾種方式：
- 並發寫Database和Kafka
- 先寫Kafka，再寫Database
- 先寫Database，再寫Kafka
並發寫Database和Kafka
這種情况下需要分布式事務來支持强一致，否則不一致的情况就會比較複雜，Database和Kafka可能沒有一個有完整的數據。
先寫Kafka，再寫Database
先寫Kafka，成功後即可返回客戶端成功，然後訂閱Kafka消息入庫Database，實現最終一致性。但這種异步化導致DB的數據更新延遲，會影響一些要求强一致讀的場景。比如賬單寫入成功，但客戶不能立即查看；再比如實時歸因場景，Flink實時消費Kafka，在遇到交易事件後反查DB歸因，但可能此時關鍵數據還沒入庫。
先寫Database，再寫Kafka
串行寫Database、Kafka，成功後返回客戶成功。這種方式問題也不小，第一寫入延遲增加，第二Database成功、Kafka失敗怎麼處理？
此時我們會想到Binlog（或者WAL），新的方案是DB->Binlog->Kafka：寫入Database，成功後即可返回客戶端成功，然後訂閱binlog寫入Kafka，下遊訂閱Kafka消費。實現最終一致性，同時保證了Database上的强一致讀。
基於業務場景决策
上面我們介紹了雙寫問題的三種解决方案，他們各自適應不同場景。
如果業務要求全盤的强一致體驗，那麼我們應當選擇分布式事務。
如果業務傾向全盤的最終一致性體驗，那麼我們選擇以MQ為第一入口實現最終一致性。
如果業務存在不同的一致性體驗需求，那麼我們選擇强一致讀寫DB，以DB binlog實現最終一致性的下遊業務。
Lindorm 數據訂閱介紹
Lindorm數據訂閱是 "DB->Binlog->Kakfa"方案的昇級版。
雲原生多模數據庫Lindorm數據訂閱功能支持任何一個錶的每一條數據變更，可以在客戶端實時有序的查看數據變更記錄。當開通某一張錶的數據訂閱功能後，其變更數據的操作就會被存儲。為了確保數據消費的順序和數據寫入的順序一致，數據訂閱功能提供了主鍵級別保序，對於同一個主鍵的更新操作，會按照其更新的順序存儲和消費。每次對Lindorm錶格的數據執行增删改操作時，數據訂閱都會生成一個Stream Record鍵值對，鍵值對的鍵是這一行數據的主鍵，值是此次操作的詳細信息（操作前的值，操作後的值，時間戳，操作類型）。
總結Lindorm數據訂閱的特點：
- 實時訂閱
- 100%兼容Kafka客戶端
- Key級別保序
原文鏈接
本文為阿裏雲原創內容，未經允許不得轉載。