22. redis在实践中的一些常见问题以及优化思路（包含linux内核参数优化）

可以用公司里的一些已有的数据，导入进去，几百万，一千万，进去做各种压力测试，性能，redis-benchmark，并发，QPS，高可用的演练，每台机器最大能存储多少数据量，横向扩容支撑更多数据。

fork耗时导致高并发请求延时

现象

1. RDB和AOF的时候，其实会有生成RDB快照，AOF rewrite，耗费磁盘IO的过程，主进程fork子进程
2. fork的时候，子进程是需要拷贝父进程的空间内存页表的，也是会耗费一定的时间的
3. 一般来说，如果父进程内存有1个G的数据，那么fork可能会耗费在20ms左右，如果是10G~30G，那么就会耗费20 * 10，甚至20 * 30，也就是几百毫秒的时间
4. info stats中的latest_fork_usec，可以看到最近一次form的时长
   
5. redis单机QPS一般在几万，fork可能一下子就会拖慢几万条操作的请求时长，从几毫秒变成1秒

优化思路

fork耗时跟redis主进程的内存有关系，一般控制redis的内存在10GB以内，如果太大，slave -> master，全量复制太大，也会出现问题的。

AOF的阻塞问题

1. redis将数据写入AOF缓冲区，单独开一个线程，做fsync操作，每秒一次
2. 但是redis主线程会检查两次fsync的时间，如果距离上次fsync时间超过了2秒，那么写请求就会阻塞
3. everysec，最多丢失2秒的数据
4. 一旦fsync超过2秒的延时，整个redis就被拖慢

优化思路

优化硬盘写入速度，建议采用SSD，不要用普通的机械硬盘，SSD，大幅度提升磁盘读写的速度

主从复制延迟问题

1. 主从复制可能会超时严重，这个时候需要良好的监控和报警机制
2. 在info replication中，可以看到master和slave复制的offset，做一个差值就可以看到对应的延迟量
   
3. 如果延迟过多，那么就进行报警

主从复制风暴问题

1. 如果一下子让多个slave从master去执行全量复制，一份大的rdb同时发送到多个slave，会导致网络带宽被严重占用
2. 如果一个master真的要挂载多个slave，那尽量用树状结构，不要用星型结构
   

linux – vm.overcommit_memory

1. 0: 检查有没有足够内存，没有的话申请内存失败
2. 1: 允许使用内存直到用完为止
3. 2: 内存地址空间不能超过swap + 50%

如果是0的话，可能导致类似fork等操作执行失败，申请不到足够的内存空间

cat /proc/sys/vm/overcommit_memory
echo "vm.overcommit_memory=1" >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1

swapiness

1. cat /proc/version，查看linux内核版本
2. 如果linux内核版本<3.5，那么swapiness设置为0，这样系统宁愿swap也不会oom killer（杀掉进程）
3. 如果linux内核版本>=3.5，那么swapiness设置为1，这样系统宁愿swap也不会oom killer
4. 保证redis不会被杀掉

echo 0 > /proc/sys/vm/swappiness
echo vm.swapiness=0 >> /etc/sysctl.conf

最大打开文件句柄

1. ulimit -n 10032 10032

百度一下，不同的操作系统，版本，设置的方式都不太一样

tcp backlog

cat /proc/sys/net/core/somaxconn
echo 511 > /proc/sys/net/core/somaxconn