redis hash field过期时间_阿里内部强制执行的redis使用规范，违者绩效直接3.25

提示：阅读本文大概需要5分钟，践行本文大概需要整个职业生涯, 因此墙裂建议各位读者关注号主，收藏本文，以备不时之需

前言

目前互联网大厂大量使用redis、pika作为后端缓存、存储，但是存在存储选型不慎重、结构规划不合理、命令使用不规范的现象，继而造成系统性能达 到瓶颈、活动高峰系统可用性下降、dba可运维难度大大增加。所以就有了这份规范，从源头规范redis使用，避免系统运行过程中出现上述 问题。

存储选型

• Redis是一个单进程、基于内存、弱事务的NoSql存储系统，适用于高QPS、低延迟、弱持久化的场景，适宜用作缓存。
• Pika是一个多线程、基于磁 盘的兼容redis协议的存储系统，适用于低QPS、高延迟、大容量持久化的场景，适宜用作存储。
• 我们建议: 在qps>5000、容量<50G、存储高频数 据时考虑redis;在延迟容忍>10ms、容量大于50G、有持久化需求时考虑Pika;在qps<1000、存储大量低频数据、需要事务时考虑Mysql。

结构规划

1. key名设计规范

• 可读性和可管理性:
  Redis有两层(key-value)或三层(key-field-value)结构，一个好的名字有助于排查线上问题、方便的进行批量处理，同时能够防止key冲突。
  建议组标识:系统标识:模块标识:...作为一个通用前缀，其中组标 识在明确namespace归属后可以不填

比如: 当前redis内存暴涨，通过高频key前缀可以轻易的区分出是那个系统的那个模块在频繁操作，快速定位问题。

• 简洁性:
  保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，key的长度不超过100个字符。

例如: 不要包含特殊字符
反例: 包含空格、换行、单双引号以及其他转义字符

2. value设计规范

• 拒绝 bigkey(防止网卡流量、慢查询):
  • string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。
  • 非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞，而且该操作不会不出现在慢查询中(latency可查))，查找方法和删除方法
• 选择适合的数据类型:
  例如:实体类型(要合理控制和使用数据结构内存编码优化配置,例如ziplist，但也要注意节省内存和性能之间的平衡)
• 控制key的生命周期:
  redis不是垃圾桶，建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)，不过期的数据重点关注 idletime。
• 结构选择
  • Strings类型: 单个kv存储、适用于如简单计数等，value长度建议小于1MB，存数字最佳，如果确实value比较大，建议压缩后存储。Hash类型: 多个相关属性放到一个Hash中、适用于如存储对象，建议field数量小于10000，整体size小于1G。
  • Set类型: 集合类型、适用于如归类对象等，建议元素数量小于10000，整体size小于1G。
  • Sorted Set类型: 有序集合类型、适用于如榜单排行，建议元素数量小于10000，整体size小于1G。
  • Lists类型: 队列类型、适用于如队列、粉丝/关注列表等，建议长度小于10000，整体size小于1G，保证生产-消费平衡。需要使用特殊的数据类型(如Hyperloglog、Geo、Scripting)，需要提前跟DBA沟通。

2. 容量预估

• 第一次申请redis是需要做好容量评估、qps评估、流量评估(根据qps、平均value)，注意: 当需要当前redis支持某个活动、需求时，需要再 次进行上述评估，以便DBA进行资源调配。
• 使用ker后没有db的概念，所以不需要进行db切换，也不支持通过db划分系统、模块等。

命令使用

1. 命令使用基本原则

• 冷热数据分离，不要将所有数据全部都放到Redis中
• 不同的业务数据要分开存储
• M类操作命令，建议个数在100个以下，整体size控制在10KB以内，如MGET、MSET、HMGET等。
• 避免使用HGETALL、HKEYS、HVALS，除非可以保证HASH内field数量在100以内、size在10KB以下。如果不可避免，可以拆分一个大 HASH为多个小的HASH。
• 单个redis实例key的数量控制在100万以内(因为我们不是所有的key都设置过期，暂时不考虑该条规则)。
• 如果将redis定位为缓存，每个key尽量设置过期时间(最长14天，更长时间需要跟DBA沟通) 。
• Redis支持过期机制，如果某些业务场景用到了过期时间这一特性就不能使用读写分离特性，否则需要在业务去自行管理、及时过期。
• 对于特别重要的数据、连接相关的操作需要保证捕获异常，防止错误被淹没、数据操作状态不确定。

2. 关注O(N)命令中N的数量

例如: hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替。

3. 禁用命令

禁止线上使用keys、flushall、flushdb、monitor、save、bgsave等，通过redis的rename机制禁掉命令，或者使用scan的方式渐进式处理。

缓存db数据一致性规范

必须采用延时双删策略，具体操作如下：

1. 写数据库
2. 删除缓存
3. 同步延时或者订阅db的binlog异步延时再次删除缓存
   伪代码示例：

public void write(String key,Object data){  //写db  db.updateData(data);  //同步删除缓存  redis.delKey(key);  //延时500ms  Thread.sleep(500);  //再次删除缓存  redis.delKey(key);}

---

正文end

往期精彩回顾

阿里内网一位p7大佬关于“限流”的分享(仅限小范围传播)

刷完这些题目，成功收割了阿里，美团，字节等大厂offer

后端服务实战之性能优化

聊聊亿级数据下Mysql数据库的分库分表方案