键值设计
key名设计
- 可读性和可管理性：以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:id
ugc:video:1
- 简洁性：保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视
- 不要包含特殊字符（包含空格、换行、单双引号以及其他转义字符）
- 建议使用expire设置key过期时间(条件允许可以打散过期时间，防止集中过期)
value设计
- 拒绝bigkey(防止网卡流量、慢查询)，在Redis中，一个字符串最大512MB，一个二级数据结构（例如hash、list、set、zset）可以存储大约40亿个(2^32-1)个元素。但实际上string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000
- 选择适合的数据类型
使用规范
- 虽然 Redis支持持久化，但将所有数据存储在 Redis 中，成本非常昂贵。建议将热数据 (如 QPS超过 5k) 的数据加载到 Redis 中。低频数据可存储在 Mysql、 ElasticSearch中
- 不要将不相关的数据业务都放到一个 Redis中。一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复
- 连接的频繁创建和销毁，会浪费大量的系统资源，极限情况会造成宿主机当机。请确保使用了正确的 Redis 客户端连接池配置
- 缓存应该仅作缓存用，去掉后业务逻辑不应发生改变，万不可切入到业务里
操作限制
- Keys 命令效率极低，属于 O(N)操作，会阻塞其他正常命令，在 cluster 上，会是灾难性的操作。严禁使用
- flush 命令会清空所有数据，属于高危操作
- Redis的事务功能较弱(不支持回滚)，不建议使用
yq.aliyun.com/articles/53…
