以下文章基于Redis3.0以上版本源码进行分析解读
我们在上一篇文章Redis之EventLoop分析中知道:
- Reids Server中所有的操作都是通过Event Loop单线程串行调度的
- Event Loop中每个loop中除了处理当前io event外, 还会处理内存回收、RDB刷出及复制等逻辑
由此可知，影响Redis单点性能的操作主要会有以下几个方面:
- Blocking Command的处理(blpop、pubsub...)
- 内存数据的频繁刷出(RDB/AOF)
先来分析一下为什么Blocking Command会对性能有很大影响
遍历所有的key和blocked client
redis中block command侦听数据结构&处理逻辑
- redis server会有一个全局链表 readkeys, 保存了所有被blpop block的key
- 链表中的每个节点保存了一个当前key上所有blocked client
- redis 在每次处理command完成后, 都会通过一个双层循环
- 由于每次请求的处理都需要完成block client的侦听逻辑, 当有大量block client的时候, 就会导致每次请求的处理时延都会增加
- 当然大量block client对于server端的链接维护也是个负担
RDB/AOF频繁刷出对于性能的影响分析
重温一下event loop的处理机制
- time event会在event loop中被串行执行.
- time event中会有比较多的高成本操作, 如db rehash、统计、RDB（AOF）数据刷出
- 其中最大的性能瓶颈就是数据的刷出, 因为Redis默认是fork一个子进程, 将当前内存中的数据按照一定格式写入到本地文件中,
如果当一个redis存在大量的写入请求, 并且rdb的flush策略没有很好配置的时候, 可能每秒都会触发数据的刷出, Disk IO的高负载会导致整体处理时延的提升, 最终租塞Event Loop的线程
