redis优化和常见问题

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

   RDB和AOF的时候，会生成RDB快照，AOF rewrite，耗费磁盘IO。
   fork（在redis持久化的时候会调用glibc的fork函数产生一个子进程，用子进程进行快照生成）的时候，子进程是需要拷贝父进程的空间内存页表的，也是会耗费一定时间的。
   一般来说，如果父进程内存有1个G的数据，那么fork可能会耗费20ms左右，如果是10G-30G，那么会耗费20ms * 10 ~ 20ms * 30,也就是击败毫秒的时间，info stat中的latest_fork_usec，可以看到最近一次fork的时长。
   优化思路：fork耗时跟内存大小有关，一般将redis大小控制在10G左右。

2. AOF的阻塞问题

   redis将数据写入AOF缓存区，单独开启一个线程做fsync操作，每秒一次。
   但是redis主线程会检查两次fsync的时间，如果距离上一次fsync时间超过两秒，那么写请求就会阻塞everysec,最多丢失2秒数据。
   一旦fsync超过2秒延迟，整个redis就会被拖慢。
   优化思路：优化硬盘写入速率，建议采用ssd，增加硬盘读写速度。

3. 主从复制延迟问题

   主从复制可能会超时严重，这时候需要很好的监控和报警机制。
   在info replication中，可以看到master和slave复制的offset，做一个差值就可以看到延迟量
   如果延迟量过多，那么就进行报警。
   思路：可以写一个脚本去计算延迟量，超过定值则通知监控系统，redis自身有pub/sub机制。

4. 主从复制风暴问题

   如果一下子让很多slave去同步master数据，一份大的rdb文件同时发送给多个slave，会导致网络带宽被占满。
   优化思路：如果一个master要挂载很多slave，使用树状结构（master下挂slave，slave下在挂slave），而不是星形结构。

5. vm.overcommit_memory

   0：检查有没有足够的内存空间，没有则申请内存失败。
   1：允许使用内存直至用完位置。
   2：内存地址空间不能超过swap+50%
   如果是0的话，可能会导致fork等操作失败。申请不到足够的内存空间。
   优化思路：将overcommit_memory设置为1。
   echo "overcommit_memory=1">>/etc/sysctl.conf
   sysctl -p
6. swapiness
   cat /proc/version 查看内核版本
   如果内核版本超过<3.5，那么swapiness设置为0，这样宁愿swap也不会oom killer(杀死进程)。
   如果内核版本超过>3.5，那么swapiness设置为1，这样宁愿swap也不会oom killer(杀死进程)。
   保证redis不会被杀掉。
   优化思路：
   echo 0 > /proc/sys/vm/swappness
   echo vm.swapiness=0 >> sysctl.conf
   sysctl -p
7. 打开最大句柄
   ulimit -n 10032 10032
8. tcp backlog
   cat /proc/sys/net/core/somaxconn
   echo 511 >  /proc/sys/net/core/somaxconn