走进KeyDB
项目git地址:https://github.com/JohnSully/KeyDB
网上公开的技术细节比较少,本文基本是通过阅读源码总结出来的,如有错漏之处欢迎指正。
多线程架构
线程模型
KeyDB将redis原来的主线程拆分成了主线程和worker线程。每个worker线程都是io线程,负责监听端口,accept请求,读取数据和解析协议。如图所示:
KeyDB使用了SO_REUSEPORT特性,多个线程可以绑定监听同个端口。
每个worker线程做了cpu绑核,读取数据也使用了SO_INCOMING_CPU特性,指定cpu接收数据。
解析协议之后每个线程都会去操作内存中的数据,由一把全局锁来控制多线程访问内存数据。
主线程其实也是一个worker线程,包括了worker线程的工作内容,同时也包括只有主线程才可以完成的工作内容。在worker线程数组中下标为0的就是主线程。
主线程的主要工作在实现serverCron,包括:
- 处理统计
- 客户端链接管理
- db数据的resize和reshard
- 处理aof
- replication主备同步
- cluster模式下的任务
链接管理
在redis中所有链接管理都是在一个线程中完成的。在KeyDB的设计中,每个worker线程负责一组链接,所有的链接插入到本线程的链接列表中维护。链接的产生、工作、销毁必须在同个线程中。每个链接新增一个字段int iel; /* the event loop index we're registered with */
用来表示链接属于哪个线程接管。
KeyDB维护了三个关键的数据结构做链接管理:
- clients_pending_write:线程专属的链表,维护同步给客户链接发送数据的队列
- clients_pending_asyncwrite:线程专属的链表,维护异步给客户链接发送数据的队列
- clients_to_close:全局链表,维护需要异步关闭的客户链接
分成同步和异步两个队列,是因为redis有些联动api,比如pub/sub,pub之后需要给sub的客户端发送消息,pub执行的线程和sub的客户端所在线程不是同一个线程,为了处理这种情况,KeyDB将需要给非本线程的客户端发送数据维护在异步队列中。
同步发送的逻辑比较简单,都是在本线程中完成,以下图来说明如何同步给客户端发送数据:
如上文所提到的,一个链接的创建、接收数据、发送数据、释放链接都必须在同个线程执行。异步发送涉及到两个线程之间的交互。KeyDB通过管道在两个线程中传递消息:
int fdCmdWrite; //写管道
int fdCmdRead; //读管道
相关文章