[学习笔记 Day03]Redis 基础：Redis 设计的优化建议与最佳实践

最佳实践

键值设计

• 约定：
  • 遵循基本格式：[业务名称]:[数据名]:[id]
  • 长度不超过 44 bit
  • 不包含特殊字符
• 优点：
  • 可读性强，避免 key 冲突，方便管理
  • 更节省内存：key 是 string 类型，底层包含 int、embstr、raw，embstr 在小于 44 bit 使用时会采用连续内存空间，占用更小
  • 查看 key 的数据类型：object encoding key
• Bigkey
  • BigKey 以 key 的大小和成员数量综合判定：
    • 例如：
      • key 本身的数据量过大，一个 string 类型，值为 5mb
      • key 的成员数量过多，一个 ZSET 类型，成员数为 10000 个
      • key 的成员的数量过大，一个 HASH 类型，成员数虽为 10000 个，但 value 总大小约为 100 mb
    • 推荐值：
      • 单个 key 的 value 小于 10kb
      • 对于集合类型的 key ，元素数量应小于 1000
    • 扩展命令：
      • 查 key 的占用大小：MEMORY USAGE key
      • 查看 value 的长度：STRLEN key
      • 查看集合的长度：LLEN key
  • BigKey 的危害：
    • 网络堵塞：执行读请求，少量 QPS 可能占满带宽
    • 数据倾斜：内存远超其他实例，无法使分片的内存资源达到均衡
    • Redis 阻塞：对元素较多的 hash、list、zset 等运算耗时较旧，主线程阻塞
    • CPU 压力：数据序列化和反序列化导致飙升
  • 查找 BigKey：
    • 命令：# redis-cli -a password --bigkeys
    • scan 扫描：利用 scan 扫描所有 key ，利用 strlen、hlen 等判断（不建议使用 memory usage）：#scan 0
    • 第三方工具：Redis-Rdb_Tools（离线）
    • 网络监控：自定义工具
  • 删除 BigKey：
    • 4.0 后：#UNLINK key1 key2 ... （删除 bigkey）
    • 3.0 前：逐个删除
• 恰当的数据类型：
  • 三种存储方式：
    • json 字符串：user:1 => {"name":"jack"...}
    • 字段打散：user:1:name => Jack
    • hash（推荐）：user:1 name Jack
  • 当 hash 的 entry 超 500 时，会使用哈希表，而不是 Ziplist ，内存占用较多
  • 可通过 hash-max-ziplist-entries 配置 entry 上限但如果过多导致 BigKey 问题
    • 查看：config get hash-max-ziplist-entries
    • 修改：config set hash-max-ziplist-entrues 1000
  • 拆分为 string 类型
    • string 结构底层没有太多内存优化，内存占用较多
    • 批量获取会比较麻烦
  • 拆分为 hash 嵌套：
  • 批处理：
    • MSET、HMSET 命令
    • 注：不要再一次批处理中传输大量命令，单词命令会占用带宽过多
    • Pipeline 批处理（以上方案，在集群中会失效）

–		串行 slot	并行 slot	hash_tag
实现思路	for 循环遍历， 一次执行每个命令	在客户端计算每个 key 的 slot ， 将其一致的分为一组， 每组利用 Pipeline 批处理	在客户端计算每个 key 的 slot， 将其一致的分为一组， 每组利用 Pipeline 批处理	将所有 key 设置相同的 hash_tag ， 则所有 key 一定相同
耗时	N 网络耗时 + N 次命令耗时	m 次网络耗时 + N 次命令， m = key 的 slot 个数	1 次网络耗时 + N 次命令耗时	1 次网络耗时 + N 次命令耗时
优点	实现简单	耗时短	耗时非常短	耗时非常短，实现简单
缺点	耗时大	实现稍微复杂， slot 越多，耗时越大	实现复杂	容易出现数据倾斜

服务端优化

持久化

• 建议：
  1. 缓存数据，尽量不用开启持久化
  2. 推荐使用 AOF
  3. 利用脚本定期在 slave 节点做 RDB，实现数据备份
  4. 设置合理 ReWrite 的阈值，避免使用 bgsave
  5. 配置 no-appendfsync-on-rewrite = yes，禁止 rewrite 期间做 AOF，避免引起阻塞（要性能 yes，要安全 no）
• 部署建议：
  • Redis 实例的物理机要留足够内，应对 fork 和 rewrite
  • 单个 Redis 实例内存上限不要太大，例如：4G 或 8G，可以加快 fork 速度，减少主从同步，数据迁移压力
  • 不要与 CPU 密集型应用部署在一起
  • 不要与高硬盘负载应用一起部署，如数据库、消息队列

• 慢查询：在命令执行耗时超过某个阈值的命令
  • slowlog-log-slower-than：慢查询阈值（单位：μs，默认 10000，建议 1000）
  • 查看慢查询日志列表：
    • slowlog len：日志长度
    • slowlog get [n]：读取 n 条慢查询日志
    • slowlog reset：清空查询列表
  • 慢查询会被放入慢查询日志，日志长度有上限，可配置：
    • slowlog-max-len：日志长度（默认 128，建议 1000）

config get slowlog-max-len

config set slowlog-max-len 1000

config set slowlog-max-len-slower-than 1000

命令及安全配置：

• Redis 设置密码
• 禁止线上使用的命令：keys、flushall、flushdb、config set 等命令（可以利用 rename-command 禁用 => redis.conf 文件中配置）
• bind：限制网卡，禁止外网访问
• 开启防火墙
• 不要使用 root 账户启动 redis
• 尽量不使用默认端口

内存配置：内存不足时，会导致 key 频繁删除

# 查看内存信息
info memory

# 查看单个的内存信息
emmory xxx

内存缓冲区：

集群优化：默认情况下，发现任意一个插槽不可用，则整个集群将不可用

# redis.conf 下进行配置（建议）：
cluster-require-full-coverage false