以下文章基于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完成后, 都会通过一个双层循环

1. 由于每次请求的处理都需要完成block client的侦听逻辑, 当有大量block client的时候, 就会导致每次请求的处理时延都会增加
2. 当然大量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的线程