拒絕雙寫:巧用 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客戶端
相關文章
- 2021-08-2021022期足彩14場+任九精選推薦:那不勒斯小勝過關,美因茨搶分勢頭迅猛。
- 2021-07-2608年奧運會, 科比是最好的球員嗎? 球迷: 沒有他又被按在地上摩擦
- 2021-07-20球王!梅西9項資料領跑足壇,C羅僅超梅西2項,這該如何責怪豬隊友?
- 2021-06-10汽車“自動駕駛”服務上線,一小時收費54塊!還不如找代駕?!
- 2021-04-17交易生態模式看齊蘋果,Oculus Quest商店支援訂閱服務