双写一致性问题的核心是确保数据库和缓存之间的数据同步，以避免缓存与数据库数据不同步的问题，尤其是在高并发和异步环境下。本文将探讨双写一致性面临的主要问题和解决方案，重点关注最终一致性。

本文讨论的是最终一致性问题

双写一致性面临的主要问题

 1、数据库和缓存非同一事务

在实际应用中，数据库和缓存通常不在同一个事务中执行，导致两者更新的顺序和时机不同。如果在某一操作过程中发生异常，可能导致数据库和缓存的数据不一致。

例如：

• 先写缓存，再写数据库：如果写数据库失败，缓存可能已经更新，导致数据不一致。

• 先写数据库，再写缓存：如果写缓存失败，数据库可能已经更新，导致缓存数据过期或失效。

• 先删缓存，再写数据库：如果在删除缓存后发生异常，读取缓存时可能重新写入旧数据，导致一致性问题。

2、并发写入顺序不一致

在高并发场景下，多个线程或请求可能同时修改缓存和数据库，导致写入顺序不一致。例如，线程1先更新了数据库但未更新缓存，线程2先更新了数据库和缓存，最后线程1才更新缓存，导致缓存和数据库之间的顺序不一致。

例如：

• 先写缓存，再写数据库

• 先写数据库，再写缓存

  

3、先删缓存后写数据库的问题

这种策略常见于保证缓存数据失效的情况，但如果删除缓存操作和更新数据库操作之间的时间差过长，可能会导致“旧值回填”问题。

具体问题是：在删除缓存后，数据库未更新前，如果有读请求到达，系统会从数据库读取旧数据并写入缓存，导致缓存和数据库数据不一致。

解决双写一致性问题的方案

1、延迟双删

第一次删除缓存：数据库更新成功后立即进行。

延迟一段时间后再次尝试删除缓存，以防止旧值回填。

该方法虽然有效，但如果第二次删除失败，仍可能造成数据不一致。

2、增强版延迟双删+重试机制

对于删除缓存失败的情况，采用重试机制。

• 方案1：直接重试删除操作。

• 方案2：通过消息队列（MQ）异步推送删除操作，避免同步操作对性能的影响。

3、监听数据库binlog异步删除缓存

利用数据库的binlog（日志文件）机制，在数据更新后通过消费者异步删除缓存。

• 优点：避免了删除缓存与更新数据库操作的同步性问题，提升了系统的可靠性。

• 缺点：需要额外的基础设施来支持binlog监听和缓存删除。

最终保障：

对于长时间未能成功删除的情况，考虑状态升级，必要时进行人工干预。

一致性

1. 强一致性

• 所有节点始终访问到相同的最新数据，数据更新后，所有读操作立即返回最新数据。

• 适用于用户对一致性要求极高的场景，但可能会牺牲系统的性能。

2. 弱一致性 

• 系统允许数据更新后短时间内存在延迟，不同节点可能在短期内不同步，直到最终一致性达到。

• 提高了性能，但用户感知的实时性较差。

3. 最终一致性

• 数据在一段时间后最终达到一致，即使没有新的更新操作，所有节点的状态会逐步同步。

• 常用于分布式系统中，尤其适用于大规模、高并发的场景。