缓存与数据库一致性的核心方案一、旁路缓存 (Cache Aside)缓存只是一个旁路边的辅助组件数据库才是真实的主数据源缓存不接管读写读写控制权全部交给业务代码。适用场景读多写少的业务场景是目前业务开发中最常用的缓存一致性方案。1. 核心执行逻辑读流程优先查询缓存若缓存未命中再查询数据库最后将数据库查询结果回写至缓存供后续请求复用。写流程先更新数据库再删除缓存数据。核心说明写操作优先选择删除缓存而非更新缓存。删除操作具备简单、幂等的特性能够有效规避并发写场景下的数据一致性问题避免缓存数据与数据库数据错乱。2. 核心痛点及解决方案痛点一高并发读写一致性问题受网络延迟、读写并发、数据库主从同步延迟、事务未提交等因素影响会出现缓存数据被污染的问题具体执行流程如下请求 A读发现缓存未命中从 DB 读取旧值 10。请求 B写更新 DB 为新值 20并成功删除缓存此时缓存为空。请求 A读由于网络延迟或 GC 停顿在请求 B 执行完删除后才将刚才查到的旧值 10 写入缓存。结果缓存中保存了旧值 10而 DB 中是新值 20造成长期的脏数据。常规优化方案延迟双删策略延迟时间常规设置为200ms~500ms错开读写并发的时间窗口避免旧数据回写缓存。痛点二缓存删除失败问题若直接删除缓存失败会导致缓存留存旧数据引发数据不一致。可将缓存删除操作交由MQ处理依托MQ的消息重试、持久化机制保障缓存删除操作最终执行成功。3. 终极解决方案Canal 监听 Binlog通过Canal组件监听MySQL的Binlog日志Canal会把自己伪装成从库发送dump 请求获取Binlog日志异步感知数据库数据变更自动执行缓存删除或更新操作。该方案对业务代码完全无侵入可靠性极高可同时解决上述两大痛点。方案核心原理MySQL 两阶段提交机制Prepare阶段InnoDB引擎将数据写入redo log日志并将事务状态标记为prepareBinlog写入阶段记录数据逻辑变更信息写入Binlog日志并刷盘持久化Commit阶段InnoDB将redo log事务状态更新为commit完成事务提交。MySQL宕机恢复机制若事务在Commit阶段宕机重启后MySQL会校验Binlog完整性。只要Binlog日志已完整写入即便redo log处于prepare状态MySQL也会判定事务有效并自动提交。因此只要Canal读取到Binlog日志即可判定数据库数据已提交生效以此保障缓存更新的准确性。方案优势传统MQ手动更新方案需改造业务代码针对Redis、ES、大数据平台等不同中间件单独发送消息代码冗余且扩展性差。而Canal可作为统一数据分发中心通过下游配置多组消费者分别处理Redis缓存更新、ES索引更新、HBase数据同步等需求大幅简化业务架构。4. 实战落地实际开发中可基于RedisTemplate、Jedis等主流Redis客户端二次封装通用的CacheService缓存工具类统一处理缓存查询、删除、更新等操作。二、读/写直通 (Read/Write Through)核心特性保障缓存与数据库强一致性适用于对数据准确性、一致性要求极高的核心业务场景。1. Read Through读直通由缓存服务统一接管数据查询逻辑。业务请求查询数据时若缓存未命中缓存服务主动同步查询数据库将数据加载至缓存后再返回结果给业务应用应用无需直接操作数据库。2. Write Through写直通由缓存服务统一接管数据写入逻辑。业务应用仅需写入缓存缓存服务会同步将数据更新至数据库仅当数据库写入成功后才向应用返回写入成功结果。3. 核心痛点所有读写操作均需同步联动数据库链路耗时较长接口响应延迟高并发性能较差。4. 技术实现Ehcache缓存框架原生提供CacheLoader读加载、CacheWriter写写入接口开发者完成配置后调用cache.put()等缓存方法框架会自动执行数据库CRUD操作无需手动编写SQL。三、异步写回 (Write Back / Write Behind)核心特性以数据一致性为代价极致提升写入并发性能适用于高并发、弱一致性业务场景。1. 执行逻辑业务应用写入数据时仅更新缓存即可立即返回成功结果无需等待数据库写入。缓存服务会异步、批量将缓存中的增量数据刷入数据库大幅提升接口吞吐能力。2. 解决问题完美适配超高并发写入场景避免大量高频写请求直接冲击MySQL导致数据库压力过载、宕机。3. 核心痛点存在数据丢失风险。若缓存节点在数据异步落库前宕机未同步至数据库的缓存更新数据会永久丢失无法恢复。4. 典型应用场景社交媒体统计数据点赞数、阅读量、浏览量等场景少量数据误差不影响用户体验但并发量极高无法直接落地数据库操作系统磁盘缓存系统write()文件写入调用采用的就是Write Back机制数据先写入内存Page Cache再由内核线程异步刷入硬盘。四、兜底方案-批量同步通过手动或者定时任务执行批处理任务作为一种补救措施也是冷数据系统参数、基础字典表预热的一种手段
缓存与数据库一致性的核心方案
缓存与数据库一致性的核心方案一、旁路缓存 (Cache Aside)缓存只是一个旁路边的辅助组件数据库才是真实的主数据源缓存不接管读写读写控制权全部交给业务代码。适用场景读多写少的业务场景是目前业务开发中最常用的缓存一致性方案。1. 核心执行逻辑读流程优先查询缓存若缓存未命中再查询数据库最后将数据库查询结果回写至缓存供后续请求复用。写流程先更新数据库再删除缓存数据。核心说明写操作优先选择删除缓存而非更新缓存。删除操作具备简单、幂等的特性能够有效规避并发写场景下的数据一致性问题避免缓存数据与数据库数据错乱。2. 核心痛点及解决方案痛点一高并发读写一致性问题受网络延迟、读写并发、数据库主从同步延迟、事务未提交等因素影响会出现缓存数据被污染的问题具体执行流程如下请求 A读发现缓存未命中从 DB 读取旧值 10。请求 B写更新 DB 为新值 20并成功删除缓存此时缓存为空。请求 A读由于网络延迟或 GC 停顿在请求 B 执行完删除后才将刚才查到的旧值 10 写入缓存。结果缓存中保存了旧值 10而 DB 中是新值 20造成长期的脏数据。常规优化方案延迟双删策略延迟时间常规设置为200ms~500ms错开读写并发的时间窗口避免旧数据回写缓存。痛点二缓存删除失败问题若直接删除缓存失败会导致缓存留存旧数据引发数据不一致。可将缓存删除操作交由MQ处理依托MQ的消息重试、持久化机制保障缓存删除操作最终执行成功。3. 终极解决方案Canal 监听 Binlog通过Canal组件监听MySQL的Binlog日志Canal会把自己伪装成从库发送dump 请求获取Binlog日志异步感知数据库数据变更自动执行缓存删除或更新操作。该方案对业务代码完全无侵入可靠性极高可同时解决上述两大痛点。方案核心原理MySQL 两阶段提交机制Prepare阶段InnoDB引擎将数据写入redo log日志并将事务状态标记为prepareBinlog写入阶段记录数据逻辑变更信息写入Binlog日志并刷盘持久化Commit阶段InnoDB将redo log事务状态更新为commit完成事务提交。MySQL宕机恢复机制若事务在Commit阶段宕机重启后MySQL会校验Binlog完整性。只要Binlog日志已完整写入即便redo log处于prepare状态MySQL也会判定事务有效并自动提交。因此只要Canal读取到Binlog日志即可判定数据库数据已提交生效以此保障缓存更新的准确性。方案优势传统MQ手动更新方案需改造业务代码针对Redis、ES、大数据平台等不同中间件单独发送消息代码冗余且扩展性差。而Canal可作为统一数据分发中心通过下游配置多组消费者分别处理Redis缓存更新、ES索引更新、HBase数据同步等需求大幅简化业务架构。4. 实战落地实际开发中可基于RedisTemplate、Jedis等主流Redis客户端二次封装通用的CacheService缓存工具类统一处理缓存查询、删除、更新等操作。二、读/写直通 (Read/Write Through)核心特性保障缓存与数据库强一致性适用于对数据准确性、一致性要求极高的核心业务场景。1. Read Through读直通由缓存服务统一接管数据查询逻辑。业务请求查询数据时若缓存未命中缓存服务主动同步查询数据库将数据加载至缓存后再返回结果给业务应用应用无需直接操作数据库。2. Write Through写直通由缓存服务统一接管数据写入逻辑。业务应用仅需写入缓存缓存服务会同步将数据更新至数据库仅当数据库写入成功后才向应用返回写入成功结果。3. 核心痛点所有读写操作均需同步联动数据库链路耗时较长接口响应延迟高并发性能较差。4. 技术实现Ehcache缓存框架原生提供CacheLoader读加载、CacheWriter写写入接口开发者完成配置后调用cache.put()等缓存方法框架会自动执行数据库CRUD操作无需手动编写SQL。三、异步写回 (Write Back / Write Behind)核心特性以数据一致性为代价极致提升写入并发性能适用于高并发、弱一致性业务场景。1. 执行逻辑业务应用写入数据时仅更新缓存即可立即返回成功结果无需等待数据库写入。缓存服务会异步、批量将缓存中的增量数据刷入数据库大幅提升接口吞吐能力。2. 解决问题完美适配超高并发写入场景避免大量高频写请求直接冲击MySQL导致数据库压力过载、宕机。3. 核心痛点存在数据丢失风险。若缓存节点在数据异步落库前宕机未同步至数据库的缓存更新数据会永久丢失无法恢复。4. 典型应用场景社交媒体统计数据点赞数、阅读量、浏览量等场景少量数据误差不影响用户体验但并发量极高无法直接落地数据库操作系统磁盘缓存系统write()文件写入调用采用的就是Write Back机制数据先写入内存Page Cache再由内核线程异步刷入硬盘。四、兜底方案-批量同步通过手动或者定时任务执行批处理任务作为一种补救措施也是冷数据系统参数、基础字典表预热的一种手段