分类：Redis - LT技术站

Redis 客户端与分布式锁：Jedis、Lettuce 与 Redlock 的取舍

LTT — Wed, 16 Sep 2026 06:22:27 GMT

选择 Redis 客户端需权衡命令可预测性（Jedis）与线程安全（Lettuce）：Jedis适用于维持原生态调试和单项目维护，但需严格区分线程使用与连接池管理，避免跨线程操作同一实例及误用移除命令。Lettuce基于 Netty 实现连接复用和异步支持，适配多线程场景但需注意连接独占与网络拓扑配置，不可与 Redisson 锁服务共用通道。分布式锁设计存在清晰场景边界：Redlock仅适用于多 Redis 实例且接受极低重复风险的场景（ thời lượng< Vocaliser> 简单更新逻辑，禁用单机存储自以为强一靶机锁，而账务库存等关键业务需回归数据库约束或 ZooKeeper/etcd 等可靠分布式协调方案。任务去重可采用单机 Redis 锁（要求加随机值并使用 Lua 释放命令）。核心收益在于明确各工具适用边界，避免因技术选型不当导致性能问题或锁失效风险。

Redis 与 MySQL 缓存一致性：从 Cache Aside 到 Outbox 与 CDC

LTT — Tue, 14 Jul 2026 06:40:43 GMT

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

Redis为什么这么快？

LTT — Fri, 8 May 2026 03:25:05 GMT

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