上一文中提到延时双删等策略实现数据一致性的时候，可能存在删除缓存失败的情况，就会出现缓存和数据库不一致的问题。为了应对删除缓存失败而导致数据不一致的问题，可以通过回溯数据库日志文件，提供一个保障的重试机制即可。
流程如下图所示：
(1)更新数据库数据
(2)数据库会将操作信息写入binlog日志当中
(3)订阅程序提取出所需要的数据以及key
(4)另起一段非业务代码，获得该信息
(5)尝试删除缓存操作，发现删除失败
(6)将这些信息发送至消息队列
(7)重新从消息队列中获得该数据，重试操作。
可以借鉴阿里的方法：使用中间件canal
Canal是什么
canal 是阿里巴巴的一个开源项目，基于java实现，已经在很多大型的互联网项目生产环境中使用，包括阿里、美团等都有广泛的应用，是一个非常成熟的数据库同步方案，基础的使用只需要进行简单的配置即可。canal是通过伪装成mysql 的从库，监听mysql 的binlog日志来获取数据。binlog设置为row模式以后，不仅能获取到执行的每一个增删改的脚本，同时还能获取到修改前和修改后的数据，基于这个特性，canal就能高性能的获取到mysql数据数据的变更。
Canal用途：
数据库镜像
数据库实时备份
索引构建和实时维护(拆分异构索引、倒排索引等)
业务 cache 缓存刷新
带业务逻辑的增量数据处理
在理解canal的原理前，我们先来看看关于MySQL数据库主从数据库的基础知识，这样就能更高效的理解Canal。
数据库的读写分离
为了应对高并发场景，MySQL支持把一台数据库主机分为单独的一台写主库(主要负责写操作)，而把读的数据库压力分配给读的从库，而且读从库可以变为多台，这就是读写分离的典型场景。
数据库主从同步
实现数据库的读写分离，是通过数据库主从同步，让从数据库监听主数据库Binlog实现的。大体流程如下：
❝
MySQL master 将数据变更写入二进制日志( binary log, 可以通过 show binlog events 进行查看)
MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据
❞
可以看到，这种架构下会有一个问题，数据库主从同步会存在延迟，那么就会有短暂的时间，主从数据库的数据是不一致的。
这种不一致大多数情况下非常短暂，很多时候我们可以忽略他。
但一旦要求数据一致，就会引申出如何解决这个问题的思考。
数据库主从同步一致性问题
我们通常使用MySQL主从复制来解决MySQL的单点故障问题，其通过逻辑复制的方式把主库的变更同步到从库，主从之间无法保证严格一致的模式，
于是，MySQL的主从复制带来了主从“数据一致性”的问题。MySQL的复制分为：异步复制、半同步复制、全同步复制。
异步复制
MySQL默认的复制即是异步复制，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
❝
主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上。
❞
全同步复制
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
❝
当主库提交事务之后，所有的从库节点必须收到、APPLY并且提交这些事务，然后主库线程才能继续做后续操作。但缺点是，主库完成一个事务的时间会被拉长，性能降低。
❞
半同步复制
是介于全同步复制与全异步复制之间的一种，主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经完全完成并且提交的反馈，如此，节省了很多时间。
❝
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
❞
事实上，半同步复制并不是严格意义上的半同步复制，MySQL半同步复制架构中，主库在等待备库ack时候，如果超时会退化为异步后，也可能导致“数据不一致”。
❝
当半同步复制发生超时时(由rpl_semi_sync_master_timeout参数控制，单位是毫秒，默认为10000，即10s)，会暂时关闭半同步复制，转而使用异步复制。当master dump线程发送完一个事务的所有事件之后，如果在rpl_semi_sync_master_timeout内，收到了从库的响应，则主从又重新恢复为半同步复制。
❞
Canal工作原理
了解了数据库从库的数据同步原理，理解canal便十分简单，其工作原理为:
canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
canal 解析 binary log 对象(原始为 byte 流)
总结来说，canal将自己伪装成mysql的从库，从主库那里消费并解析binlog，通过日志来保持数据的一致性。
Canal实战
因为篇幅有限，对canal的实际使用感兴趣的同学可以在我的个人博客查看：
https://blog.csdn.net/big_white_py/article/details/107826180
