一致性方案的设计原则
- 数据一致性：确保Redis和MySQL中的数据在任何时候都是一致的，即任何对数据的修改在Redis和MySQL中都应同步体现
- 事务性：确保数据同步操作具有原子性，即要么全部成功，要么全部失败。
- 持久性：确保即使系统崩溃或重启，已同步的数据也不会丢失。
实现方案
设置缓存key过期时间
- 此方案只适用对数据一致性要求很低或写请求很少的业务，当查询没有命中缓存时，就从数据库中读，把查到的数据写到缓存，同时设置缓存的过期时间。
- 写操作直接更改数据库，不用更新缓存。但是当一个key没过期时，写操作已更新数据库数据，此时的读还是读取到旧数据。此时就出现数据不一致了。
先更新数据库，再更新缓存
- 此方案适用于读多写少的场景。但是可能会出现更新完数据库还未更新缓存，此时的查询操作查询缓存则是更新之前的数据，就会造成数据不一致了
先删除缓存，再更新数据库
- 先删除缓存，如果删除成功再去更新数据库，就算数据库更新失败，再次读取数据库缓存到redis数据还是一致的。
- 但是高并发的情况下，如果A删除完缓存，A再去更新数据库，在更新的过程后，B来查询数据，发现缓存没有，就从数据库获取并更新缓存，后面A更新成功，就会出现缓存和数据库不一致。如果后面一直没有更新操作，则缓存则与数据库一直不一致了，所以这种情况给缓存设置一个过期时间，做一个兜底操作
延时双删
- 先删除缓存数据，再更新数据库数据，等待一小段时间，再次删除缓存数据（可以另开线程执行删除，也可以设置删除重试次数，避免删除失败）
- 存在的问题：无法绝对保障数据的一致性，因为延迟时间难以确认，如果偏大也会造成系统性能问题，所以到底是延迟多长时间，这个很难确认，偏小又起不到延时双删的作用。所以延时时间还得根据实际场景做出评估。
使用消息队列
- 先更新数据库，然后将删除缓存的消息投递到消息队列中。收到删除缓存消息后，尝试进行删除缓存。如果失败，则不断进行重试。
- 引入了消息队列，系统的复杂性提升，可用性降低。也会带来各种各样的问题，例如消息丢失、乱序与重复消费等。在删除缓存的场景下，乱序与重复消费不会造成任何问题。但是消息丢失则会导致数据不一致情况。
监听binlog
- 异步监听binlog：监听数据库的binlog，检测到数据更新则去删除缓存，如果删除失败则通过MQ不断重试，直至删除成功，业务代码只操作数据库，不操作缓存。同时启动一个订阅binlog的程序去监听删除操作，然后投递到消息队列中。再启动一个消费者，根据消息去删除缓存。在MySQL中，可以使用Canal中间件来订阅binlog。
- 该方案使用一个中间件来帮我们完成解耦工作，但也让系统的复杂度逐步上升。
总结
大量数据同步可能导致Redis和MySQL的性能下降，也会增加系统的复杂性，维护成本也会上升，在选择方案时要针对自己的业务场景选择合适的方案。
