Redis学习--开发运维的陷阱

内存分配控制

• 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，这几种方式各具优势，具体使用哪种要根据当前场景来决定。