參考：
阿里巴巴 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亂序操作，數據就不會和數據庫一致了。可以參考以下文章：
如何保證消息的順序性