17370845950

先更新数据库再操作缓存，确保数据一致；推荐事务提交后删除或更新缓存，避免回滚导致污染；高并发下可用延迟双删减少旧数据重载风险；复杂系统可结合Binlog或消息队列异步同步缓存；读操作优先查缓存以减轻数据库压力，但强一致性场景应直连数据库；核心是保证事务成功后再处理缓存，缓存仅为加速手段，数据以数据库为准。

在使用 MySQL 事务时，结合缓存可以提升系统性能，但必须注意数据一致性。事务的原子性和缓存的异步特性容易导致脏读或数据不一致。关键在于：先操作数据库事务，再更新或清除缓存，确保缓存状态与数据库最终一致。

1. 先更新数据库，再操作缓存

这是最推荐的做法。在事务提交后，再对缓存进行处理，避免事务回滚导致缓存污染。

• 开启事务，执行写操作（INSERT/UPDATE/DELETE）
• 提交事务
• 事务成功提交后，删除或更新对应缓存键

2. 使用延迟双删策略防止并发问题

在高并发场景下，可能有请求在事务提交和缓存删除之间读到旧数据并重新写入缓存。可采用“先删缓存 → 提交事务 → 延迟再删一次”的方式降低风险。

• 第一步：删除缓存
• 第二步：执行数据库事务
• 第三步：事务提交后，等待几毫秒，再次删除缓存

3. 结合 Binlog 或消息队列实现缓存同步

对于复杂系统，可通过监听 MySQL 的 Binlog（如使用 Canal）将数据变更异步通知到缓存服务。

• 事务提交后生成 Binlog 记录
• 消息中间件消费变更事件
• 根据事件类型清理或刷新缓存

4. 读操作优先从缓存获取

在事务不影响读路径的前提下，查询尽量走缓存，减轻数据库压力。

• 先查缓存是否存在数据
• 缓存未命中时查询数据库
• 将查询结果写入缓存，并设置合理过期时间

基本上就这些。核心是保证数据库事务成功后再处理缓存，避免数据错乱。缓存只是加速手段，数据源仍以数据库为准。设计时要考虑失败重试、缓存穿透和雪崩等问题。不复杂但容易忽略细节。