參考：
阿裡巴巴 MySQL binlog 增量訂閱&消費元件
Debezium for PostgreSQL to Kafka
Logical Decoding Output Plug-in Installation for PostgreSQL
解決思路
總體思路，監聽資料庫操作記錄日志（DML為主），将資料的變動發向kafka，然後應用端進行消費更新緩存。如下圖所示：
下面按照資料庫的區分分别初探一下解決方案，與大家共同學習，具體的配置有機會搭建再給出。
MySQL
MySQL作為目前網際網路行業應用最廣泛、最流行的資料庫，阿裡已經有比較成熟的元件進行支援binlog增量訂閱——Canal。
Canal會僞裝成MySQL的slave，然後MySQL推送binlog給canal，canal解析byte流資料，發給kafka。
解決方案：MySQL+Canal+Kafka+Redis
PostgreSQL
PostgreSQL标榜自己是世界上最先進的開源資料庫，現在已有不少公司采用PG作為自己的結構化資料持久化存儲。
關于PG和MySQL的比較，可以參考如下文章：
PostgreSQL VS MySQL
MySQL的複制是基于binlog的邏輯異步複制，無法實作同步複制，MySQL所有的高可用方案都是基于binlog做的同步，以及基于MySQL的分布式資料也是基于MySQL的binlog實作，binlog是MySQL生态圈最基本技術實作。
PostgreSQL可以做到同步，異步，半同步複制，以及基于日志邏輯複制，可以實作表級别的訂閱和釋出，可以同步資料到kafka，通過kafka實作資料流轉。
Canal并不支援PG，所幸的是有元件支援。Debezium是一個開源項目，為捕獲資料更改(change data capture,CDC)提供了一個低延遲的流式處理平台。可以安裝并且配置Debezium去監控你的資料庫，然後你的應用就可以消費對資料庫的每一個行級别(row-level)的更改。隻有已送出的更改才是可見的，是以你的應用不用擔心事務(transaction)或者更改被復原(roll back)。
解決方案：PostgreSQL+Debezium+Kafka+Redis
如下圖所示：
是以，解決緩存和資料庫的資料一緻性，可以采用如下方式：
- 建構基于Redis緩存，并先進行緩存預熱；
- 業務線程讀取緩存，通路不到發消息到kafka通知進行緩存的更新，同時業務線程自己去讀取資料庫；
- 背景線程消費debezium/canal發的kafka消息進行緩存的更新（先删除再建立），此時緩存的有效期設定為永久
當然，上述要注意一點，即保證消息的順序消費，否則緩存進行了DML亂序操作，資料就不會和資料庫一緻了。可以參考以下文章：
版權聲明：本文為CSDN部落客「hzk1562110692」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：https://blog.csdn.net/hzk1562110692/article/details/101451454