做大数据架构这几年我被问得最多的一个问题就是HDFS、HBase、ClickHouse 都能存数据为什么还要专门引一套 Redis每次我都要花不少时间解释——在大数据链路里缓存工具不是“数据库的备胎”而是真正决定接口响应和任务稳定性的关键一环。今天就从我实际接触过的离线数仓、实时计算和数据服务化项目出发把 Redis 和 Memcached、Caffeine、Ehcache、Hazelcast、Ignite、Tair、Aerospike 这些常被放在一起比较的缓存工具放到大数据场景里逐项拆解讲讲各自的能力边界和选型逻辑。这篇文章不是教科书式的功能列表而是一份实战侧的对比笔记。适合正在搭数据平台、做实时接口服务、或者被面试官问到“为什么用 Redis 不用 XXX”的同学参考。1. 大数据缓存之问为什么数据都有了还要再快一层1.1 大数据链路里缓存的三个使命很多人理解缓存第一反应是“让查询变快”。这个理解没错但在大数据场景里不够完整。数据链路上游是 Hadoop、Spark、Flink下游是报表、大屏、推荐接口、运营后台。上游计算结果是批量的、分钟级甚至小时级产出的下游消费方却期望毫秒级拿到数据。这中间的落差靠硬调存储性能很难解决必须在中间加一层“记忆体”。我习惯把大数据场景下缓存的使命分成三类这样遇到选型问题就不容易跑偏。第一类是热点加速。比如实时大屏每秒刷新每次刷新都去查 ClickHouse 的聚合表QPS 一高ClickHouse 的查询队列就开始堆积接口超时是家常便饭。但如果把最近 5 分钟的聚合结果丢进 Redis大屏直接读缓存ClickHouse 的负载能降一个数量级。第二类是结果复用。数仓里一张指标宽表可能同时被七八个服务消费每个服务都自己跑一遍 Hive SQL 或者查一次 HBase资源浪费极严重。把计算结果写一份到缓存所有服务共享同一份数据既省计算资源又能保证各端看到的口径一致。第三类是状态协调。大数据任务天然是多节点并行任务之间经常需要“谁先跑完谁拿锁”“这批数据里哪些 ID 已经处理过”这类协调动作。Redis 的分布式锁、Set 去重、进度标记在这一层几乎是标配。1.2 缓存失效的代价从命中率到雪崩我见过不少团队上线缓存时只关注命中率命中率一低就加 TTLTTL 一加长数据又容易过期不新鲜。这种调优思路一开始就偏了。大数据场景里缓存失效真正可怕的不是命中率下降而是“整片失效”。原因很典型很多批量任务在每天同一时刻跑完往缓存里写数据时习惯性把 TTL 设成一样的值。结果就是所有 key 在同一分钟集中过期缓存被打穿所有请求同时回源打向下游数据库数据库连接池瞬间被拉满然后缓存被重建又因为流量太大重建失败形成恶性循环。我在一个项目里就踩过这个坑。定时任务每天凌晨 2 点写一批缓存TTL 统一设 2 小时凌晨 4 点到 6 点之间缓存几乎全部过期而那时候正好是运营后台的访问高峰。后来改成 TTL 加随机偏移比如 7200 秒基础值加 0 到 900 秒随机数让过期时间分散开情况立刻缓解。失效原因典型影响规避手段批量写入 TTL 相同缓存集中过期回源流量打爆数据库TTL 增加随机偏移错峰过期热点 key 过期瞬间单 key 大量请求同时回源热点 key 不设过期靠主动更新缓存穿透查询不存在的数据打到数据库布隆过滤器或空值缓存大数据场景里缓存失效不是“等它慢慢恢复”就行的事。一次雪崩可能把上游任务也拖死恢复时间以小时计。所以做缓存方案之前先想清楚三个问题数据能不能丢丢了影响多大回源能不能扛住这三个问题没想明白后面所有优化都是空中楼阁。2. Redis 的看家本领从数据类型到原子操作它不只是快2.1 五种基础类型在大数据链路里的典型用法Redis 常被拿来和其他缓存工具比“谁更快”但真正让它在数据领域站稳脚跟的其实是数据结构。同样是缓存Memcached 只能存字符串而 Redis 的 String、Hash、List、Set、ZSet 五种基础类型几乎覆盖了数据链路里所有常见的临时数据形态。拿我做过的一个网约车项目举例。司机维表存在 MySQL 里每次接口查询都要关联司机信息如果每次都回 MySQL 查数据库压力很大。我把维表按城市维度灌进 Redis Hashkey 是“city:driver:10001”field 是司机 IDvalue 是司机信息的 JSON一次 HGETALL 就能拿到整个城市的司机集合接口延迟从 200 毫秒降到 2 毫秒。Hash 之外另外几种类型也是高频工具。String 用于计数器比如实时计算里统计某订单的累计金额INCRBY 一把梭。List 在轻量场景里可以做消息队列LPUSH 生产、BRPOP 消费虽然比不上 Kafka 可靠但配合短任务列表绰绰有余。Set 用来做去重集合比如“这批数据里哪些用户已经领过优惠券”SADD 之后 SCARD 看数量SISMEMBER 判断是否已存在跨任务共享同一个集合非常方便。ZSet 做排行榜和 TopN 是杀手级用法一个 ZADD 下去按 score 排序的需求立刻满足ZREVRANGE 直接取前 100不用在应用层排序。在大数据任务里这些数据结构的价值在于“服务端计算”。数据不用拉回客户端Redis 内部就把交集、并集、排名算好了。这对网络带宽的节省非常可观。2.2 容易被忽略的高级结构Bitmap、HyperLogLog、Stream基础类型之外Redis 还有三个高级结构在大数据场景里经常比基础类型更出彩但很多同学没用到。第一个是 Bitmap。做日活统计时一个用户占 1 bit一亿用户也就 12MB 左右内存。每天一个 key用户 ID 作为 offset 置 1BITCOUNT 直接给出当日活跃数。更难得的是可以做跨天位的“与”“或”运算比如要算“昨天和今天都活跃的用户是多少”一个 BITOP AND 就出来了不用去数仓做 join。这个操作放在 Hive 里跑规模一大就是几百亿行扫描而 Bitmap 在 Redis 里是纯内存位运算毫秒级返回。第二个是 HyperLogLog。如果你只需要知道“大概有多少”不需要精确值它极其好用。比如实时大屏的 UV 展示误差 0.81%但一个 HyperLogLog key 最多占 12KB 内存。我见过有人硬用 Set 存几百万用户 ID 来做 DAU几个亿的数据量把 Redis 内存顶爆换成 HyperLogLog 之后内存占用从 GB 级降到 KB 级查询还是毫秒级。要注意的是 PFCOUNT 是近似值不能用于对账只能用于看板展示。第三个是 Stream。Redis 5.0 引入的 Stream 数据结构支持消费组、消息回溯、Pending 列表在很多轻量级大数据组件之间可以充当缓冲层。比如 Flink 任务产出的实时告警事件不想再引入一套 Kafka直接写到 Redis Stream告警服务用消费组读取比 List 模拟的队列可靠得多。2.3 单线程模型、多线程 IO 与持久化取舍Redis 为什么快这个问题面试里几乎必问。核心就三点纯内存操作、单线程避免锁竞争、I/O 多路复用。单线程带来的副作用也很直接——一个慢命令会阻塞后面所有命令。网上一搜“Redis 慢查询”能出来一堆案例大部分是有人在生产环境执行了 KEYS或者对一个超大集合执行了 SMEMBERS结果整个 Redis 卡了几秒。需要注意Redis 6.x 之后引入了多线程 I/O但只是把网络读写分散到多个线程核心命令执行依然是单线程。所以瓶颈在网络时多线程有帮助瓶颈在慢命令时换了也白换。持久化方面RDB 是定期快照恢复快但可能丢数据AOF 是追加日志可以做到每秒刷盘甚至每次写都刷盘但文件大、恢复慢。大数据场景我的实践建议是如果 Redis 只做缓存关掉持久化最省事如果 Redis 里放着不能丢的分布式锁状态或任务进度开 AOF 且 everysec 刷盘足够如果数据真的重要到一分一秒都不能丢别依赖 Redis 的持久化数据应该直接写真正的存储系统。Redis 持久化是兜底不是主存储方案。3. Redis 与 Memcached 的分水岭在大数据侧谁更容易踩坑Memcached 是 Redis 出现之前最流行的分布式缓存今天依然有不少老系统在用。两者对比网上能查到一堆表格但那些表格大多停留在“Redis 支持丰富数据结构Memcached 只支持 KV”这个表面。在大数据场景里这个差异会带来非常具体的工程问题。3.1 数据结构与原子操作get/set 之外的能力差距Memcached 的模型非常简单key-valuevalue 是字符串API 主要是 get、set、add、delete、incr/decr。在大数据侧这个简单模型很快就碰到天花板。举个例子。数据分析师要圈选“过去 7 天活跃且消费过的人群”这个集合可能有几百万个用户 ID。如果放在 Redis 里用 Set 存每天的活跃用户然后 SINTERSTORE 取 7 天交集结果直接在服务端算完返回。如果用 Memcached只能把每一天的用户 ID 列表全部拉回应用服务器在内存里做交集几百万字符串的传输量会瞬间吃掉网络带宽。再比如分布式锁。Redis 可以用 SET key value NX EX 一条命令完成加锁配合 Lua 脚本保证判断和删除的原子性。Memcached 虽然有 add 命令可以做“只有 key 不存在时才写入”的原子操作但后续怎么判断持有者、怎么续期、怎么安全释放协议层面几乎没有帮忙。我还有一次血的教训。项目的缓存层用 Memcached 存了一个 JSON 字符串的配置两个服务同时读改写同一份配置因为没有 CAS 或者 Lua 这种原子操作最终一个服务覆盖了另一个服务的修改配置丢失。这类问题在 Redis 里可以用 WATCH 配合 MULTI或者干脆用 Lua 脚本在服务端执行Memcached 则只能靠客户端加锁复杂度高不少。3.2 内存管理与淘汰策略的差异Memcached 的内存管理走 slab 分配机制内存按固定大小分成一系列 slab class每个 class 里存放相近大小的对象。它的好处是内存碎片少、分配效率高坏处是如果 value 大小分布不均匀会出现内存浪费。比如一个 slab class 的 chunk 是 512KB但实际存的是 400KB 的 value剩下的空间就浪费了。Redis 没有 slab 这种预分配机制但它的过期删除是惰性删除加定期删除的组合淘汰策略支持 LRU、LFU 以及 noeviction。在大数据场景里我更关注的是淘汰策略的选择如果 Redis 被当作用户维度缓存的临时结果用 allkeys-lru 比较合适如果是计数器或者分布式锁一旦被淘汰就会出问题建议用 noeviction 明确的过期时间宁可报错也不要默默丢数据。内存对比上Memcached 的 value 上限是 1MBRedis 的 value 理论上可以到 512MB。大数据场景里经常有超过 1MB 的缓存对象比如一次要返回几万行的维表结果Memcached 直接写不进去。这也是选型时容易被忽略的点。3.3 什么场景依然值得用 Memcached说了这么多 Redis 的优势Memcached 也不是一无是处。它的多线程模型让它在高并发纯 KV 场景下扩展性很强CPU 多核利用比单线程 Redis 更有优势。如果业务形态极其简单——就是存一个几 KB 的 JSON 或者 HTML 片段读多写少TTL 短那么 Memcached 更轻、更稳、更好维护。我现在的选型标准很简单缓存对象是否需要数据结构操作是选 Redis否但 value 很小且 QPS 要求极高Memcached 可以纳入考察。大数据项目里确实遇到过这类场景广告点击日志的透传缓存key 是请求 IDvalue 是一小段原始日志两小时过期QPS 峰值几十万。这种场景 Memcached 完全能胜任而且比 Redis 省内存。但如果你在做的是数据服务化、实时大屏、分布式任务协调这类偏复杂链路Memcached 的能力缺口会随着业务发展越来越大。我的经验是新项目不要选 Memcached老项目如果没有数据结构需求继续用着也没问题不必为了换而换。4. 本地缓存双雄Caffeine 与 Ehcache 在大数据链路中的位置说到缓存很多人只想到 Redis忽略了“本地缓存”这一层。大数据服务端经常是 JVM 应用进程内缓存用得非常多。Caffeine 和 Ehcache 是 Java 生态里两个绕不开的身影它们的定位和 Redis 完全不同但又互补。4.1 本地缓存与分布式缓存的边界本地缓存活在应用进程里Redis 是独立的分布式缓存服务。这个区别直接决定了一致性模型。本地缓存的查询路径最短——内存里直接拿没有网络开销所以它一定是所有缓存里最快的。但它有天然缺陷进程重启数据就没了多实例部署时各节点数据不一致更新某个 key 时无法通知其他节点。Redis 正好相反一次写入全局可见进程重启缓存还在只要配置了持久化缺点是每次读写都有一次网络 RTT。在大数据链路里这两类缓存的分工很清晰。Redis 管跨节点共享的数据比如实时榜单、全局配置、分布式锁本地缓存管单个实例内部的复用比如维表查询结果、服务间调用的响应体、反复使用的配置对象。4.2 Caffeine 与 Ehcache 的选型要点Caffeine 是 Java 界目前公认最强的本地缓存库基于 Window TinyLFU 算法命中率高API 现代Spring Boot 里默认的本地缓存就是 Caffeine。它适合高并发、低延迟的接口层热点数据几百毫秒内重复读取的情况命中率能到 99% 以上。Ehcache 则是老牌选手功能更重。它支持堆外内存、磁盘存储、JTA 事务、分布式集群同步缓存的持久化和恢复机制比较完整。代价是 API 风格偏老性能上限比 Caffeine 低。我一般只在需要“本地缓存还要能落盘、重启不丢”的场景里才考虑它普通接口服务用 Caffeine 就好。两者的典型结合方式是二级缓存Caffeine 做 L1 一级缓存Redis 做 L2 二级缓存。读路径是 L1 未命中读 L2L2 未命中回源数据库再层层写回写路径是更新数据库后先删 Redis再在本地缓存里也做失效。这个模式能大幅降低 Redis 的读压力但要注意一致性我通常会给数据加版本号本地缓存里带上版本后台更新时通过版本号主动失效。4.3 大数据算子内缓存和 Redis 的配合模式很多人写 Spark 或 Flink 任务时直接在 map 或 flatMap 里逐条查 Redis遇到几个亿条数据就悲剧了。每条数据一次网络 RTT哪怕 Redis 再快几十万条并发的网络回环延迟也能把任务拖死。正确做法是在算子内部用 Caffeine 做批内缓存。比如数据流中的每个用户 ID 都要关联城市维表一百个字段里可能只有五六个城市在变完全可以在 Executor 内部先查一次 Redis把城市维表加载到本地缓存后续数据直接读本地Redis 查询次数能降 90% 以上。这个模式有两个坑需要注意。一是内存Executor 本地缓存如果无限膨胀会挤占 Spark 的执行内存必须设置 maximumSize 和 expireAfterWrite。二是数据新鲜度本地缓存的 TTL 不能设太长否则上游维表更新了下游任务还在用旧数据建议 TTL 设在 5 到 10 分钟配合 Redis 主动版本失效机制。5. 分布式内存网格Hazelcast 与 Apache Ignite 是缓存还是计算引擎Hazelcast 和 Apache Ignite 经常被归入“分布式缓存工具”的类别和 Redis 放在一起对比。但从大数据工程的角度看我更愿意把它们称作“内存数据网格”。这个定位差异会直接影响你对它们的期望值。5.1 数据网格和缓存的本质区别Redis 的核心能力是数据结构操作它的计算是在数据很小、逻辑很简单的场景下做的比如集合运算、Lua 脚本。Hazelcast 和 Ignite 走的是另一条路数据分布到集群各节点后计算可以在数据所在的节点本地执行再把结果汇总也就是“移动计算而非移动数据”。Ignite 支持标准 SQL、分布式 Join、分布式聚合还能把一部分计算下推到数据侧。这意味着如果你有一份很大的数据在内存网格里可以直接写一条 SQL 做 count、group by、join获取聚合结果不用像 Redis 那样把几千万条 key 全量拉回客户端再自己算。Hazelcast 的 EntryProcessor 机制类似可以在缓存条目所在的节点上执行一段 Java 代码做更新。比如某个字段需要累加值Redis 会建议你用 INCRHazelcast 则允许你传一个函数进去在数据节点上执行并返回结果灵活性高很多但也意味着你需要写业务逻辑部署到缓存节点上。5.2 什么时候选择数据网格而不是 Redis我总结过选型判断标准。如果只是“热点结果缓存”比如把聚合结果存储起来按 key 查询Redis 足够如果你希望在缓存层直接做实时查询比如“查询最近一小时所有订单中金额大于 1000 的订单按城市分组统计”并且数据量上千万Ignite 这类工具会让 Redis 舒服得多。Ignite 还有一个和 Redis 差异极大的能力原生持久化。它可以把数据从内存落到磁盘支持 SQL 实现“缓存即存储”而 Redis 持久化更像备份机制不能支撑复杂查询。在需要“快速写入实时查询可靠存储”三合一的场景里Ignite 是强有力的竞争者Redis 则需要配一个真的数据库才能达到同等效果。但这不代表 Ignite 是随便就能上手的。我见过一个团队把 Ignite 用成了“二号 HBase”最后集群内存水位一直下不来分区再平衡常常阻塞运维同学苦不堪言。数据网格的复杂度、集群拓扑、内存管理、故障转移都比 Redis 重得多。如果团队只有两三个人管系统建议先用 Redis真扛不住时再考虑上数据网格不要一上来就为了“将来可能用到 SQL”而自找麻烦。5.3 Redis Cluster 与数据网格的高可用对比部署形态上Redis Cluster 是分片 主从16384 个 slot 按节点分配扩容时要做 slot 迁移故障转移靠主从自动晋升。整体机制成熟但槽位迁移期间会有性能抖动需要提前测。Ignite 和 Hazelcast 的分区模型更“自然”数据分片自动平衡节点加入离开后会自动重新分布副本不需要管理员手动指定槽位。它们的客户端可以感知拓扑变化某个节点挂掉后请求自动转向副本节点。从高可用能力看数据网格比 Redis Cluster 更灵活但代价是网络开销更大节点间通信也更多集群规模一大管理复杂度上升明显。在超大规模场景下Redis 的优势反而突出协议简单、运维习惯成熟、监控指标丰富数据网格的各种能力是要用复杂运维来换的。所以我的建议依然是先用 Redis让系统先跑起来等真的遇到计算下推、SQL 需求时再评估是不是该换。6. 大规模场景下的补位者Tair、Aerospike 与 Redis 生态6.1 Redis Cluster 撑不住时的几种方向Redis 虽好但也会碰到两个硬性问题。一是内存有限数据量过了几百 GB 后纯内存方案的成本陡增二是单线程模型极端高并发下 CPU 会成为瓶颈。Redis Cluster 能解决一部分扩展问题但内存成本没办法靠集群本身解决。这时候常见方向有几种。一是用 Tair 这类兼容 Redis 协议的分布式系统它在阿里内部经历过大规模生产检验支持持久化和多副本客户端生态可以无缝迁移。二是用 Aerospike 这类内置 SSD 持久化方案的高并发 KV 存储延迟仍然很低但单机容量可以做到 TB 级成本比纯内存低很多。三是用 Pika 这种兼容 Redis 协议的磁盘存储把冷数据换到 SSD。还有一些方案是干脆把数据放回 HBase 或 ClickHouse让 Redis 只承载热点这其实是最朴素也最稳妥的做法。我在一个广告推荐项目里见过内存预算卡死的案例。Redis 集群存了几十亿条用户特征 KV双副本后单机内存开销巨大每加一台机器都像在烧钱。后来把数据切到 Aerospike内存集群缩到几台专门放热数据整体成本降了一个量级接口延迟还更稳了。6.2 Aerospike 在高并发 KV 场景的特别之处Aerospike 是广告、推荐系统里的常客它的核心优势不是单机 QPS 比 Redis 高多少而是“内存 SSD 混合持久化”的架构。对大多数 KV 而言热点数据在内存里冷数据自动落到 SSD但读取延迟依然只有 1 毫秒上下不会像 MySQL 那样把磁盘当主力存储。它的数据分片机制也比 Redis Cluster 更自动集群节点变化后会自动做数据重新分布。比较有意思的是Aerospike 还支持在服务端做简单的表达式过滤和聚合虽然不是 SQL但在画像筛选场景里能省不少网络传输。缺点也很明显。一是生态远不如 Redis客户端语言的成熟度、工具链、文档都差一个身位二是它把数据当成存储管理运维口径和缓存差别很大不能像 Redis 那样随手 FLUSHALL三是一些高级操作如 Lua 脚本、复杂数据结构完全没有。所以 Aerospike 适合的是“KV 量大、要持久化、QPS 极高”的场景而不是普通缓存的替代品。6.3 Tair 与 Redis 生态的兼容与增强Tair 是阿里巴巴开源的分布式 KV 系统重点在于生态兼容。很多组件直接兼容 Redis 协议业务把连接地址一换就能从 Redis 迁移过去。它比较好的点是支持强一致的多副本同步、主备切换、持久化解决了 Redis 主从异步复制可能丢数据的问题。对于已经深度使用 Redis 的团队如果遇到“Redis 主从切换丢了分布式锁导致任务重复执行”这类问题又不想把系统改成另一套存储走 Tair 兼容版是比较平滑的路。但要提醒的是Tair 的版本、部署形态、变体很多有的模块开源有的能力依赖云厂商内部版本选型前要看清楚到底是自建开源版还是云服务版两者功能差异不小。工具生态在落地时的作用经常被低估。Redis 有雷打不动的 redis-cli有 RedisInsight、Another Redis Desktop Manager 这类可视化工具很多运维脚本、监控面板、SDK 都是现成的团队的迁移成本和学习成本都很低。这一整套生态是 Redis 面对 Tair、Aerospike 们时最值得重视的隐性资产。7. 实战选型与治理从集群部署到缓存治理的经验记录7.1 集群部署主从、哨兵、Cluster 怎么选实战中部署形态没有标准答案我一般按三个档次做决策。缓存不重要且数据量小单机 Redis 够用顶多配一个从节点做备份。高可用要求上来后用主从加哨兵。哨兵负责自动故障转移应用层通过哨兵拿主节点地址挂掉时哨兵会推举新的主节点切换期间可能有秒级不可用但大多数大数据服务可以容忍。数据量大、QPS 高的时候直接用 Redis Cluster让数据分片到多节点官方方案虽然没有哨兵那套独立监控但故障转移和分片是内置的。部署环境如果是 Docker我推荐用 docker-compose 快速搭一套实验环境。以下是我常用的一键主从示例version: 3.8 services: redis-master: image: redis:7.2 container_name: redis-master command: [redis-server, --appendonly, yes] ports: - 6379:6379 volumes: - ./master-data:/data redis-replica: image: redis:7.2 container_name: redis-replica command: [redis-server, --slaveof, redis-master, 6379, --appendonly, yes] depends_on: - redis-master ports: - 6380:6379 volumes: - ./replica-data:/datadns 解析用 docker compose 内置网络replica 会自动从 master 同步数据。需要提醒的是这只是实验环境生产环境不要这样裸跑至少把密码、持久化策略、内存限制补上。7.2 缓存治理Key 设计、过期策略、Big Key 与热点 KeyKey 设计是第一道治理关卡。我见过最乱的 Redis 是那种一个业务一种风格有的用冒号有的用下划线前缀完全没有统一出了问题排查半天不知道 key 是哪个业务写的。实践上推荐“业务:领域:ID”的三段式比如“order:paid:20250101:12345”既方便人工识别也方便用 SCAN 按前缀统计。过期策略要按业务类型分开。接口结果缓存建议 1 到 10 分钟加随机偏移维表缓存可以半小时到一小时但要配合版本号主动刷新分布式锁不建议设很短的 TTL锁的过期时间应该根据任务最大执行时长留足余量同时用看门狗机制自动续期。Big Key 和热点 Key 是大数据场景里的高频事故源。一个 Hash 里塞了几十万个字段每次 HGETALL 都造成大流量这是典型的 Big Key 问题应该拆成多个小 Hash 分片。热点 Key 是某个 key 被大量请求同时打到比如双十一大屏上的“总成交额”计数器几万个客户端同时读一个 keyRedis 单实例 CPU 被打满。解决方案是本地缓存加 Redis 读取合并把命中热点 key 的请求在服务端合并成一次或几次 Redis 调用。还有两个命令层面的铁律生产环境禁用 KEYS用 SCAN 代替线上慎用 MONITOR它会让 Redis 变慢。慢查询日志打开慢命令阈值建议设在 100 毫秒以下定期分析。可以使用如下配置slowlog-log-slower-than 10000 slowlog-max-len 128单位是微秒10000 微秒等于 10 毫秒阈值可以按业务实际情况调整。7.3 分布式锁在实时任务与调度里的坑大数据任务调度里分布式锁用得极多。典型场景是多个定时任务同时跑完都要写同一张统计结果表不加锁就会重复写入甚至数据错乱。最原始的实现是 SETNX 加 DEL但释放锁时容易误删别人的锁。更稳的写法是 SET key value NX EX 加 Lua 脚本保证原子性value 放一个唯一请求 ID释放时先比对再删除。代码大概是这样if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这个实现能解决绝大多数场景。但要注意分布式锁不是万能的。锁过期会导致任务并发执行加锁只能做互斥不能做幂等。我的习惯是大数据任务里加锁之外再配一个数据库唯一键或者版本号双保险才敢放心。Redisson 的分布式锁内置了看门狗续期逻辑能降低锁过期问题但 RedLock 这种多节点红锁方案在工程界一直有争议我的个人观点是大数据集群内同一机房的 Master-Slave 结构用 Redisson 的普通锁足够不需要过度设计。8. 一次离线数仓项目里Redis 到底承担了哪几个角色前面讲了很多理论最后用一个我做过的网约车离线数仓项目收尾这样对 Redis 在大数据链路中的真实位置会有更直观的感觉。这个项目的技术栈是 Hive 数仓加 Spark 计算加数据服务层。一开始 Redis 的角色只有一个就是给实时大屏缓存聚合结果。后来业务复杂起来Redis 的用法越来越多最终承担了至少五个角色。第一个是维表缓存。司机、城市、订单状态这些维度数据如果每次都从 MySQL 查服务接口根本扛不住。我把热门的维度表预加载到 Redis Hash应用服务一次 HGETALL 拿全量再本地 Caffeine 存副本MySQL 的压力几乎降为零。第二个是结果缓存。报表系统每天凌晨产出指标运营后台白天读。结果直接写 Redis String后台接口读不到缓存再回源 Hive 或 MySQL。大部分查询都是毫秒级返回。第三个是 UV 去重。活动运营要看实时参与人数百万级用户用 Set 做去重内存会爆我用 HyperLogLog误差在可接受范围内存开销不到 12KB。第四个是实时排行。司机完成订单数、用户邀请排行这些都是 ZSet 的天然场景ZADD 更新成员分数ZREVRANGE 取 Top100几十毫秒出结果。第五个是分布式锁。凌晨批量任务同时跑多个任务都要写同一天的汇总表我用任务日期作为锁粒度在 Redis 里 setnx 加锁配合 Lua 释放确保同一时间只有一个任务在写。踩过的坑也值得一提。大屏接口的缓存 TTL 最初设成 2 小时结果每天凌晨任务写完后 2 小时整点所有请求同时回源HDFS 源表查询又慢接口一度 5 秒超时。后来改成 30 分钟基础值加随机 0 到 15 分钟偏移加上 Caffeine 本地兜底这个问题再没出现过。做大数据项目的这些年我越来越认同一个观点Redis 能成为默认缓存不是因为它在某个维度上碾压所有对手而是因为数据结构和分布式场景配合得最顺手。如果整篇文章只留一条经验那就是先定义清楚“缓存里的数据可不可以丢、过期了回源能不能扛住”再决定要不要接 Redis、要不要开持久化、要不要上集群。这个顺序一定不能反。