簡介：?本文介紹了雙寫場景的一致性問題，詳細介紹了三種解決方案，并針對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級別保序

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的拒绝双写：巧用Lindorm数据订阅的全部內容，希望文章能夠幫你解決所遇到的問題。

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