【一图流思维导图】Redis 使用规范 (键值对使用规范/命令使用规范/数据保存规范/运维规范)

参照 Redis 很屌，不懂使用规范就糟蹋了

Redis 使用规范

异常

Could not get a resource from the pool

• 获取不到连接资源，并且集群中的单台 Redis 连接量很高
• 更改最大连接数、连接等待数，虽然报错信息频率有所缓解，但还是持续报错。
• 经过线下测试，发现存放 Redis 中的字符数据很大，平均 1s 返回数据

前言

• 只有规范的使用 Redis，才能实现高性能和节省内存，否则再屌的 Redis 也禁不起我们瞎折腾。

键值对使用规范

建议

• 好的 key 命名

  • 才能提供可读性强、可维护性高的 key，便于定位问题和寻找数据

• value要避免出现 bigkey

• 选择高效的序列化和压缩

• 使用对象共享池

• 选择高效恰当的数据类型

key 命名规范

• 「业务名:表名:id」

  • 把「业务模块名」作为前缀（好比数据库 Scheme），通过「冒号」分隔，再加上「具体业务名」
  • set 公众号:技术类:码哥字节 100000

不要使用 bigkey

• 规范背景

  • 因为 Redis 是单线程执行读写指令，如果出现bigkey 的读写操作就会阻塞线程，降低 Redis 的处理效率

• bigkey包含两种情况

  • 键值对的 value很大，比如 value保存了 2MB的 String数据
  • 键值对的 value是集合类型，元素很多，比如保存了 5 万个元素的 List 集合

• 防止网卡流量、慢查询

  • string类型控制在10KB以内

• hash、list、set、zset元素个数不要超过 5000

• 还可以通过 gzip 数据压缩来减小数据大小

  • GZIPOutputStream
  • sun.misc.BASE64Decoder()
  • GZIPInputStream

• 如果集合类型的元素的确很多

  • 我们可以将一个大集合拆分成多个小集合来保存

使用高效序列化和压缩方法

• 为了节省内存，使用高效的序列化方法和压缩方法去减少 value的大小

• protostuff和 kryo这两种序列化方法

• 对比 Java内置的序列化方法

  • 优点：效率更高
  • 劣势：序列化后都是二进制数据，可读性太差

• 通常会序列化成 JSON或者 XML

  • 为了避免数据占用空间大，可以使用压缩工具（snappy、 gzip）

使用整数对象共享池

• 内部维护了 0 到 9999 这 1 万个整数对象，并把这些整数作为一个共享池使用

  • redis其实只保存了一份整数对象，可以节省内存空间。

• 有两种情况是不生效的

  • 1

    • Redis 中设置了 maxmemory，而且启用了 LRU策略（allkeys-lru 或 volatile-lru 策略）
    • 这是因为 LRU 需要统计每个键值对的使用时间，如果不同的键值对都复用一个整数对象就无法统计了。

  • 2

    • 集合类型数据采用 ziplist 编码，而集合元素是整数
    • 因为 ziplist 使用了紧凑型内存结构，判断整数对象的共享情况效率低

命令使用规范

规范背景

• 有的命令的执行会造成很大的性能问题，我们需要格外注意
• 如果我们执行一些涉及大量操作、耗时长的命令，就会严重阻塞主线程，导致其它请求无法得到正常处理。

生产禁用的指令

• KEYS

  • 对 Redis 的全局哈希表进行全表扫描，严重阻塞 Redis 主线程

  • 替代

    • SCAN

      • 分批返回符合条件的键值对，避免主线程阻塞

• FLUSHALL

  • 删除 Redis 实例上的所有数据，如果数据量很大，会严重阻塞 Redis 主线程

• FLUSHDB

  • 删除当前数据库中的数据，如果数据量很大，同样会阻塞 Redis 主线程

• 补充

  • 加上ASYNC 选项，让 FLUSHALL，FLUSHDB 异步执行

• 也可以直接禁用

  • 用rename-command命令在配置文件中对这些命令进行重命名，让客户端无法使用这些命令。

慎用 MONITOR 命令

• MONITOR 命令会把监控到的内容持续写入输出缓冲区。

• 除非十分需要监测某些命令的执行

  • Redis 性能突然变慢，我们想查看下客户端执行了哪些命令

慎用全量操作命令

• 些操作会对整个底层数据结构进行全量扫描 ，导致阻塞 Redis 主线程

• 比如获取集合中的所有元素

  • hash

    • hgetall

  • list

    • lrange

  • Set

    • smembers
    • zrange

• 如果业务场景就是需要获取全量数据咋办？

  • 使用 SSCAN、HSCAN等命令分批返回集合数据
  • 把大集合拆成小集合，比如按照时间、区域等划分

数据保存规范

冷热数据分离

• 虽然 Redis 支持使用 RDB 快照和 AOF 日志持久化保存数据

  • 提供数据可靠性保证的
  • 并不是用来扩充数据容量的

• 不要什么数据都存在 Redis

  • 应该作为缓存保存热数据

业务数据隔离

• 不要将不相关的数据业务都放到一个 Redis 中

  • 1 避免业务相互影响

  • 2 避免单实例膨胀

    • 能在故障时降低影响面，快速恢复

设置过期时间

• 写入 Redis 的数据会一直占用内存，如果数据持续增多，就可能达到机器的内存上限，造成内存溢出，导致服务崩溃
• 建议你根据业务使用数据的时长，设置数据的过期时间

控制单实例的内存容量

• 建议设置在 2~6 GB

  • 无论是 RDB 快照，还是主从集群进行数据同步，都能很快完成

    • 不会阻塞正常请求的处理。

防止缓存雪崩

• 避免集中过期 key 导致缓存雪崩。

• 当某一个时刻出现大规模的缓存失效的情况

  • 就会导致大量的请求直接打在数据库上面
  • 导致数据库压力巨大
  • 高并发环境下，可能瞬间就会导致数据库宕机

运维规范

使用 Cluster 集群或者哨兵集群，做到高可用

• Redis-Sentinel

  • 是redis官方推荐的高可用性解决方案

  • redis 主从复制

    • 问题

      • redis本身或者客户端都没有实现主从切换的功能。
      • 需要人为修改所有应用方的主节点地址
      • 需要命令所有从节点复制新的主节点

  • 当用redis作master-slave的高可用时

    • 如果master本身宕机，
    • redis-sentinel就是一个独立运行的进程
    • 用于监控多个master-slave集群
    • 自动发现master宕机，进行自动切换slave > master。

• Redis Cluster 集群

  • 主要解决了大数据量存储导致的各种慢问题，同时也便于横向拓展。

  • 横向扩展的 Redis 切片集群

  • Redis 集群是一种分布式数据库方案

    • 集群通过分片（sharding）来进行数据管理
    • 并提供复制和故障转移功能

实例设置最大连接数，防止过多客户端连接导致实例负载过高，影响性能

不开启 AOF 或开启 AOF 配置为每秒刷盘，避免磁盘 IO 拖慢 Redis 性能

设置合理的 repl-backlog，降低主从全量同步的概率

设置合理的 slave client-output-buffer-limit，避免主从复制中断情况发生

根据实际场景设置合适的内存淘汰策略

使用连接池操作 Redis

XMind - Trial Version