KeyDB专案是从redis fork出来的分支。众所周知redis是一个单执行绪的kv内存储存系统，而KeyDB在100%相容redis API的情况下将redis改造成多执行绪。

专案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处理aofreplication主备同步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; //读管道

本地执行绪需要异步传送资料时，先检查client是否属于本地执行绪，非本地执行绪获取到client专属的执行绪ID，之后给专属的执行绪管到传送AE_ASYNC_OP::CreateFileEvent的操作，要求新增写socket事件。专属执行绪在处理管道讯息时将对应的请求新增到写事件中，如图所示：

redis有些关闭客户端的请求并非完全是在连结所在的执行绪执行关闭，所以在这里维护了一个全域性的异步关闭连结串列。

锁机制

KeyDB实现了一套类似spinlock的锁机制，称之为fastlock。

fastlock的主要资料结构有：

struct ticket

{

uint16_t m_active; //解锁+1

uint16_t m_avail; //加锁+1

};

struct fastlock

{

volatile struct ticket m_ticket;

volatile int m_pidOwner; //当前解锁的执行绪id

volatile int m_depth; //当前执行绪重复加锁的次数

};

使用原子操作__atomic_load_2，__atomic_fetch_add，__atomic_compare_exchange来通过比较m_active=m_avail判断是否可以获取锁。

fastlock提供了两种获取锁的方式：

try_lock：一次获取失败，直接返回lock：忙等，每1024 * 1024次忙等后使用sched_yield 主动交出cpu，挪到cpu的任务末尾等待执行。在KeyDB中将try_lock和事件结合起来，来避免忙等的情况发生。每个客户端有一个专属的lock，在读取客户端资料之前会先尝试加锁，如果失败，则退出，因为资料还未读取，所以在下个epoll_wait处理事件循环中可以再次处理。

Active-Replica

KeyDB实现了多活的机制，每个replica可设定成可写非只读，replica之间互相同步资料。主要特性有：

每个replica有个uuid标志，用来去除环形复制新增加rreplay API，将增量命令打包成rreplay命令，带上本地的uuidkey，value加上时间戳版本号，作为冲突校验，如果本地有相同的key且时间戳版本号大于同步过来的资料，新写入失败。采用当前时间戳向左移20位，再加上后44位自增的方式来获取key的时间戳版本号。