MySQL与Redis不能形成原子事务，导致缓存一致性问题。标准实践采用Cache Aside模式：业务操作先提交MySQL，再删除Redis缓存并设置TTL。需防范删除失败导致的脏数据残留，通过异步重试队列、死信处理和实时监控缓解。热点Key需额外控制并发回源，如使用Singleflight限流、版本号校验或Lease令牌机制。多级缓存场景需广播失效事件并设置本地缓存短期TTL。最终一致性依赖严格流程：事务提交后删除缓存，同时结合业务级别控制（基础级：TTL+删除失败告警；可靠级：异步重试+补偿任务；平台级：Outbox+CDC+失效广播）。核心风险需通过版本化、延迟双删和合理SLO监控平衡。

Redis 快，主要不是因为某一个原因，而是多个设计共同作用的结果： 内存操作 + 单线程模型 + IO 多路复用 + 高效数据结构 1. 单线程模型：避免复杂的线程竞争 Redis 的核心命令执行长期以来主要是单线程模型。 也就是说，大部分命令是由一个主线程顺序执行的。 这样有几个好处：