redis6.4 多线程

resid要处理命令，则redis必须完整地接收客户端的请求，并将命令解析出来，再将结果读出来，通过网络回写到客户端。整个工序分为以下几个部分：

• 接收。通过TCP接收到命令，可能会历经多次TCP包、ack、IO操作
• 解析。将命令取出来
• 执行。到对应的地方将value读出来
• 返回。将value通过TCP返回给客户端，如果value较大，则IO负荷会更重

异步的效率更高，要实现高并发必须要异步，因为同步有太多时间浪费在等待上了，遇到网络不好的客户端直接就被拖垮。异步的策略简单可总结如下：

• 网络包有数据了，就去读一下放到缓冲区，读完立马切到其他事情上，不等下一个包
• 解析下缓冲区数据是否完整。如完整则执行命令，不完整切到其他事情上
• 数据完整了，立即执行命令，将执行结果放到缓冲区
• 将数据给客户端，如果一次给不完，就等下次能给时再给，不等，直到全部给完

事件驱动

异步没有零散的等待，但有个问题是，如果redis不一直阻塞等命令来，咋个知道“网络包有数据了”、“下次能给时”这两个时机？ 如果一直去轮训问肯定效率很低，要有个高效的机制，来通知redis这两个时刻，由这些时刻来触发动作。 这就是事件驱动。

一个tcp包来了、有数据可以写给客户端 这两个时机都是事件。与之对应的就是redis和客户端之间socket的可读、可写事件[1] ，就像微信聊天中新消息提醒一样。 linux中的epoll就是干这个事的，redis基于epoll等机制抽象出了一套事件驱动框架[2]，整个server完全由事件驱动，有事件发生就处理，没有就空闲等待。

redis6多线程主要解决 socket 可读可写的网络IO等待，命令的执行还是单线程处理