双写一致性问题的核心是确保数据库和缓存之间的数据同步，以避免缓存与数据库数据不同步的问题，尤其是在高并发和异步环境下。本文将探讨双写一致性面临的主要问题和解决方案，重点关注最终一致性。
本文讨论的是最终一致性问题
双写一致性面临的主要问题
1、数据库和缓存非同一事务
在实际应用中，数据库和缓存通常不在同一个事务中执行，导致两者更新的顺序和时机不同。如果在某一操作过程中发生异常，可能导致数据库和缓存的数据不一致。
例如：
-
先写缓存，再写数据库：如果写数据库失败，缓存可能已经更新，导致数据不一致。
-
先写数据库，再写缓存：如果写缓存失败，数据库可能已经更新，导致缓存数据过期或失效。
-
先删缓存，再写数据库：如果在删除缓存后发生异常，读取缓存时可能重新写入旧数据，导致一致性问题。
2、并发写入顺序不一致
在高并发场景下，多个线程或请求可能同时修改缓存和数据库，导致写入顺序不一致。例如，线程1先更新了数据库但未更新缓存，线程2先更新了数据库和缓存，最后线程1才更新缓存，导致缓存和数据库之间的顺序不一致。
例如：
-
先写缓存，再写数据库
-
先写数据库，再写缓存
3、先删缓存后写数据库的问题
这种策略常见于保证缓存数据失效的情况，但如果删除缓存操作和更新数据库操作之间的时间差过长，可能会导致"旧值回填"问题。
具体问题是：在删除缓存后，数据库未更新前，如果有读请求到达，系统会从数据库读取旧数据并写入缓存，导致缓存和数据库数据不一致。
解决双写一致性问题的方案
1、延迟双删
第一次删除缓存：数据库更新成功后立即进行。
延迟一段时间后再次尝试删除缓存，以防止旧值回填。
该方法虽然有效，但如果第二次删除失败，仍可能造成数据不一致。
2、增强版延迟双删+重试机制
对于删除缓存失败的情况，采用重试机制。
-
方案1：直接重试删除操作。
-
方案2：通过消息队列（MQ）异步推送删除操作，避免同步操作对性能的影响。
3、监听数据库binlog异步删除缓存
利用数据库的binlog（日志文件）机制，在数据更新后通过消费者异步删除缓存。
-
优点：避免了删除缓存与更新数据库操作的同步性问题，提升了系统的可靠性。
-
缺点：需要额外的基础设施来支持binlog监听和缓存删除。
最终保障：
对于长时间未能成功删除的情况，考虑状态升级，必要时进行人工干预。
一致性
1. 强一致性
-
所有节点始终访问到相同的最新数据，数据更新后，所有读操作立即返回最新数据。
-
适用于用户对一致性要求极高的场景，但可能会牺牲系统的性能。
2. 弱一致性
-
系统允许数据更新后短时间内存在延迟，不同节点可能在短期内不同步，直到最终一致性达到。
-
提高了性能，但用户感知的实时性较差。
3. 最终一致性
-
数据在一段时间后最终达到一致，即使没有新的更新操作，所有节点的状态会逐步同步。
-
常用于分布式系统中，尤其适用于大规模、高并发的场景。