数据库缓存同步 binLog

基于binlog的数据库-缓存同步方案

当出现在删除缓存之前，系统突然崩溃或者出现了其他问题，那么缓存中的数据就会变得过时，因为缓存删除操作并未被执行时，也可以用基于binlog的数据库-缓存同步方案。

这个方案中，我们不再直接在业务代码中执行删除Redis缓存的操作，而是将这个任务交给了一个独立的进程或服务。这个服务会订阅MySQL的binlog，监听到数据库的更新操作，然后根据binlog日志中的信息找到对应的Redis键并进行删除操作。

优点：

1. 减少了业务代码的复杂性：因为不再需要在业务代码中显式地删除Redis缓存，这一操作被抽象为了一个独立的服务，从而降低了业务代码的复杂性。
2. 减少了系统的耦合性：这个方案不需要将消息队列和业务代码深度绑定，可以降低系统各部分之间的耦合度。

缺点：

1. 需要对binlog有深入的理解：要实现这个方案，需要对MySQL的binlog机制有深入的理解，这可能需要一定的学习成本。
2. 实时性可能受到影响：虽然在大多数情况下这个方案可以保证数据的一致性，但是由于binlog处理和缓存删除并不是在同一操作中完成，因此在极端情况下可能存在短暂的数据不一致。如果系统有严格的实时性要求，这可能会是一个问题。
3. 对数据库有一定的依赖：这个方案依赖于MySQL的binlog，因此如果数据库选择了其他的产品或者由于某种原因无法获取到binlog，那么这个方案就无法实施。