key名设计

【建议】: 可读性和可管理性

比如业务名:表名:id

【建议】：简洁性

保证语义的前提下，控制key的长度

【强制】：不要包含特殊字符

空格、换行、单双引号以及其他转义字符

【强制】: 集群批量操作key，用{}保证成功

value设计

【强制】：拒绝bigkey

• string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000

• 危害： 过期删除，导致redis阻塞，网络拥塞

• bigkey的产生

  • 社交类：粉丝列表，如果某些明星或者大v不精心设计下，必是bigkey。
  • 统计类：例如按天存储某项功能或者网站的用户集合，除非没几个人用，否则必是bigkey。
  • 缓存类：将数据从数据库load出来序列化放到Redis里，第一是不是有必要把所有字段都缓存，第二，有没有相关关联的数据，为了 图方便把相关数据都存一个key下，产生bigkey

• 非字符串的bigkey，不用del删除，用hscan、sscan、zscan方式渐进式删除

• 如何优化bigkey

• 拆
• 如果bigkey不可避免，用渐进式和局部数据获取数据，避免阻塞.

【推荐】：选择适合的数据类型

要合理控制和使用数据结构，但也要注意节省内存和性能之间的平衡

【推荐】：控制key的生命周期，redis不是垃圾桶。

(条件允许可以打散过期时间，防止集中过期，统一调用del，阻塞reids)

【推荐】：慎用lua脚本

命令使用

【推荐】 O(N)命令关注N的数量

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

【推荐】：禁用命令

禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁命令

【推荐】合理使用select

redis的多数据库较弱，还是单线程处理

【推荐】使用批量操作提高效率

【建议】Redis事务功能较弱，不建议过多使用，可以用lua替代

客户端使用

【推荐】 避免多个应用使用一个Redis实例

【推荐】使用带有连接池的数据库

连接池预热

【建议】高并发下建议客户端添加熔断功能(例如sentinel、hystrix)

【推荐】设置合理的密码，如有必要可以使用SSL加密访问

配置

【强制】: 设置最大内存(maxmemory-policy)

如果不设置最大内存(maxmemory-policy)，当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)，会让 Redis 的性能急剧下降。

【推荐】cluster-require-full-coverage为no

cluster-require-full-coverage为no时，集群可以不完整提供服务

【推荐】cluster-­node-­timeout 设置合理

防止脑裂问题

参考资料

Redis最佳实践：7个维度+43条使用规范，带你彻底玩转Redis (opens new window)

• 性能
• 可靠性
• 资源
• 运维
• 监控
• 安全