redis和mysql之间的数据一致性

解决双写一致性问题的主要策略

1、旁路缓存模式(Cache Aside Pattern)

在这个模式中，我们一般都是先更新数据库再删除旧缓存。
首先，为什么我们不选择先删除缓存再更新数据库，因为这样会导致在并发的情况下，假如A线程先删除了缓存，但是由于并发的情况，B线程在缓存中未读取数据，在数据库中读取数据之后，写入缓存之中，然后A数据写入数据库。那么此时缓存和数据库之间不一致，这比先更新数据库再删除旧缓存的结果坏的多。

2、解决双写一致性问题的三种方案

2.1 延时双删策略

延迟双删策略主要用于解决在高并发的场景下，由于网络延迟、并发控制等原因造成的数据库和缓存不一致的问题。
但是由于网络延迟或其他不确定性因素，删除缓存与数据库更新之间可能存在时间窗口，导致在这段时间内的读请求从数据库读取数据后写回缓存，新写入的缓存数据可能还未反映出数据库的最新变更。所以为了解决这个问题，延时双删策略在第一次删除缓存后，设定一段短暂的延迟时间，如几百毫秒，然后在这段延迟时间结束后再次尝试删除缓存。这样做的目的是确保在数据库更新传播到所有节点，并且在缓存中的旧数据彻底过期失效之前，第二次删除操作可以消除缓存中可能存在的旧数据，从而提高数据一致性。

2.2 删除缓存重试机制

删除缓存重试机制是指在删除缓存操作失败时，设定一个重试策略，确保缓存最终能被正确的删除，以维持与数据库的一致性。
在执行数据库更新操作之后，尝试删除关联的缓存项，如果首次删除缓存失败（例如网络波动、缓存服务暂时不可用等情况），系统进入重试逻辑，按照预先设定的策略（如指数退避、固定间隔重试等）进行多次尝试。直到缓存删除成功，或者达到最大重试次数为止。通过这种方式，即使在异常情况下也能尽量保证缓存与数据库的一致性。

监听并读取biglog异步删除缓存

在数据库发生写操作时，将变更记录在binlog或类似的事务日志中，然后使用一个专门的异步服务或者监听器订阅binlog的变化（比如Canal），一旦检测到有数据更新，便根据binlog中的操作信息定位到受影响的缓存项。讲这些需要更新缓存的数据发送到消息队列，消费者处理消息队列中的事件，异步地删除或更新缓存中的对应数据，确保缓存与数据库保持一致。在
这里面，我们需要注意几个问题，首先就是消息的顺序性，对于这个，我们可以使用一些具有顺序性的消息队列，例如kafka,其次是幂等性。同时在异步处理binlog中，务必考虑一下异常的处理机制和重试策略，确保binlog事件能够正确的处理并执行缓存更新操作。