Redis内存优化

1、键值设计

一、key名设计

三大建议

• 可读性和可管理性

以业务名（或数据库名）为前缀（防止key冲突），用冒号分隔，好比业务名:表名:id

• 简洁性

保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视 (embstr 3-39)

• 不包含特殊字符

反例：包含换行 等

二、value设计

• 拒绝bigkey
• 选择合适的数据结构
• 过时设计

string类型控制在10kb以内
hash、list、set、zset元素个数不超过5000
反例 一个包含几百万个元素的list、hash等，一个巨大的json字符串
bigkey的危害

• 网络阻塞
• 慢查询
• 节点数据不均衡
• 反序列消耗

Redis客户端自己不负责序列化
应用频繁序列化和反序列化bigkey：本地缓存或者Redis缓存

bigkey发现

• 应用异常
• redis-cli --bigkeys
• scan + debug object
• 主动报警
• 内核热点key问题优化

三、bigkey问题

bigkey的删除

• 阻塞：注意隐性删除（rename、过时等）
• lazy delete(unlink命令)

bigkey的预防

• 优化数据结构：例如二级拆分
• 物理隔离或者万兆网卡：不是治标方案
• 命令优化：例如hgetall->hget、hscan
• 报警和按期优化

键值生命周期

• 周期数据须要设置过时时间，object idle time能够找垃圾key-value
• 过时时间不宜集中：缓存穿透和雪崩问题

命令优化

• O(N)以上的命令关注N的数量
• 禁用命令 keys flush flushdb等
• 合理使用select redis的多数据库较弱，使用数字进行区分 不少客户端支持较差
• Redis事物功能较弱，不建议过多使用
• Redis集群版本在使用Lua上有特殊要求
• 必要状况下使用monitor命令时，要注意不要长时间使用

客户端优化
避免多个应用使用一个Redis实例
不相干的业务拆分，公共数据作服务化
使用链接池

最大链接池的设置
maxIdle接近maxTotal便可
业务但愿Redis达到的并发量
客户端执行命令时间
Redis资源
资源开销
例子：一次命令时间的平均耗时为1ms，一个链接的QPS大约是1000
业务指望的QPS是50000
理论的maxTotal = 50000/1000 = 50个

2、内存优化

一、内存消耗

• 内存使用统计
• 内存消耗划分
• 子进程内存消耗

内存划分：自身内存（800k左右），对象内存，缓存内存，Lua内存，内存碎片
内存消耗：自身内存，缓冲内存(客户端缓冲器，复制缓冲区，AOF缓冲区)，对象内存（key，value）
客户端缓冲区

• 普通客户端

输入缓冲区，最大1GB，超事后会被强制断开，不可动态设置
输出缓冲区配置 client-output-buffer-limit <class> <hard limiy> <soft limit> <soft seconds>
class客户端类型，分为三种 普通客户端 slave从节点客户端 pubsub发布订阅客户端
hard limit 若是客户端使用的输出缓冲区大于 hard limit 客户端会被当即关闭
soft limit和soft seconds 若是客户端使用的输出缓冲区超过了soft limit而且持续了soft seconds客户端会被当即关闭

默认 client-output-buffer-limit normal 0 0 0
默认 没有限制客户端缓冲
注意 防止大的命令或者monitor

• slave客户端

默认 client-output-buffer-limit slave 256mb 64mb 60
阻塞 主从延迟较高，或者从节点过多
注意 主从网络，从节点不要超过2个

• pubsub客户端

默认 client-output-buffer-limit pubsub 32mb 8mb 60
阻塞 生产大于消费
注意 根据实际场景适当调试

缓冲内存
复制缓冲区：此部份内存独享，考虑部分复制，默认是1MB，能够设置更大
AOF缓冲区：AOF重写器键，AOF的缓冲区，没有容量限制

对象内存
key：不要过长，量大不容忽视（redis3:embstr 39字节）
value：ziplist，intset等优化方式

内存碎片

必然存在 jemalloc
优化方式：
避免频繁更新操做： append setrange等
安全重启 例如redis sentinel和redis-cluster等

子进程内存消耗

必然存在 fork(bgsave和bgrewriteaof)
优化方式：
去掉THP特性
观察写入量

二、内存管理

• 设置内存上限

定义实例最大内存，便于管理机器内存，通常预留30%

• 动态调整内存上限

config set maxmemory 6GB
config rewrite

• 内存回收策略

删除过时键值

惰性删除：访问key->expired dict -> del key
定时删除：每秒运行10次，采样删除

内存溢出
超过maxmemory后触发响应策略，由maxmemory-policy控制

三、内存优化

内存分布
自身内存，缓冲内存，对象内存
合理选择数据结构
独立统计：集合，MitMaps，HyperLogLog
客户端内存优化
客户端缓冲区
输入缓冲区：最大1G
一次内存暴增 可能缘由：

• 批量写入
• 主从不一致
• 客户端溢出

处理和预防：
找到对应的业务方直接干掉
运维层面：线上Redis禁用monitor，适度限制缓冲区大小
开发层面：理解monitor的原理，也能够短暂寻找热点key，使用CacheCloud能够直接监控到

四、Redis运维

Linux内核优化
overcommit含义：
0 表示内核将检查是否由足够的可用内存，若是有足够的可用内存，内存申请经过，不然内存申请不经过，并把错误返回给应用进程
1 表示内核运行超量使用内存知道用完为止
2 表示内核坚定不过两的使用内存，即系统整个内存地址空间不超过swap+50%的RAM值，50%是overmit_ratio默认值，此参数一样支持修改
获取
cat /proc/sys/vm/overcommit_memory
设置
echo "vm.overcommit_memory=1" >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1
最佳实践：

• Redis设置合理的maxmory，保证机器有20%-30%的闲置内存
• 集中化管理AOF重写的RDB的bgsave

swappiness最佳实践

• vm.swappiness=1

物理内存充足的时候，使Redis足够快
物理内存不足的时候，避免Redis死掉

• THP

做用：加速fork
建议：禁用，可能产生更大的内存消耗
设置方法：echo never > /sys/kernel/mm/transparent_hugepage/enabled

• OOM killer

做用：内存使用超出，操做系统按照规则kill掉某些进程
配置方法：/proc/{progress_id}/oom_adj越小，被杀掉的几率越小
运维经验：不要过分依赖此特性，应该合理管理内存

安全的Redis

被攻击Redis的特征：

• redis所在的机器有外网IP
• Redis以默认端口6379为启动端口，而且是对外网开放的
• Redis是以root用户启动的
• Redis没有设置密码
• Redis的bind设置为0.0.0.0或者""

攻击方式：

• flushall
• set crakit id_rsa.pub
• config set dir
• config set dbfilename
• save

安全七法则

• 设置密码：

服务端配置：requirepass和masterauth
客户端链接：auth命令和-a参数
相关建议
密码要足够复杂，防止暴力破解
masterauth不要忘记
auth仍是经过铭文传输

• 假装危险命令

服务端配置:rename-command为空或者随机字符串
客户端链接：不可用或者使用指定随机字符串
相关建议
不支持config set 动态设置
RDB和AOF若是包含了rename-command以前的命令，将没法使用
config命令自己是再Redis内核会使用到，不建议使用

• bind

服务端配置：bind限制的是网卡，并非IP
相关建议
bind不支持 config set
bind 127.0.0.1须要谨慎

• 防火墙：杀手锏
• 按期备份
• 不使用默认端口，防止被若攻击杀掉
• 使用非root用户启动

热点key

• 客户端
• 代理端
• 服务端
• 机器搜集