epoll

  1. 服务器启动以后，服务端会去调用epoll_create，创建一个epoll实例，epoll实例中包含两个数据。
    • 红黑树（为空）：rb_root 用来去记录需要被监听的FD。
    • 链表（为空）：list_head，用来存放已经就绪的FD。
  2. 创建好了之后，会去调用epoll_ctl函数，此函数会会将需要监听的数据添加到rb_root中去，并且对当前这些存在于红黑树的节点设置回调函数，当这些被监听的数据一旦准备完成，就会被调用，而调用的结果就是将红黑树的fd添加到list_head中去(但是此时并没有完成)。
  3. 当第二步完成后，就会调用epoll_wait函数，这个函数会去校验是否有数据准备完毕（因为数据一旦准备就绪，就会被回调函数添加到list_head中），在等待了一段时间后(可以进行配置)，如果等够了超时时间，则返回没有数据，如果有，则进一步判断当前是什么事件，如果是建立连接时间，则调用accept() 接受客户端socket，拿到建立连接的socket，然后建立起来连接，如果是其他事件，则把数据进行写出。

redis 流程

  1. redis 单线程网络模型流程。

  1. redis 多线程网络模型流程。

redis 思考

  1. Redis到底是单线程还是多线程？
    • 如果仅仅聊Redis的核心业务部分（命令处理），答案是单线程
    • 如果是聊整个Redis，那么答案就是多线程
  2. 在Redis版本迭代过程中，在两个重要的时间节点上引入了多线程的支持：
    • Redis v4.0：引入多线程异步处理一些耗时较旧的任务，例如异步删除命令unlink。
    • Redis v6.0：在核心网络模型中引入多线程，进一步提高对于多核CPU的利用率。
  3. 因此，对于Redis的核心网络模型，在Redis 6.0之前确实都是单线程。是利用epoll（Linux系统）这样的IO多路复用技术在事件循环中不断处理客户端情况。
  4. 为什么Redis要选择单线程？
    • 抛开持久化不谈，Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，因此多线程并不会带来巨大的性能提升。
    • 多线程会导致过多的上下文切换，带来不必要的开销。
    • 引入多线程会面临线程安全问题，必然要引入线程锁这样的安全手段，实现复杂度增高，而且性能也会大打折扣。