华为云GaussDB(for Redis)揭秘第18期：谁说Redis不能存大key

GaussDB(for Redis)专家小强最近有点忙，因为很多客户经理都来找他咨询社区版Redis的大key问题，且一个个都求知欲爆表：

小强一拍大腿：你们还真问对人了！

根据现网经验，生产环境因为大key导致的Redis事故屡见不鲜，其中典型的有扩容失败、请求阻塞、OOM宕机等等。早期业务规划不充分、消息队列消费不及时、未及时清理无效数据等原因都可能引入大key隐患。

社区版Redis大key隐患常见于以下三大场景：

1. 内存消耗不均衡，大key所在分片有OOM风险

2. 扩容时需要搬迁部分数据，大key耗时久，会导致访问阻塞甚至数据丢失

3. 删除或过期大key时，业务访问被长时间阻塞，甚至导致主从同步中断

   
   

社区版Redis架构并不适合可靠存储大key，业界也只能建议预防、拆分或及时清理大key。从客户视角出发，其实有些场景是需要大key的，例如企业ERP系统，海量货币汇率存储等。这时即使适当拆分，也避免不了较大HASH key存在。

• 社区版Redis存储大key会导致分片内存消耗不均，随着集群整体数据量水位提升，大key所在分片随时有OOM风险。

• 高斯Redis支持大key可靠存储，且不会导致分片OOM。需要注意的是，虽然高斯Redis适合用来可靠存储大key，但从网络链路角度考虑，业务应避免对大key执行诸如hgetall等风险命令。

• 社区版Redis在扩容时，由于要搬迁数据，此时画风是这样的：

• 高斯Redis支持秒级扩容，并支持升规格、加节点、加存储容量3种手段灵活扩容，运维体验极佳。‍

• 社区版Redis大key的删除/过期都会导致访问严重阻塞。实测删除/过期一个大hash key（包含1000w个元素），社区版Redis访问阻塞长达整整14秒。

虽然社区版Redis提供了“异步”的unlink命令能够一定程度上缓解大key阻塞问题，但unlink并非严格异步，例如对于zset类型（skiplist编码）以及全部string key都只能阻塞删除，风险不可控。

• 高斯Redis从根本上解决了大key删除/过期操作隐患。在高斯Redis中，对任何数据执行删除/过期，都是立刻执行成功且0阻塞。这是由于底层采用了真正的“标记删除”，因此完全不影响业务访问。实测删除/过期一个大hash key（包含1000w个元素），高斯Redis仅毫秒级。