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