blog
首页
Redis 设计和使用规范
命名规范
【建议】key 名尽量具有可读性，同一类型/模块使用相同的前缀: 如 igame
, dnf
【建议】key 名多个段之间用统一的字符分割，推荐分割符： _
: # + = ; ,.
【建议】key 名字尽量简短，建议控制在 100 字节内，不允许超过 976 字节
【建议】key 名尽量避免使用二进制
【建议】key 名不要包含空格/换行/回车/单双引号/tab 等特殊字符
设计规范
【建议】尽量减少大 key 的设计，string 类型控制在 10KB 以内，hash、list、set、zset 元素个数不要超过 5000(避免网卡流量瓶颈/慢查询)
【建议】单个热点 key 可以考虑拆分成多个 key 进行处理，把热度打散
【建议】非字符串的 bigkey，不要使用 del 删除，使用 hscan、sscan、zscan 方式渐进式删除
【建议】注意防止 bigkey 过期时间自动删除问题，而引起阻塞
【建议】选择合适的数据类型
【建议】控制 key 的生命周期，尽量都设置 expire 过期时间，且要避免集中过期
【建议】Redis 事务功能较弱，不建议过多使用；集群模式下，不支持事务
使用规范
【建议】合理利用批操作命令，使用 O(N)命令(hgetall/lrange/smembers/zrange/sinter)时需关注 N 的数量，有遍历的需求可以使用 hscan/sscan/zscan 代替
【建议】减少不必要的请求，del 前先 ttl，避免删除不存在的 key
【必须】禁止线上使用 keys/monitor/flushall/flushdb 等危险命令，通过 Redis 的 rename 机制禁掉，或者使用 scan 的方式渐进式处理
【建议】合理使用 select，redis 默认使用 db0
【建议】在必须使用 monitor 命令时，要注意不要长时间开启
客户端规范
【建议】避免多个业务使用同一个 Redis 实例
【建议】高并发下建议客户端添加熔断功能，减少到 DB 侧的压力
【必须】客户端必须要使用密码访问 Redis，并且避免在公网访问
【建议】客户端访问 Redis 最好带连接池，并且使用长连接，能够减少创建链接的开销