就在 2019 年 12 月 20 号这天,众所期待的 Redis 新版 6.0 rc1 发布了(Redis 6 RC1 is out today)肯定很多关注的同学都进行了试用,虽然因为引入了 c11 的 _Atomic 导致相当多的环境都无法直接编译成功,但是对于想一探究竟的粉丝们来说,这是完全阻挡不了的热情,当然我也不例外~<狗头>~~
新版除了增加
ACLS 权限控制模块
、支持更为广泛的新协议 RESP3
、客户端缓存
、无磁盘同步
、Cluster Proxy
等十来个相当实用的新特性外,还对 长久以来 社区筒子们 呼声比较高的 多线程 进行了支持,当然也带来 性能提升了一倍 的好处这次我们的任务有两个:
剖析 Redis6 多线程的实现方式
与 Memcached 的多线程模型(个人认为这是一个极其经典的多线程网络编程案例)进行对比
历史原因分析
众所周知,Redis 之前的版本一直都是典型的单线程模型(注意:这里不是指 Redis 单实例中只有一个线程,而是表示 核心操作模块由单线程完成,当然另外还有一些 辅助线程 从旁协助,比如 LRU 的淘汰过程
),为什么不使用多线程呢,其实原因很简单(官方解释)
简单说来就是:
- 根据以往的场景,普通 KV 存储 瓶颈压根不在 CPU,而往往可能受到
内存
和网络I/O
的制约 - Redis 中有各种类型的数据操作,甚至包括一些事务处理,如果采用多线程,则会被多线程产生的切换问题而困扰,也可能因为加锁导致系统架构变的异常复杂,更有可能会因为加锁解锁甚至死锁造成的性能损耗
当然,单线程也会有 不能充分利用多核资源 弊端,这是一个权衡;而通常 Redis(包括 Redis cluster) 的性能已经足够我们使用,如果有想了解具体 Redis 如何实现如此高性能 的同学,请看 渐进式解析 Redis 源码 - 事件 ae
那么,既然 单线程 都已经基本能满足场景,更不要说还能开启 多实例、上集群 等方式,那么为什么还要费力引入 多线程呢? 请继续阅读后方内容~~~
引入多线程
上面提到,瓶颈往往在 内存
和 网络I/O
内存方面毋容置疑,加就是了,虽然需要注意 NUMA陷阱(请自行 Google),但是也不是不能解决;
那么能不能对 网络I/O 进行进一步优化从而减少消耗呢,通常做法是:
采用 DPDK 从内核层对网络处理流程模块进行优化
(因为需要特殊支持,所以显得不那么大众)利用多核优势
于是 Redis 开发组的各位大佬们就想到 能不能通过 支持多线程 这一简单惠民的方式进行解决(这里也体现了大佬们对性能的极限追求),于是就有了 下面的架构(以 Read 为例):
根据上方结构简图可以看到,Redis 6 中的多线程 主要在处理 网络 I/O 方面,对网络事件进行监听,分发给 work thread 进行处理,处理完以后将主动权交还给 主线程,进行 执行操作,当然后续还会有,执行后依然交由 work thread 进行响应数据的 socket write 操作
源码剖析
根据以往风格,代码还是进行说明的,如果您只是为了了解原理结构,对实现细节不是那么感兴趣的话,请移步到下一趴: 与 Memcached 多线程模型对比
由于有些方法里的代码量比较大,我们这里按照 典型的代码片段进行解析,同志们可以根据文章提示的代码位置 和 代码里面的关键词 在源码中搜素,可能数据结构一些元素 看不太懂什么意思,没关系,先混个脸熟,后面看完回头再看过来或者单独把代码 clone 下来读一下 就明白了
声明,我们代码均来源于 官方github https://github.com/antirez/redis/tree/6.0 ,本次源码基本都存在与 src/network.c
中
redis-server 逻辑首先执行 initThreadedIO()
函数对 线程进行初始化,当然,也包括 根据配置 server.io_threads_num
控制线程个数,其中主线程的处理逻辑为 IOThreadMain()
函数
handleClientsWithPendingReadsUsingThreads()
待处理任务分配
之前在 渐进式解析 Redis 源码 - 事件 ae 提到过,处理新连接调用 acceptCommonHandler()
函数进行处理,随后调用 createClient()
创建 client 连接结构数据 并通过 connSetReadHandler()
设定 readQueryFromClient()
函数为处理 读取事件的主要逻辑,执行顺序为:
acceptTcpHandler/acceptUnixHandler
acceptCommonHandler
createClient
->connSetReadHandler
readQueryFromClient
readQueryFromClient()
函数
函数 postponeClientRead()
将任务放入处理队列,而根据上面 IOThreadMain()
和 handleClientsWithPendingReadsUsingThreads()
的任务处理逻辑进行处理
与 Memcached 多线程模型对比
那么 Redis 6 中的 多线程模型 与 Memcached 这一及其经典的多线程网络编程案例中的模型 对比起来有哪些异同呢
首先,我们先来复习一下 Memcached 的线程机制 :
Memcached 服务器采用 master-woker 模式进行工作,后再辅以 辅助线程。
服务端采用 socket 与客户端通讯,主线程、工作线程 采用 pipe管道进行通讯。
主线程采用 libevent 监听 listen、accept 的读事件,事件响应后 将连接信息的数据结构封装起来 根据算法 选择合适的工作线程,将 连接任务携带连接信息 分发出去,相应的线程利用连接描述符 建立与 客户端的socket连接 并进行后续的存取数据操作。
主线程和工作线程 处理事件流都采用状态机进行事件转移。
那么显而易见,他们的 线程模型 对比起来:
- 相同点:都采用了 master-worker 这一经典思路
- 不同点:Memcached 执行主逻辑也是在 worker 线程里,模型更加简单,不过这也归功于 Memcached 简易数据操作的特性产生的天然隔离;而 Redis 把处理逻辑还 交还给 master 线程,虽然一定程度上增加了模型复杂度,但是如果把处理逻辑放在 worker 线程,也很难保证隔离性
总结
Redis 多线程模型 可能无法满足很多 粉丝设想的 类 Memcached 这种具有完全隔离性的多线程模型,但这也是各方面利弊的权衡,有失必有得,好在新版的性能着实也给了我们惊喜,还算是比较满足,期待 stable版 尽快与大家见面!!!
本文作者: wettper
本文链接: http://www.web-lovers.com/redis-source-set.html
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处!