Redis 中的大 Key 问题深度解析

目录

Redis 中的大 Key 问题深度解析

一、大 Key 的定义

二、案例分析

三、解决大 Key 问题的底层逻辑

---

在使用 Redis 的过程中，大 Key 问题是一个常见且重要的考量点。本文将深入探讨 Redis 中关于大 Key 的定义、案例分析以及解决大 Key 问题的底层逻辑。

一、大 Key 的定义

在 Redis 中，大 Key 不能单纯以 value 值大小或者集合元素数量多来判断。很多人认为 string 大于五兆、hash list size 大于 1 万的 key 就是大 key，但这种说法并不准确。实际上，大 Key 的判断标准是看其是否影响业务。

二、案例分析

1. 20 兆 value 值的首页缓存：系统首页数据缓存到 Redis 中，value 值为 20 兆，每天零点到 24 点访问人数 1 万，且用户请求稀疏分布到 24 小时，TPS 不高。从 Redis 读取只需 1 秒，而用 SQL 语句加载需 10 秒。在这种情况下，这个 key 不算大 key，因为它没有影响业务。
2. 五兆 value 值的高并发场景：若 key 只有五兆，但每天早上九、五点钟有 1 万个人并发同时访问。如果因并发高导致 IO 阻塞通道，即便这个 key 小于 20 兆，也是不合理的，应算作大 key。
3. 哈希 list 成员数量与大 Key 判断：哈希 list 里成员很多是否算大 key 取决于查找方式。如果每次只查找几个成员，那么它就不算大 key。

三、解决大 Key 问题的底层逻辑

解决大 Key 问题的根本在于不让大 Key 影响业务，在此前提下讨论解决方案才有意义。

1. 对于 1 万个并发返回很大的场景，首先应考虑 CDN 而不是 Redis。例如，一个五兆的 key 在 1 万个并发瞬时带宽就是 50 个 G，一般情况下很难承受如此大的带宽。
2. 解决大 Key 问题需要对缓存的数据做出正确预估。考虑这些数据该不该放到 Redis 里、大小和读取频率如何、能否通过一级缓存、CDN 或在 NG 层面解决。如果能在这些层面解决问题，不产生大 key，自然就无需解决大 key 问题。

总之，对于大 Key 的判断和处理要结合实际业务场景，不能仅凭表象衡量。在面试中，可以结合实际场景，运用上述话术回答问题，会很受用。正确认识和处理大 Key 问题，有助于提高 Redis 的使用效率和系统的稳定性。