多级缓存跳过

键值设计

优雅的 key 结构

Redis的Key虽然可以自定义，但最好遵循下面的几个最佳实践约定：

• 遵循基本格式：［业务名称］：［数据名］：［id］
• 长度不超过44字节
• 不包含特殊字符

例如：我们的登录业务，保存用户信息，其key是这样的： login:user:10

优点：

1. 可读性强
2. 避免key冲突
3. 方便管理
4. 更节省内存：key是string类型，底层编码包含int、embstr和raw三种。embstr在小于44字节使用，采用连续内存空间，内存占用更小

set num 123 如果 type num 得到 string 但是 object encoding num 得到底层是 int set name Jack 如果 type name 得到 string 但是 object encoding name 得到底层是 embstr

BigKey

什么是 bigkey

• Key 本身数据量大
• 成员数量过多
• 成员数据量大

推荐值

• 单个 key 的 value 小于 10KB
• 对于集合类型的 key，建议元素数量小于 1000

危害：

1. 网络阻塞
2. 数据倾斜，分片不均衡
3. Redis 阻塞
4. 序列化与反序列化 CPU 压力大

恰当的数据结构

对于一个 User 对象存储

1. String 类型的字符串整体存储 user:1
2. 打散字段，String 类型分别存储 user:1:name user:1:age
3. Hash 结构

Hash 结构不超过 1000 Entry，可以拆分

批处理

大数据导入

1 个命令响应 = 1 次网络往返 + 1 次执行

所以一次传递而非多次传递同等数据量更好，注意不要太多，不然会阻塞网络

pipeline 放入命令到管道，支持原生的各种命令，只是一次发送这些全部的命令到 Redis，而非原生的 MSET 的原子性大量操作

持久化配置

Redis 的持久化虽然可以保证数据安全，但也会带来很多额外的开销，因此持久化请遵循下列建议：

1. 用来做缓存的 Redis 实例尽量不要开启持久化功能
2. 建议关闭 RDB 持久化功能，使用 AOF 持久化
3. 利用脚本定期在 slave 节点做 RDB，实现数据备份
4. 设置合理的rewrite阈值，避免频繁的 bgrewrite
5. 配置 no-appendfsync-on-rewrite = yes，禁止在 rewrite 期间做 AOF，避免因 AOF 引起的阻塞

部署有关建议：

1. Redis 实例的物理机要预留足够内存，应对 fork 和 rewrite
2. 单个 Redis 实例内存上限不要太大，例如 4G 或 8G。可以加快 fork 的速度、减少主从同步、数据迁移压力
3. 不要与 CPU 密集型应用部署在一起
4. 不要与高硬盘负载应用一起部署。例如：数据库、消息队列

慢查询

在 Redis 中执行耗时超过某个阈值的命令，称为慢查询（不止查询），Redis 单线程所以慢查询会阻塞

慢查询的阈值可以通过配置指定：

• slowlog-log-slower-than: 慢查询阈值，单位是微秒。默认是10000，建议1000

慢查询会被放入慢查询日志中，日志的长度有上限，可以通过配置指定：

• slowlog-max-len: 慢查询日志（本质是一个队列）的长度。默认是128，建议1000

查看慢查询日志列表：

• slowlog len: 查询慢查询日志长度
• slowlog get [n]: 读取 [n]/全部 条慢查询日志
• slowlog reset: 清空慢查询列表