场景 | Redis 和 MySQL 的数据同步

​ Redis 和 MySQL 一致性问题是企业级应用中常见的挑战之一，特别是在高并发、高可用的场景下。由于 Redis 是内存型数据库，具备极高的读写速度，而 MySQL 作为持久化数据库，通常用于数据的可靠存储，如何保证两者数据的一致性需要具体业务场景的设计与优化？

​ Redis 和 MySQL 的一致性保障在不同的业务场景中需要结合场景特性来进行权衡，主要的策略包括：

1. 旁路缓存模式（Cache Aside Pattern）：常用于读多写少的场景，写操作时删除缓存。
2. 异步更新（Write Behind）：先更新缓存再异步写入 MySQL，保证最终一致性。
3. 双写策略：同时更新 Redis 和 MySQL，配合事务机制确保一致性。
4. 延迟回写：通过定时批量写入 MySQL 减少频繁数据库操作。

方案一：旁路缓存模式（Cache Aside Pattern）

在大部分业务系统中，Redis 作为缓存层用于提升系统的读取性能，而 MySQL 作为持久化存储，用于保证数据的可靠性。

• 系统先查询 Redis 缓存，如果缓存中没有数据，再从 MySQL 中查询并将数据写入 Redis 缓存。
• 更新数据时，更新 MySQL 并删除 Redis 缓存，使缓存数据失效，保证下次读取时能拿到最新数据。

业务场景

​ 商品详情页面。当用户请求某个商品详情时，首先查询 Redis 缓存，如果缓存中没有，则查询 MySQL，将查询结果缓存到 Redis 中；如果商品信息发生变更时，更新 MySQL 并删除 Redis 中的缓存。

保障一致性

1. 缓存淘汰策略：MySQL 数据更新后立即删除 Redis 缓存，确保下次读取时能获取到最新数据。即通过 “删除缓存” 的方式避免脏数据存在于缓存中。
2. 并发问题：当并发请求较高时，可能会出现“缓存雪崩”或“缓存击穿”问题。例如：A 更新 MySQL 数据，B 在缓存失效的瞬间读取了旧数据，再次缓存到 Redis。为解决此问题，可以采用 延迟双删策略：
   • 删除 Redis 缓存。
   • 更新 MySQL。
   • 适当延迟（如 500ms），再次删除 Redis 缓存，确保在并发情况下不存在缓存不一致问题。

方案二：异步更新（Write Behind）

​ 在某些实时性要求较高的场景中，可以考虑先更新 Redis 缓存，然后再异步更新 MySQL 数据库。

业务场景

​ 秒杀系统。例如商品库存的扣减，用户购买商品时，首先更新 Redis 中的库存数量，保证极低延迟的实时性体验。然后将变更异步（消息队列）写入 MySQL，确保持久化存储的一致性。

保障一致性

​ Redis 作为前端实时数据的缓存，MySQL 作为后端数据的持久化存储，采用异步更新策略时，一致性无法保证是强一致性，但可以通过使用消息队列等手段来保证最终一致性。异步写入 MySQL 时，如果操作失败，可以通过重试机制或补偿机制恢复一致性。

重试机制是指在操作（如更新MySQL或删除Redis缓存）失败时，系统会自动尝试再次执行该操作的过程。这可以通过以下几种方式实现：

1. 自动重试：在发送更新操作到消息队列后，消费者在处理消息时可能会失败。消息队列通常会支持配置重试策略，如Kafka的重试策略配置。消费者可以设置重试次数和重试间隔，例如指数退避策略，以避免因临时网络问题或服务故障导致操作失败。
2. 手动重试：在某些情况下，可能需要手动触发重试机制。例如，如果一个操作失败了，系统可以将失败的操作记录到一个重试队列中，并在一定时间后重新尝试执行这些操作。

补偿机制是指在操作失败后，执行一些操作来恢复数据一致性的过程。以下是一些常见的补偿策略：

1. 消息队列补偿：如果更新MySQL后删除Redis缓存失败，可以将这个失败的操作作为一个消息发送到另一个消息队列（补偿队列）。然后，有一个补偿服务监听这个队列，并尝试执行相应的补偿操作，如再次删除缓存或执行其他恢复操作。
2. 业务层补偿：如果重试一定次数后操作仍然失败，可能需要在业务层进行补偿。例如，可以通知业务层这个失败，并由业务逻辑决定如何处理，比如人工介入或者执行一些特定的业务流程来恢复数据一致性。

方案三：双写策略

​ 有时业务需要同时更新 Redis 和 MySQL 的数据，如用户余额更新、积分奖励系统等场景中，Redis 和 MySQL 需要同步写入。

业务场景

​ 积分系统：用户消费时增加或减少积分，需要同时更新 Redis 和 MySQL 中的积分记录。

• 同步写入：当更新用户积分时，Redis 和 MySQL 同时更新数据。由于需要保证两个存储的同步性，必须考虑事务性问题。
• 分布式事务：如果系统架构分布式，可能需要使用分布式事务（如 2PC，或者更轻量的解决方案如 TCC）来确保一致性。

保障一致性

双写一致性问题：如果同时写 Redis 和 MySQL，可能会面临一致性问题。常见解决方案是通过事务补偿机制来实现。具体步骤：

1）使用数据库事务保证 MySQL 写入成功。

2）如果 Redis 写入失败，可以尝试重试，或在事务结束后通过补偿机制将失败的数据写入 Redis。

方案四：延迟回写

​ 数据回写模式适用于 Redis 作为缓存层，MySQL 作为持久化存储层，但 Redis 中数据修改后并不立即同步更新 MySQL，而是在特定时机触发数据回写。

业务场景

​ 广告计费系统：广告点击量保存在 Redis 中，以减少频繁的数据库写入压力，定期将 Redis 中的统计数据批量写入 MySQL。

• 可以通过定时任务或者触发器将 Redis 中的数据定期回写到 MySQL，这样既减少了 MySQL 的压力，又保证了数据一致性。

保障一致性

• 持久化与批量同步：通过 Redis 的持久化机制（如 RDB、AOF），在 Redis 崩溃时不会丢失数据。通过定时器或事件驱动系统触发批量同步 MySQL。

总结

​ 每种策略有不同的适用场景，设计时需要考虑一致性、性能和可用性之间的平衡

参考

• 一文彻底搞定Redis与MySQL的数据同步