拒絕雙寫：巧用 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客戶端