内存分配控制
-
vm.overcommit_memory
vm.overcommit_memory的三个可选值及说明 - 获取和设置
# cat /proc/sys/vm/overcommit_memory 获取
echo "vm.overcommit_memory=1" >> /etc/sysctl.conf # 设置
sysctl vm.overcommit_memory=1
-
获取和设置
Redis设置合理的maxmemory，保证机器有20%~30%的闲置内存。
集中化管理AOF重写和RDB的bgsave。
设置vm.overcommit_memory=1，防止极端情况下会造成fork失败。 -
swappiness参数说明
swap对于操作系统来比较重要，当物理内存不足时，可以将一部分内存页进行swap操作，已解燃眉之急。
swapniess重要值策略说明 - 设置方法
# echo {bestvalue} > /proc/sys/vm/swappiness 系统重启后就会失效
echo vm.swappiness={bestvalue} >> /etc/sysctl.conf
需要注意/proc/sys/vm/swappiness是设置操作，/etc/sysctl.conf是追加操作。
-
如何监控swap
（1）查看swap的总体情况
free–m
（2）实时查看swap的使用
vmstat 1 每隔一秒输出
（3）查看指定进程的swap使用情况
redis-cli -h ip -p port info server | grep process_id # 获取redis进程
process_id:986
cat /proc/986/smaps # 查询swap信息
cat /proc/986/smaps | grep Swap #每个内存块镜像信息中，这个进程使用到的swap量
- 其他优化
## THP
echo never > /sys/kernel/mm/transparent_hugepage/enabled
## OOM killer 从-15到-17设置越小越好
echo {value} > /proc/${process_id}/oom_adj
flushall/flushdb误操作
-
缓存与存储
缓存：对后端数据源造成一定的负载压力
存储：很严重 -
借助AOF机制恢复
appendonly no：对AOF持久化没有任何影响，因为根本就不存在AOF文件。
appendonly yes：只不过是在AOF文件中追加了一条记录，虽然Redis中的数据被清除掉了，但是AOF文件还保存着flush操作之前完整的数据，这对恢复数据是很有帮助的。
1）如果发生了AOF重写，Redis遍历所有数据库重新生成AOF文件，并会覆盖之前的AOF文件。
1.调大AOF重写参数auto-aof-rewrite-percentage和auto-aof-rewrite-minsize，让Redis不能产生AOF自动重写。
2.拒绝手动bgrewriteaof。
2）如果要用AOF文件进行数据恢复，那么必须要将AOF文件中的flushall相关操作去掉，为了更加安全，可以在去掉之后使用redis-check-aof这个工具去检验和修复一下AOF文件，确保AOF文件格式正确，保证数据恢复正常。
-
RDB有什么变化
1.必须自动策略是关闭的并且没有手动执行过save、bgsave或者发生了主从的全量复制
综上所述，如果AOF已经开启了，那么用AOF来恢复是比较合理的方式，但是如果AOF关闭了，那么RDB虽然数据不是很实时，但是也能恢复部分数据，完全取决于RDB是什么时候备份的。
处理bigkey
- 字符串类型：体现在单个value值很大，一般认为超过10KB就是bigkey，但这个值和具体的OPS相关。
- 非字符串类型：哈希、列表、集合、有序集合，体现在元素个数过多。
bigkey的危害 - 内存空间不均匀（平衡）：例如在Redis Cluster中，bigkey会造成节点的内存空间使用不均匀。
- 超时阻塞：由于Redis单线程的特性，操作bigkey比较耗时，也就意味着阻塞Redis可能性增大。
- 网络拥塞：
bigkey造成网络拥塞示意图
如何发现
127.0.0.1:6379> debug object key
Value at:0x7fc06c1b1430 refcount:1 encoding:raw serializedlength:1256350 lru:11686193
lru_seconds_idle:20
可以发现serializedlength=11686193字节，约为1M，同时可以看到encoding是raw，也就是字符串类型，那么可以通过strlen来看一下字符串的字节数为2247394字节，约为2MB：
127.0.0.1:6379> strlen key
(integer) 2247394
- 被动收集：当抛出异常时打印出所操作的key
- 主动检测：scan+debug object
如何删除
Redis将在4.0版本支持lazy delete free的模式，那时删除bigkey不会阻塞Redis。
寻找热点key
客户端
客户端进行热点key的统计
代理端
基于代理的热点key统计
Redis服务端
使用monitor命令统计热点key
机器
Redis客户端使用TCP协议与服务端进行交互，通信协议采用的是RESP。
机器Redis TCP包分析
寻找热点key的四种方案
本章重点回顾
1）Linux相关优化：
·vm.overcommit_memory建议为1。
·Linux>3.5，vm.swappiness建议为1，否则建议为0。
·Transparent Huge Pages（THP）建议关闭掉，但需要注意Linux发行版本改变了THP的配置位置。
·可以为Redis进程设置oom_adj，减少Redis被OOM killer杀掉的概率，但不要过度依赖此特性。
·建议对Redis所有节点所在机器使用NTP服务。
·设置合理的ulimit保证网络连接正常。
·设置合理的tcp-backlog参数。
2）理解Redis的持久化有助于解决flush操作之后的数据快速恢复问题。
3）Redis安全建议：
·根据具体网络环境决定是否设置Redis密码。
·rename-command可以伪装命令，但是要注意成本。
·合理的防火墙是防止攻击的利器。
·bind可以将Redis的访问绑定到指定网卡上。
·定期备份数据应该作为习惯性操作。
·可以适当错开Redis默认端口启动。
·使用非root用户启动Redis。
4）bigkey的危害不容忽视：数据倾斜、超时阻塞、网络拥塞，可能是Redis生产环境中的一颗定时炸弹，删除bigkey时通常使用渐进式遍历的方式，防止出现Redis阻塞的情况。
5）通过客户端、代理、monitor、机器抓包四种方式找到热点key，这几种方式各具优势，具体使用哪种要根据当前场景来决定。
