拒絕雙寫:巧用Lindorm數據訂閱

阿裏雲雲棲號 2021-09-18 16:12:00 阅读数:905

巧用 lindorm

簡介: 本文介紹了雙寫場景的一致性問題,詳細介紹了三種解决方案,並針對DB->Binlog->Kafka方案給出了Lindorm數據訂閱的最佳實踐。

雙寫問題介紹

雙寫問題(Dual Write Problem)是指:需要同時修改兩個獨立系統的場景,比如Database和Kafka,再比如Database和緩存,那麼如何保障兩個系統的數據一致性?

image.png

以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"方案的昇級版。

image.png

雲原生多模數據庫Lindorm數據訂閱功能支持任何一個錶的每一條數據變更,可以在客戶端實時有序的查看數據變更記錄。當開通某一張錶的數據訂閱功能後,其變更數據的操作就會被存儲。為了確保數據消費的順序和數據寫入的順序一致,數據訂閱功能提供了主鍵級別保序,對於同一個主鍵的更新操作,會按照其更新的順序存儲和消費。每次對Lindorm錶格的數據執行增删改操作時,數據訂閱都會生成一個Stream Record鍵值對,鍵值對的鍵是這一行數據的主鍵,值是此次操作的詳細信息(操作前的值,操作後的值,時間戳,操作類型)。

總結Lindorm數據訂閱的特點:

  • 實時訂閱
  • 100%兼容Kafka客戶端
  • Key級別保序

原文鏈接
本文為阿裏雲原創內容,未經允許不得轉載。

版权声明:本文为[阿裏雲雲棲號]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/09/20210918161200448n.html