1. 引言缓存的价值与一致性的挑战在互联网高并发场景下数据库往往成为系统的瓶颈。为了提升系统的吞吐量和响应速度我们通常会在数据库前面引入一层缓存如 Redis、Memcached将热点数据存放在内存中从而大幅度降低数据库的访问压力。然而缓存与数据库是两套独立的存储系统当数据需要更新时如何保证两者之间的数据一致性成为了架构设计中的核心难点。“亿级流量高并发”意味着每秒数万甚至数十万的读写请求数据更新频繁可能同时存在大量的读写并发对系统可用性和响应时间的极高要求。在这样的背景下任何锁、复杂事务或同步操作都可能成为性能瓶颈因此我们需要在一致性、性能和可用性之间做出权衡。本文将深入剖析各种双写一致性方案帮助你在实际场景中做出合理的技术选型。2. 问题定义什么是缓存与数据库双写一致性缓存与数据库双写一致性指的是当应用程序对数据进行修改写操作时必须保证缓存中的数据和数据库中的数据在某个时间点或最终达成一致。根据业务对数据一致性的严格程度可以分为以下两种级别2.1 强一致性 vs 最终一致性强一致性要求任何时刻、任何节点读取到的数据都是最新的。在分布式系统中通常需要引入分布式事务如 2PC、TCC或锁机制来实现但会严重影响并发性能。最终一致性允许系统在一小段时间内存在数据不一致但经过一定时间后所有副本最终会达到一致状态。这是大多数高并发场景下的妥协选择。2.2 业务场景的容忍度金融、交易类系统如余额、库存通常要求强一致性不能出现超卖或金额错误。内容类系统如用户昵称、文章点赞数可以接受短暂的最终一致性。统计类数据如 PV、UV可以容忍较大延迟。在实际高并发系统中通常很难实现真正的强一致性而是通过合理的设计将不一致的窗口缩小到可接受范围同时保证高性能。3. 并发场景下数据不一致的典型场景为了理解如何保证一致性我们首先需要分析在并发读写时缓存和数据库可能产生不一致的几种情况。假设缓存的存储模型为 key-value我们讨论写操作更新或删除和读操作的并发。3.1 先更新数据库后更新缓存流程线程A更新数据库为值X。线程A更新缓存为值X。线程B同时读取缓存读到X正确。并发问题如果两个线程同时写线程A更新数据库为X。线程B更新数据库为Y。线程B更新缓存为Y后更新缓存。线程A更新缓存为X后于B更新缓存。最终缓存中是X数据库中是Y产生不一致。原因更新缓存顺序与数据库更新顺序相反更严重的问题在读多写少的场景下频繁更新缓存会造成不必要的开销且无法解决并发顺序问题。3.2 先更新缓存后更新数据库流程线程A更新缓存为X。线程A更新数据库为X。线程B读取缓存读到X正确。并发问题同样存在顺序问题如果线程A、B同时写可能出现数据库最终值与缓存不一致。更重要的是如果更新数据库失败缓存中已经写入了新值导致缓存与数据库永久不一致除非设置过期时间。因此这种顺序很少被采用。3.3 先删除缓存后更新数据库这是早期常用的一种策略旨在让后续读请求发现缓存缺失从而从数据库加载最新数据。流程线程A删除缓存key。线程A更新数据库为X。线程B读取缓存发现缺失从数据库读取旧值Y因为线程A还没更新完然后将Y写入缓存。线程A完成数据库更新。最终缓存中是Y旧值数据库中是X新值不一致。问题核心删除缓存和更新数据库不是原子的中间存在时间窗口其他线程可能读入旧数据。3.4 先更新数据库后删除缓存这是目前公认的较优策略即 Cache Aside 模式推荐的写法。流程线程A更新数据库为X。线程A删除缓存key。后续读请求发现缓存缺失从数据库读取X并写入缓存。并发问题假设以下时序线程A读缓存未命中从数据库读到旧值Y准备写回缓存。线程B更新数据库为X并删除缓存。线程A将旧值Y写入缓存因为它在读数据库时还没被更新。最终缓存中是Y数据库中是X不一致。这个时间窗口很小但确实存在。我们需要解决的就是这个窗口期的不一致问题。4. 常见缓存模式详解在讨论具体解决方案前有必要了解几种经典的缓存读写模式它们定义了应用程序与缓存、数据库交互的方式。4.1 Cache Aside Pattern旁路缓存这是最常用的模式由应用程序直接维护缓存。读操作先读缓存命中则返回未命中则读数据库然后写入缓存再返回。写操作先更新数据库然后删除缓存或者更新缓存但删除更简单且能避免并发问题。优点实现简单缓存中只保留真正被访问的数据惰性加载。缺点需要处理并发写时可能产生的不一致如上节所述的时间窗口。4.2 Read/Write Through Pattern在这种模式下应用程序将缓存视为主要数据源读写操作都通过缓存进行缓存负责同步数据到数据库。Read Through当读取缓存未命中时缓存自己从数据库加载数据并返回。Write Through写操作时先更新缓存然后缓存同步更新数据库通常同步或异步。优点对应用程序屏蔽了底层存储细节简化了业务代码。缺点缓存需要具备与数据库交互的能力如 Redis 模块或自定义代理实现复杂同样存在一致性问题。4.3 Write Behind Caching Pattern写操作时只更新缓存然后异步批量写入数据库类似 Linux 的写回策略。优点写性能极高可将多次写合并为一次数据库操作适合写密集场景。缺点数据可能丢失缓存宕机一致性窗口较大通常用于日志、计数等允许丢失的场景。在高并发场景下Cache Aside 是最灵活且被广泛采用的模式后续讨论将以此为基础。5. Cache Aside 的并发问题与改进方案针对 Cache Aside 在并发写时可能出现的旧数据覆盖问题业界有多种改进方案。5.1 延迟双删策略核心思想在更新数据库后延迟一小段时间再次删除缓存以确保在删除期间可能出现的并发读请求写入的旧数据被清除。流程以先更新数据库后删除缓存为例线程A更新数据库。线程A删除缓存。线程A休眠一段时间如几百毫秒再次删除缓存。为什么有效第一次删除后如果有一个并发读请求在删除之后、数据库更新完成之前读取了旧数据并写回缓存那么在延迟删除时这个旧数据会被清除。第二次删除的目的是“擦屁股”。关键点延迟时间需要估算必须大于读请求将数据写回缓存的时间。通常可以设置为 500ms 或根据业务耗时统计。二次删除可能失败需要记录日志或异步重试。如果采用先删除缓存再更新数据库延迟双删同样适用但需要调整步骤。伪代码示例Java Redisjavapublic void updateData(String key, Object newValue) { // 1. 更新数据库 database.update(key, newValue); // 2. 第一次删除缓存 redis.del(key); // 3. 延迟一段时间例如500ms Thread.sleep(500); // 4. 第二次删除缓存 redis.del(key); }注意sleep 会阻塞线程在高并发下不可取。通常使用异步任务或延迟队列如 ScheduledExecutorService、RabbitMQ 延迟消息来执行二次删除。优点实现简单能有效解决大部分并发不一致问题。缺点仍存在极短时间内不一致窗口缩短到延迟时间且二次删除可能因系统故障而失败。5.2 设置缓存过期时间兜底无论采用何种策略为缓存设置一个合理的过期时间TTL是最简单有效的兜底手段。即使由于某些原因导致数据不一致缓存过期后会自动失效下一次读请求会从数据库拉取最新数据。过期时间不宜过长一般设置为几分钟到几小时根据业务容忍度决定。结合延迟双删即使二次删除失败过期时间最终会修复一致性。5.3 基于分布式锁的强一致性如果业务要求强一致性可以通过加锁来保证同一时间只有一个线程能操作某个数据。思路在写操作前获取分布式锁如 Redis 的 SETNX锁的粒度可以是数据项的 key。获得锁的线程执行“更新数据库 更新/删除缓存”操作其他线程等待或直接返回。流程线程A尝试获取锁 key_lock。成功则执行更新数据库然后更新缓存或删除最后释放锁。线程B获取锁失败可以选择自旋等待、快速失败或降级处理。缺点性能下降锁会导致并发写串行化降低吞吐量。死锁风险需设置锁超时自动释放。锁粒度如果热点数据多锁竞争激烈。适用场景对一致性要求极高、写并发相对较低的核心数据如库存扣减。在亿级流量下通常只会对关键数据加锁且需优化锁粒度如分段锁。5.4 版本号/时间戳 CAS利用数据的版本号version或更新时间戳在写入缓存时采用 CASCompare And Swap方式确保只有最新版本的数据才能被写入。设计数据库中增加 version 字段每次更新 version1。读数据时从数据库读取数据和版本号一起写入缓存缓存值包含版本号。写操作时更新数据库version1并删除缓存或更新缓存但需检查版本。并发解决如果线程A在更新数据库后删除了缓存但线程B恰好读到了旧数据并尝试写回缓存此时缓存中可能已经有其他线程写入的新版本数据或为空。如果采用更新缓存而不是删除可以要求写入缓存时携带版本号只有当前版本大于缓存中的版本时才允许写入。但通常删除缓存更简单因为版本控制增加了复杂度。在分布式环境下可以使用 Redis 的 Lua 脚本实现原子性检查和设置SET if version matches。优点无需锁性能较好。缺点需要业务表增加字段代码逻辑稍复杂。6. 基于消息队列的最终一致性方案前面提到的方案都是在一次请求内同步完成数据库和缓存的操作。当并发极高时同步操作可能增加响应时间或导致失败。引入消息队列可以实现异步解耦达到最终一致性。6.1 设计思路应用程序更新数据库后发送一条“缓存更新”消息到消息队列如 Kafka、RocketMQ。一个或多个消费者监听消息执行缓存删除或更新操作。如果消费者执行失败可通过重试机制保证最终成功。优点写操作只需更新数据库快速响应。消息队列削峰填谷保护缓存系统。解耦业务逻辑与缓存维护。缺点引入消息中间件增加系统复杂度。存在消息延迟不一致窗口取决于消息处理速度。需要处理消息重复消费幂等性。6.2 消息可靠性与顺序保证可靠性生产者需确认消息发送成功同步/异步消费者需手动 ACK 并处理重试。顺序性如果对同一数据的更新需要按顺序执行可以使用分区键如数据ID保证相同 key 的消息发送到同一分区消费者单线程处理。但 Redis 删除操作本身是幂等的多次删除不影响最终一致性顺序性要求不高时可以忽略。6.3 重试与死信处理当消费者执行删除缓存失败如 Redis 超时应该进行重试。可设置重试次数超过次数后进入死信队列人工介入或通过定时任务补偿。伪代码RocketMQ 示例java// 生产者 Transactional public void updateDB(Data data) { database.update(data); // 发送消息包含 key 信息 rocketMQTemplate.send(cache-topic, MessageBuilder.withPayload(data.getId()).build()); } // 消费者 RocketMQMessageListener(topic cache-topic, consumerGroup cache-group) public class CacheConsumer implements RocketMQListenerString { Override public void onMessage(String key) { redis.del(key); // 如果失败抛出异常RocketMQ 会根据配置重试 } }7. 基于数据库 binlog 的增量同步Canal阿里巴巴开源的 Canal 组件可以模拟 MySQL slave 的交互协议解析 binlog 日志获取数据库的增量变更然后同步到缓存或其他存储。这种方式实现了业务代码与缓存更新的完全解耦。7.1 工作原理Canal 伪装成 MySQL 从库向主库发送 dump 请求。MySQL 主库推送 binlog 给 Canal。Canal 解析 binlog得到行数据变更insert/update/delete。根据配置将变更数据发送到 MQ 或直接调用接口更新缓存。7.2 业务无侵入设计应用程序只需要正常更新数据库无需编写任何缓存更新代码。Canal 监听到变更后自动更新 Redis。这符合低侵入的设计原则。优点与业务代码完全解耦降低开发成本。可以保证数据库更新一定能触发缓存更新除非 Canal 故障。天然支持所有数据库变更操作。缺点引入 Canal 和 MQ 等组件运维复杂。binlog 同步有延迟毫秒级到秒级取决于网络和 Canal 处理能力。需要处理异构数据格式如将关系行转换为 Redis 结构。7.3 延迟与一致性的权衡由于 binlog 同步是异步的存在短暂的不一致窗口。对于大多数最终一致性场景可以接受。如果业务需要更严格的实时性可以结合 Cache Aside 的主动删除但这样又增加了耦合。典型架构text应用程序 - 更新数据库 数据库 binlog - Canal - MQ - 消费者更新 Redis同时读请求走 Cache Aside先读 Redis未命中则读数据库并回写。这样即使 binlog 还没更新 Redis读请求也能通过 Cache Aside 拉取最新数据但可能因为并发导致旧数据回写需配合过期时间。8. 方案对比与选型指南为了在亿级流量高并发下做出合理选择我们需要从多个维度评估上述方案。8.1 一致性强度方案一致性强度不一致窗口延迟双删最终一致性延迟时间如500ms分布式锁强一致性串行化无锁释放后立即一致版本号/CAS强一致性乐观锁无但需保证原子性消息队列最终一致性消息处理延迟通常秒级Canal binlog最终一致性binlog同步延迟毫秒到秒级单纯 Cache Aside最终一致性极小窗口并发读写碰撞8.2 复杂度与维护成本延迟双删低只需在业务代码中添加异步二次删除逻辑。分布式锁中需引入锁组件处理锁超时、重试。版本号/CAS中需修改表结构编写 Lua 脚本。消息队列中高引入 MQ 集群需处理消息可靠性、幂等性。Canal高部署 Canal 和 MQ监控 binlog 同步状态。8.3 性能影响延迟双删异步删除几乎不影响主流程但 sleep 会阻塞线程需改为异步。分布式锁加锁导致写串行化对高并发写性能影响大。版本号/CAS乐观锁无阻塞适合读多写少。消息队列写操作只更新 DB性能最好。Canal读操作受 Cache Aside 影响写操作无额外开销。8.4 适用场景总结表方案适用场景延迟双删大多数互联网业务对一致性要求不高可容忍短暂不一致简单易行分布式锁库存扣减、秒杀等强一致场景写并发较低版本号/CAS数据有版本控制可接受少量写冲突如用户信息更新消息队列写操作频繁希望降低响应时间对一致窗口有容忍度Canal希望彻底解耦缓存更新已有 binlog 同步基础设施接受秒级延迟9. 亿级流量下的挑战与应对除了数据一致性亿级流量高并发场景下还需要面对缓存系统自身的诸多挑战这些挑战与一致性方案相互影响。9.1 缓存击穿、雪崩、穿透与一致性方案的结合缓存击穿一个热点 key 失效大量并发请求穿透到 DB。在一致性方案中如果采用先删缓存后更新 DB很容易引发击穿。因此推荐先更新 DB 后删缓存并在回写缓存时加锁互斥锁防止并发回写。缓存雪崩大量 key 同时失效。解决方案设置随机过期时间结合一致性方案中的过期兜底。缓存穿透查询不存在的数据。可在缓存中存储空值或布隆过滤器避免 DB 压力。在延迟双删或消息队列方案中二次删除或异步更新可能会引起短暂的缓存缺失但通常不会造成大量击穿因为删除的是单个 key。9.2 高并发下的锁粒度控制如果必须使用分布式锁保证强一致性需要精细控制锁粒度分段锁将数据分成多个 segment每个 segment 独立加锁减少锁竞争如库存分段。乐观锁使用版本号在更新时检查失败重试。锁超时时间合理设置避免死锁同时不能太短导致并发冲突。9.3 热点数据与多级缓存对于极端热点数据如大 V 的微博单一缓存可能仍无法承受读取压力可以采用多级缓存L1本地缓存如 Caffeine在应用内存中缓存超短过期时间。L2分布式缓存如 Redis。此时一致性维护更加复杂因为需要同步更新两级缓存。通常 L1 过期时间极短或通过消息通知各应用节点清除本地缓存。10. 实战经验与最佳实践10.1 业务需求驱动选型在开始设计前必须明确业务对一致性的要求关键数据如订单状态、支付金额采用分布式锁或 TCC 分布式事务确保强一致同时做好降级预案。重要但可短暂不一致如商品标题、描述采用延迟双删 过期时间或 Canal 异步更新。非关键数据如浏览量、点赞数采用 Write Behind定期刷盘。10.2 推荐组合方案Cache Aside 过期时间 异步补偿对于大多数高并发系统我推荐以下组合读操作Cache Aside先读缓存未命中则读数据库并回写。写操作先更新数据库。然后删除缓存同步删除。同时发送一条“延迟删除”消息到 MQ或提交一个异步任务在几秒后再次删除缓存延迟双删的异步版本。设置缓存过期时间如 1 小时作为最终兜底。监控与补偿记录删除缓存失败的日志通过定时任务扫描重试。定期对账如全量比对或抽样发现不一致后修复。这个方案结合了 Cache Aside 的简单性、延迟双删的短窗口和过期时间的兜底同时通过 MQ 异步化避免了线程阻塞。10.3 监控、巡检与数据对账在分布式环境中任何方案都不能保证 100% 的一致因此需要建立监控和修复机制缓存命中率监控突然下降可能表示缓存被大量删除或失效。数据库与缓存一致性巡检选取部分数据比对两者的内容记录不一致率。报警当不一致率超过阈值或关键数据不一致时及时告警。自动修复工具如通过定时任务扫描根据数据库最新数据修复缓存。11. 总结在亿级流量高并发场景下保证缓存与数据库的双写一致性是一个系统工程问题没有“银弹”。我们需要在一致性、性能、可用性和复杂度之间做出权衡。Cache Aside 模式是基础但需通过延迟双删、过期时间等弥补并发缺陷。分布式锁可以保证强一致但会牺牲性能适用于核心场景。消息队列和 Canal实现最终一致性适合业务解耦和异步化。监控和补偿是最后一公里确保系统长期健康。