Redis vs Alluxio：从缓存原理到大数据场景选型与组合实践

1. 先聊一个大家都会遇到的选型困境：缓存到底选谁

先从我最近的实际经历说起。前阵子团队在重构一条数据服务链路，场景是这样的：底层数据落在 HDFS，Spark 每半小时跑一次批作业生成指标结果，下游是一个实时查询服务，要求 P99 延迟在 200ms 以内。架构评审会上，大家自然聊到了缓存层的选型，有人提议直接用 Redis，因为团队对它最熟，运维体系也成熟；也有人提出应该上 Alluxio，理由是它可以和 Spark、HDFS 无缝衔接，能避免重复跑批。

这个场景我相信很多做大数据平台的同学都遇到过。表面上是在选缓存组件，实际上面临的是两个完全不同层面的问题：你要缓存的是"经过计算后的结果数据"，还是"计算过程中反复读取的源数据/中间数据"？这俩问题的答案，直接决定了 Redis 和 Alluxio 谁更合适，甚至决定了你是否需要同时上两个。

这篇内容我就围绕这个核心矛盾，把我压测和落地过程中的实际数据、踩过的坑、以及最终沉淀下来的选型决策框架完整梳理一遍。文章里我不会只讲概念，Redis 和 Alluxio 的原理网上都写烂了，我更想聊的是：它们在真实大数据链路里各自扮演什么角色、什么场景下谁顶不住、什么场景下你以为能用其实不能用，以及两者如何共存。适合正在做实时数仓、数据服务化、湖仓一体架构的读者参考，也适合那些在技术选型评审会上被问到"缓存为什么不用 Redis"时不知道怎么回答的朋友。

2. 从本质差异说起：Redis 缓存的是热数据，Alluxio 加速的是数据访问路径

很多同学容易把 Redis 和 Alluxio 都归类为"缓存"，但它们的定位差异非常大，这个差异决定了使用方式完全不同。我在团队里经常用一个类比来解释：Redis 是"货架"，你把卖得最快的商品摆在最显眼的架子上，顾客来了直接拿走；Alluxio 更像是"传送带"，它改变的是货物从仓库到柜台的搬运方式，让搬运速度变快，而不是替你存一份商品副本。

2.1 Redis 的本质：以内存为介质的键值存储，核心是"命中"

Redis 本质上是一个内存数据结构存储系统，它的数据模型是 Key-Value，支持 String、Hash、List、Set、ZSet 等丰富的结构。在缓存场景下，它的工作方式非常简单直接：应用先去 Redis 查，命中了就直接返回，没命中再回源到数据库或下层存储，然后把结果写回 Redis，设置一个过期时间。

这里有个容易被忽视的关键点：Redis 能加速的前提是"数据放得下"。它把全部数据都存在内存里，所以它的容量边界就是内存边界，这就是为什么在纯内存数据库里，Redis 的定位是"缓存热点数据"，而不是"缓存所有数据"。

我在实际项目中见到过太多把 Redis 当万能缓存的案例。比如有个团队要把一张 200GB 的用户维表全量 Load 进 Redis，美其名曰"加速查询"，结果 Redis 内存从 16GB 直接飙到 48GB，主从同步延迟从毫秒级涨到几秒，最终因为内存碎片和持久化阻塞导致集群雪崩。这就是典型的定位错位：Redis 适合存的是访问频率高、单条数据量小、总量可控制在内存规模内的数据，而不是"为了加速就把所有数据扔进去"。

Redis 的命中率和性能之间是强相关关系，但很多人忽略了"未命中回源"的代价。假设 Redis 的吞吐能做到 10 万 QPS，但命中率只有 80%，那就意味着底层存储要承受 2 万 QPS 的回源压力。如果你的底层存储扛不住这 2 万 QPS，Redis 再快也没用，反而会成为雪崩的加速器。

2.2 Alluxio 的本质：分布式存储与计算框架之间的数据编排层

Alluxio 的定位和 Redis 完全不同。它是以内存为中心的分布式虚拟文件系统，处于计算框架（Spark、Presto、Flink、MapReduce）和底层存储系统（HDFS、S3、OSS、Ceph）之间。

它做的事情用一句话概括：把底层存储的数据缓存到靠近计算节点的位置，并向计算框架暴露统一的文件接口。也就是说，Spark 在计算时不需要每次都从 HDFS 拉数据，而是可以从 Alluxio 直接读已经被缓存的块，或者从 Alluxio 读取已计算好的中间结果。

我第一次理解 Alluxio 的价值时，印象最深的是这个场景：两个 Spark 作业，A 作业读同一份 HDFS 日志做清洗，B 作业也需要这份清洗后的数据。传统架构下，B 作业要重新跑一遍清洗逻辑，或者把 A 的中间结果写到 HDFS，B 再读一次。如果中间结果落在 Alluxio 里，B 作业直接读 Alluxio 缓存的数据即可，避免了重复的读取和计算开销。

这种"跨作业、跨引擎的数据共享"是 Redis 根本做不到的。Redis 的数据模型决定了它不认识文件、不认识数据块，它只认 Key。如果你要跨作业共享数据集，你要么自己把数据按 Key 拆成无数小对象存进 Redis，要么放弃这个方案。而 Alluxio 天然是把数据当"文件/数据块"来管理的，这和 Hadoop 生态的语义完全一致。

既然 Redis 是货架，Alluxio 是传送带，那"传送带"到底解决了什么问题？我总结为三个层次：

第一，访问距离问题。计算框架和底层存储分离时，每次读数据都要走网络。Alluxio 把数据缓存到本地或近端节点，把"远端读"变成"本地读"，IO 路径大幅缩短。第二，存储压力问题。没有被 Alluxio 缓存命中时，所有读请求直接打到 HDFS 或 S3，底层存储的 QPS 压力非常大。有了 Alluxio 做中间层，热数据从 Alluxio 走，底层存储只需要处理缓存未命中的请求，压力小很多。第三，跨作业共享问题。中间结果写入 Alluxio，而不是每次都回写 HDFS，省掉了大量的重复计算和重复 IO。

2.3 两者最核心的差异：数据语义不同

用一张表可以直观对比两者的差异：

Redis 更像是"最终一致性语义下的短期热点存储"，而 Alluxio 是"保证数据可见性的大数据加速层"。如果你非要让 Redis 去处理大数据量的文件读取，你会发现做事方式非常别扭：要把文件拆成 Key，还要自己管理文件块的元信息，Redis 的 String 类型虽然支持大 Value 但性能会剧烈下降。反过来，如果你想用 Alluxio 去缓存一个用户购物车的热点数据，它根本不适合，因为它没有丰富的数据结构，也无法高效支撑千万级别的随机点查。

3. 我在压测中看到的真实差距：为什么 Redis 在大数据量下会先崩

理论归理论，真正让我坚定"不能只用 Redis 做大数据链路缓存"的是一组压测数据。我们在同样 8 核 16GB 的三台机器上分别部署 Redis 集群和 Alluxio 集群，模拟同一个业务场景：Spark 作业扫描 500GB 数据，每批读 128MB 数据块，作业需要反复扫描三次（模拟多轮迭代计算）。

3.1 场景 A：纯 Redis 缓存中间结果的尴尬

一开始我们尝试的是用 Redis 缓存 Spark 计算的中间结果。做法是：Spark 里用 RDD 的 foreachPartition 把每个分区的计算结果写入 Redis，下游的作业再从 Redis 里读。

测试下来发现两个致命问题。

问题一：数据写入变成瓶颈。Spark 输出的是高维特征数据，一个分区经序列化后就有 30-50MB，我们当时用的 Java 原生序列化加 basic string 存储，每批次大约 200 个 partition，也就是要写入 Redis 的数据量高达 6-10GB。Redis 虽然是内存操作，但大批量写入同样有网络序列化开销，写入 QPS 大约只能稳定在 3.5 万左右。三分钟的计算结果，光写 Redis 就花了将近两分钟，整个端到端延迟被无限拉长。

问题二：数据读出的反序列化开销极高。下游读取时要跨越网络把所有值拉回内存并且反序列化，如果数据的 Value 是大量 Doubles 组成的数组，序列化后的体积膨胀非常厉害，读出来的延迟放大得非常明显。我们测出来在 200 并发下单条记录读取的平均耗时从 1ms 涨到了 17ms。

说白了，Redis 在大量小键值对、高并发随机读的场景下确实是王者，但一旦数据变成了大块的文件内容或中间数据集，它的网络开销、序列化开销、内存占用都会让人非常难受。这不是 Redis 的缺陷，而是它天生不是为这个场景设计的。

3.2 场景 B：Alluxio 承接计算引擎的缓存读取

在同样的计算迭代场景下，我们把 Spark 的 spark.sql.execution.arrow.pyspark.enabled 改成 Alluxio 作为中间数据层，通过 alluxio:// 协议读写数据。

效果差异非常明显。

第一次跑的时候 Alluxio 没有缓存，作业要从 HDFS 拉数据，速度慢一些，这是正常的冷启动成本。但第二次、第三次跑同样的作业时，Spark 直接从 Alluxio 读取本地缓存的数据块，数据块的本地命中率到了 96% 以上。三次迭代的总时间从第一轮的 40 分钟降到了 20 分钟，最终稳定在 12 分钟，比纯 Redis 方案快了将近一倍。

这背后的原理是：Alluxio 对计算框架透明地暴露了文件接口，Spark 根本不知道数据是缓存在内存还是底层存储，它只需要按文件/块去读。而 Redis 要求应用自己管理数据切分、序列化、组装，这个复杂度在大数据场景下是不可控的。

3.3 压测暴露的额外问题：内存碎片和数据倾斜

做 Redis 压测时我们遇到过内存碎片率涨到 1.7 的情况。原因是我们频繁写入大 Value（30MB+），再频繁淘汰，Redis 的内存分配器产生了大量碎片。后来我们用了 jemalloc 配合大页内存并设置 maxmemory-policy allkeys-lru 才把碎片率控制到 1.2 以内。这个坑在真实环境中非常值得关注：如果你的缓存数据有大量大 Value，内存碎片和逐出策略会成为比 QPS 更先出现的瓶颈。

Alluxio 侧也踩过内存倾斜的坑。默认配置下 Alluxio Worker 是按节点平均分配内存的，但作业读取不是均匀的，某个 Worker 很快满，另一个却空着。后来我们把 alluxio.worker.allocator.class 换成 MaxFreeAllocator，允许数据写入剩余空间最大的 Worker 上，倾斜情况才明显缓解。

4. 实战决策框架：到底什么时候该用 Redis、什么时候该上 Alluxio

压测数据贴出来，有人可能会说：既然 Alluxio 这么强，是不是直接把 Redis 换掉？答案是显然不行。Redis 在它擅长的领域依然是无可替代的。这里我把我自己沉淀下来的决策框架分享出来，四步走，基本能解决 90% 以上的缓存选型问题。

4.1 第一步：先搞清楚你要缓存的数据是什么类型

这是整个决策里最重要的一步，但也是最常被忽略的一步。我把大数据链路中需要缓存的数据分为三类：

• 结果型数据：比如用户维表、商品标签、实时流计算输出的指标，单条数据量小，条数在百万到千万级。这类数据最适合 Redis。
• 中间型数据：比如 Spark Stage 的输出、ETL 清洗后的明细数据、跨作业共享的数据集，单条数据量大，以文件/表形式存在。这类数据适合用 Alluxio。
• 源数据加速：底层是 HDFS、S3 或者远端存储，计算引擎要反复读取源数据做迭代计算。这种场景基本就是 Alluxio 的阵地。

你可以拿一个简单的判断准则：如果数据是以"行/键"为单位被访问的，选 Redis 没问题；如果数据是以"文件/块/分区"为单位被访问的，选 Alluxio 明显更合理。

4.2 第二步：估算数据量级和访问模式

一般来说，总数据量在内存可容纳范围内（比如 10GB 以下）、单条数据小于 1MB、访问高度随机，Redis 有明显的性能优势和更低的运维成本。数据量在几十 GB 到 TB 级、以批量扫描为主、且有跨作业复用需求的场景，Alluxio 更合适。

这里有个容易被忽略的点：不要只看总数据量，要看热数据比例。如果总量很大但热数据只有 5%，Redis 也可以做热点缓存；如果作业需要反复扫描完整数据集，那不存在什么热数据概念，只存在频繁全量读取的路径加速需求，这就必须用 Alluxio 了。

4.3 第三步：看你的计算引擎是否有 Alluxio 集成插件

这是很多实际项目里最现实的约束条件。如果你的计算引擎不直接支持 Alluxio 协议，硬上 Alluxio 会带来大量额外开发成本。目前 Alluxio 对 Spark、Presto、Flink 这些主流引擎都有成熟的集成方案，通常在引擎里配置 alluxio:// 作为文件系统就能生效。但如果你用的是比较小众的计算引擎，那就得重新平衡了。

而 Redis 则没有这个顾虑，无论什么引擎都能通过 API 或者连接池访问，接入成本更简单。

但要注意，Redis 接入简单不等于能用好。如果你的引擎是跑批量大作业的，自己写代码把数据往 Redis 里塞，反而要承担序列化、数据分片、批量读写、异常重放等一系列负担，这个复杂度并不比集成 Alluxio 低。

4.4 第四步：考虑一致性和故障恢复需求

缓存做久了都会遇到一个问题：数据更新了，但缓存里的还是旧的。Redis 场景下，常见方案是设置合理的 TTL，或者通过 Canal 监听业务库变更后主动更新缓存。这种最终一致性对于结果型数据来说是可接受的。

Alluxio 的一致性则取决于缓存策略，可以做到"强一致"（写 Alluxio 时同步写底层存储）或"弱一致"（写 Alluxio 即可，底层存储异步刷写）。如果你的下游必须保证读到的数据是最新的，需要评估好 Alluxio 的缓存策略配置，否则可能出现旧数据被反复读取的情况。

我见过一个实际案例：数据分析平台用 Alluxio 缓存了 HDFS 上的 Hive 表数据，但底层数据文件每天凌晨更新一次，由于没有配置失效策略，平台运行了三天还在读旧文件。后来通过配置 alluxio.user.file.cache.partial.write.merge 和合理设置缓存淘汰策略，并把数据更新触发缓存失效的回调接进来才解决。

综合下来，我给团队的建议是：不要二选一，而是让它们各司其职，组合成一条"结果缓存 + 数据加速"的双层链路。

5. 组合落地实践：Redis 和 Alluxio 在一条链路里如何各司其职

这一节就以我们数据服务化平台的真实架构为例，完整拆解 Redis + Alluxio 组合方案的落地细节和踩坑记录。

5.1 整体链路设计

模块划分非常简单：

• 底层存储：HDFS（离线数仓主干）+ 云上 OSS（冷数据）
• 计算引擎：Spark SQL 做批处理，Presto 做即席查询
• 加速层：Alluxio 分布式缓存，直接加速 Spark/Presto 的读写
• 结果层：Redis Cluster，承接结果数据的实时查询和热点应用访问

链路运作方式：Spark 作业从 HDFS 读取数据，经 Alluxio 缓存加速读写计算逻辑，生成聚合结果之后，把结果数据以 Key-Value 形式写入 Redis。下游的实时服务只面向 Redis，不直接面对 Spark 或 HDFS。

在这个链路里，底层大数据的"传输效率"由 Alluxio 负责，高并发场景下的"结果查询效率"由 Redis 负责。这两件事互不干扰，却又是完整数据服务的两个必要环节。

5.2 Redis 侧的重点配置与常用命令

Redis 在这里我重点做三件事：合理设置过期时间、配置内存淘汰策略、优化序列化方式。

第一个是 TTL 设置。结果型数据我一般设置 ttl=1800 秒，也就是半小时，这个时间窗口与批处理作业调度周期对齐。过长会导致数据更新不及时，过短会导致缓存命中率低、频繁回源。

第二个是淘汰策略。因为结果数据允许丢失后重建，我选择的是 allkeys-lru，这样可以让 Redis 在内存吃紧时自动淘汰最久未使用的 Key，而不是启动写保护拒绝新数据。

第三个是序列化方式。这个点太容易被忽视了。很多团队直接用 Java 原生 Serializable 存对象，性能差而且垃圾字节多。我们当时换成了 Kryo 序列化，写进 Redis 的对象体积比原生序列化小了不少，对于高并发场景的性能改善非常直接。如果数据模型简单，直接用 String 类型存储 JSON 字符串，加速效果也很明显。

另外，集群模式下要特别注意 hash tag 的使用。如果一批 Key 需要在 Lua 脚本中原子操作，必须给它们设置相同的 hash tag（用 {...} 将同一个字段括起来），保证这些 Key 落在同一个槽里。我们刚开始做多 Key 聚合时没注意这个，经常报 CROSSSLOT 错误，加上 hash tag 之后这个错误就销声匿迹了。

5.3 Alluxio 侧的关键配置与运行经验

Alluxio 这边重点配置三块：挂载底层存储、缓存策略、内存与存储分层。

挂载底层存储直接用命令：

bash复制alluxio fs mount /mnt/hdfs hdfs://nameservice/user/data

挂载后 Alluxio 暴露统一的 alluxio:// 路径给计算引擎。Spark 那边不需要大改，只需要把路径前缀替换成 alluxio://master:19998/mnt/hdfs/... 即可。

缓存策略一般有两种选择，按需缓存或预加载。如果作业数据集固定且经常被多个作业共用，可以提前执行：

bash复制alluxio fs load /mnt/hdfs/user/important_table

提前把热数据拉进缓存。如果是面向未知查询，则保持默认的按需缓存模式即可。

存储分层方面，我建议按节点规划内存和 SSD 的配比。内存的访问速度极快但空间有限，SSD 可以大幅扩展缓存容量，但延迟会高一个量级。对于 Spark 这类批处理作业，SSD 已经够用；对于 Presto 这种交互式查询，尽量让数据留在内存里。实际落地时我们给 Worker 配了 64GB 内存 + 2TB SSD，通过 alluxi.worker.ramdisk.size 和 alluxio.worker.file.buffer.size 控制不同层级的容量占比。

这里必须提醒一个坑：Alluxio 的元数据是存在 Master 节点内存里的，文件数量过多或者目录层级过深会直接压爆 Master 内存。我们在挂载一个超大 Hive 库时，小文件上千万个，Master 的 JVM 堆直接飙到 90% 以上。后来做了两级优化：一是合并底层小文件，把千万级小文件合并成百万级的中等文件；二是调整了 alluxio.master.metastore.inode.cache.max.size 参数，但这个参数只是缓存上限，并没有根治内存问题。所以如果你的表本身就有严重的小文件问题，先治理底层存储再上 Alluxio 会更顺利。

5.4 双缓存一致性处理

Redis 和 Alluxio 都缓存数据后，会有一个新问题：两条缓存路径的一致性如何保证？

我的策略是分层处理：Redis 缓存的结果数据，由批处理作业完成后主动更新，作业开始前如果发现 Redis 已有旧数据就直接淘汰掉，作业完成后写入新结果，相当于"生成时刷新"。这个策略叫 Cache-Aside 模式，对数据时效要求不高的场景足够。

Alluxio 侧的数据一致性则依赖底层存储版本。我们结合 HDFS 文件更新事件，在数据源变更后主动执行：

bash复制alluxio fs free /mnt/hdfs/user/important_table

释放旧缓存，让下一次访问重新从底层拉取新数据。这样做比等待 Alluxio 基于时间的过期策略更可靠，因为 Alluxio 默认不会感知底层文件的变更，如果不主动释放，它会一直返回旧数据。

6. 两个缓存结合时的性能调优细节和常见坑

组合方案上线后，我们还花了一整周做性能调优。这个环节里踩的坑比方案设计阶段多得多，挑几个最有代表性的分享出来。

6.1 Alluxio 本地读命中率优化

初期部署后我们发现 Spark 作业的平均本地读命中率只有 71%，大量数据还是通过远端 Worker 读的。原因在于 Alluxio 的位置感知策略和 Spark 的调度策略没有对齐。Spark 的 Executor 和 Alluxio Worker 在同一批节点上，但 Spark 在调度 Task 时并不感知 Alluxio 的缓存位置。

解法也不难：把 Alluxio Worker 的节点信息以拓扑脚本的方式共享给 Spark。在 Spark 里设置：

scala复制spark.sql.adaptive.enabled=true
spark.sql.adaptive.coalescePartitions.enabled=true

并把 spark.scheduler 配置指向包含 Alluxio 节点信息的拓扑脚本。这样 Spark 调度时会尽可能把计算任务派发到数据所在节点的 Executor 上。调整之后，本地命中率从 71% 提升到了 94%，作业时间缩短了约 18%。

6.2 Redis 大 Value 与 key 设计规范

另一个很深刻的教训来自 Key 设计。一开始团队成员图省事，直接用表名拼接主键：

text复制user_profile:detail:100023438

这个 Key 很长，数据是 20 多个字段组成的 JSON 字符串。看起来没什么问题，但在高频访问下，长 Key 和长 Value 会导致 Redis 网络和内存都出现退化。

后来我们做了几步优化：

• Key 缩写：up:d:100023438，把语义压缩到最简。
• Value 使用 Hash 结构存储，单字段可独立更新，不需要全量重写 JSON。
• 设置序列化压缩：Redis 本身不压缩数据，压缩做法是应用层用 Snappy 压缩大字段后再存入，读取时解压。在 JSON 大 Value 场景下，Snappy 压缩比可以达到 3:1，网络带宽和内存占用都大幅下降。

另一个和 Redis 查询模式相关的坑是热 Key 问题。某个头部用户 UUID 的访问量占全缓存访问量的 20% 以上，导致 Redis 某个分片比其他分片负载高很多。虽然没有直接到打崩的地步，但响应延迟明显比其他分片高。最终方案是把这个热 Key 复制多份，在不同副本上分别带上后缀，比如 up:d:100023438:0、up:d:100023438:1，读取时随机取后缀，在读多写少的场景下这个策略效果很好。

6.3 存储分层与容量水位监控

Alluxio 上线后不能做"甩手掌柜"，容量水位和存储分层指标都要纳入监控。我常用的核心指标有四个：

• Alluxio Worker Capacity Usage：每个 Worker 的存储使用率。
• Local Hit Ratio：本地读命中率，低于 80% 需要检查调度配置。
• Under Storage Read Throughput：底层存储读取吞吐，变高说明命中率在下降或缓存被冲刷。
• Master JVM Heap：元数据内存，增长异常要考虑小文件治理或者元数据规模问题。

Redis 侧重点监控 changed_memory、evicted_keys、blocked_clients 三个指标，分别对应缓存变化量、淘汰量和阻塞情况。如果 evicted_keys 突增，通常意味着内存不足，盲目增加内存不如先检查是不是有过期时间不合理的大批量 Key。

7. 运维和成本视角的补充建议

技术选型很多时候不仅看性能，还要看运维成本和预算。这里分享几个我们在产线上沉淀出来的经验。

7.1 团队能力匹配

如果团队对 Hadoop 生态熟悉而对 Redis 熟练度一般，建议优先把 Redis 用熟用透；如果你想上 Alluxio，要评估团队有没有维护额外分布式系统的人力。Alluxio 和 Redis 都是要长期运维的组件，不是引入即完事。

7.2 缓存层故障时的降级预案

任何一个缓存都有可能挂，降级预案必须提前设计好。

Redis 挂了，我们的降级方案是直接把查询打到 Presto/Hive，并开启限流保护底层查询。由于结果数据可以重新计算，这个降级是可接受的，只是延迟会明显上升。

Alluxio 挂了，计算引擎会直接回源到 HDFS 读取全文，所以不会有数据丢失风险，但性能会回落到没有缓存的水平。要确保底层存储的 QPS 冗余足够，否则 Alluxio 挂掉的一瞬间，底层存储会被全部流量打爆。

7.3 成本评估

Redis 集群的成本基本等于内存成本，如果缓存数据规模很大，内存成本会几何级上升。Alluxio 的好处是可以用 SSD 分担相当一部分数据量，综合成本比纯内存缓存低很多。我们做个简单测算：假设要缓存 100GB 热数据，Redis 至少需要约 150GB 内存（算上复制、碎片、缓冲区），而 Alluxio 可以用 50GB 内存 + 200GB SSD 来覆盖类似场景，成本相差约一半。但 Alluxio 的元数据还是吃内存的，文件数量多了成本也不低，不能只看数据容量。

8. 最后聊聊我的个人判断

做了这么多对比和实践，我给团队的最终建议是这样的：短平快的实时查询缓存，无脑选 Redis；大数据计算链路的文件级加速和跨引擎数据共享，直接上 Alluxio。两者不冲突，反而互补。

我在实际运营这套组合方案后，最大的感受是：系统中的每个缓存组件都应该有明确且唯一的责任边界。Redis 负责"面向用户的高并发结果查询"，Alluxio 负责"计算层的数据访问加速"。边界清晰之后，容量规划、性能调优、故障排查都会变得简单得多。最怕的是所有数据对两个缓存都开放，结果形成缓存双写和更新风暴，运维起来会很痛苦。

踩过这一轮坑之后，我再也不会"一本正经"地说 Redis 能搞定一切缓存了。如果你正在建设数据服务化平台、或者正在为计算引擎的 IO 瓶颈发愁，不妨先把你的数据分类理清楚，再决定去该把哪个组件放在哪一段。这可省下来的排查时间，比你多开 20 个节点划算多了。