解决缓存和数据库的数据一致性

参考：

阿里巴巴 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
如下图所示：

所以，解决缓存和数据库的数据一致性，可以采用如下方式：

1. 构建基于Redis缓存，并先进行缓存预热；
2. 业务线程读取缓存，访问不到发消息到kafka通知进行缓存的更新，同时业务线程自己去读取数据库；
3. 后台线程消费debezium/canal发的kafka消息进行缓存的更新（先删除再建立），此时缓存的有效期设置为永久

当然，上述要注意一点，即保证消息的顺序消费，否则缓存进行了DML乱序操作，数据就不会和数据库一致了。可以参考以下文章：
如何保证消息的顺序性