redis实践中的常见问题以及优化
1、fork耗时导致高并发请求延时
  生成RDB快照、AOF重写,耗费磁盘的IO的过程，主进程fork子进程，子进程需要拷贝父进程的空间内存页表
  一般来说，如果父进程内存1G数据，那么fork可能会耗费20ms左右，通过info stats中的latest_fork_usec，可以看到最近一次fork的时长。
  所以一般优化控制redis内存在10G以内。
2、AOF阻塞问题
  redis将数据写入AOF缓冲区，会单独开一个线程做fsync,每秒一次，redis主线程会检查两次fsync时间，如果距离上次fsync时间超过了两秒
  那么写请求就会阻塞，everysec，最多丢失2秒的数据。
  优化硬盘写入速度，使用SSD盘
3、主从复制延时问题
  主从复制可能会超时严重，需要良好的监控与报警机制
  1、在info replication中，可以看到master和slave的offset，做一个差值就能算出延迟，如果延迟过多就进行报警
     并通知客户端从节点延迟过高。 可以采用Zookeeper的监听回调机制实现客户端通知。
     客户端接到具体的从节点高延迟通知后， 修改读命令路由到其他从节点或主节点上。 
     当延迟恢复后，再次通知客户端，恢复从节点的读命令请求。
     这种方案的成本比较高， 需要单独修改适配Redis的客户端类库。
     如果涉及多种语言成本将会扩大。客户端逻辑需要识别出读写请求并自动路由，还需要维护故障和恢复的通知。
  2、调整从库运行方式slave-serve-stale-data参数 
      yes：从库会继续响应客户端的请求 
      no:除去INFO和SLAVOF命令之外的任何请求都会返回一个错误”SYNC with master in progress”
  3、采用Redis集群方案做水平扩展。
  4、通过配置控制同步时间与延时一定程度减少延时，减少异步数据复制丢失脑裂丢失数据问题
     min-slaves-to-write 1 min-slaves-max-lag 10
     至少有1个slave，数据复制和同步延迟不能超过10秒
     如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么master就会拒绝接收任何请求
   5、生产者层面做限流降级
     先将消息写入本地磁盘或者写入消息队列，开启定时任务定时将消息重新推送master。
4、主从复制风暴问题
  如果多个slave同时执行全量复制，一份大的RDB同时发送到多个slave，会导致网络宽带被严重占用。
  slave尽量用树状结构，不要用星型结构。
5、vm.overcommit_memory用来设置内存分配策略 有三种选项
  0:检查有没有足够内存，没有的话申请内存失败 ,可能导致fork失败，申请不到内存
  1:允许使用内存直到用完为止
  2:内存地址空间不能超过SWAP +50%
6、swapiness 当物理内存不足时， 可以将一部分内存页进行swap操作，swap空间由硬盘提供系统参数swppiness会决定操作系统使用swap的倾向程度
  0:Linux3.5以及以上，宁愿用OOM killer也不用swap
  1:Linux3.4以及更早，宁愿用swap也不用OOM killer
  60: 默认值
  100: 操作系统会主动地使用swap
7、打开最大文件句柄  ulimit -n
8、tcp backlog 控制队列长度 半连接状态队列和全连接队列