Redis7 epoll和I/O多路复用

1、多路复用要解决的问题

并发多客户端连接，在多路复用之前最简单和典型的方案：同步阻塞网络IO模型
这种模式的特点就是用一个进程来处理一个网络连接(一个用户请求)，比如一段典型的示例代码如下。
直接调用 recv 函数从一个 socket 上读取数据。
int main()
{
 ...
 recv(sock, ...) //从用户角度来看非常简单，一个recv一用，要接收的数据就到我们手里了。
}

我们来总结一下这种方式：
优点就是这种方式非常容易让人理解，写起代码来非常的自然，符合人的直线型思维。
缺点就是性能差，每个用户请求到来都得占用一个进程来处理，来一个请求就要分配一个进程跟进处理，
类似一个学生配一个老师，一位患者配一个医生，可能吗？进程是一个很笨重的东西。一台服务器上创建不了多少个进程。

进程在 Linux 上是一个开销不小的家伙，先不说创建，光是上下文切换一次就得几个微秒。
所以为了高效地对海量用户提供服务，必须要让一个进程能同时处理很多个 tcp 连接才行。
现在假设一个进程保持了 10000 条连接，那么如何发现哪条连接上有数据可读了、哪条连接可写了 ？

我们当然可以采用循环遍历的方式来发现 IO 事件，但这种方式太低级了。
我们希望有一种更高效的机制，在很多连接中的某条上有 IO 事件发生的时候直接快速把它找出来。
其实这个事情 Linux 操作系统已经替我们都做好了，它就是我们所熟知的 IO 多路复用机制。
这里的复用指的就是对进程的复用

2、I/O多路复用模型

2.1、是什么

I/O：
网络I/O

多路：
多个客户端连接(连接就是套接字描述符，即socket或者channel)，指的是多条TCP连接

复用：
用一个进程来处理多条的连接，使用单进程就能实现同时处理多个客户端的连接

一句话：
实现了用一个进程来处理大量的用户连接
IO多路复用类似一个规范和接口，落地实现，可以分为select-->poll-->epoll三个阶段来描述

2.2、redis如何处理客户端连接

Redis的IO多路复用
Redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，一次放到文件事件分派器，事件分派器将事件分发给事件处理器。

Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，
所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，
而 I/O 多路复用就是为了解决这个问题而出现
 
所谓 I/O 多路复用机制，就是说通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或写就绪），能够通知程序进行相应的读写操作。
这种机制的使用需要 select 、 poll 、 epoll 来配合。多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。
当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。
 
Redis 服务采用 Reactor 的方式来实现文件事件处理器（每一个网络连接其实都对应一个文件描述符） 
Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分：
多个套接字、
IO多路复用程序、
文件事件分派器、
事件处理器。
因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型

2.3、redis设计与实现

2.4、举个栗子

上午开会，错过了公司食堂的饭点， 中午就和公司的首席架构师一起去楼下的米线店去吃米线。我们到了一看，果然很多人在排队。
架构师马上发话了：嚯，请求排队啊！你看这位收银点菜的，像不像nginx的反向代理？只收请求，不处理，把请求都发给后厨去处理。
我们交了钱，拿着号离开了点餐收银台，找了个座位坐下等餐。
架构师：你看，这就是异步处理，我们下了单就可以离开等待，米线做好了会通过小喇叭“回调”我们去取餐；
如果同步处理，我们就得在收银台站着等餐，后面的请求无法处理，客户等不及肯定会离开了。

接下里架构师盯着手中的纸质号牌。
架构师：你看，这个纸质号牌在后厨“服务器”那里也有，这不就是表示会话的ID吗？
有了它就可以把大家给区分开，就不会把我的排骨米线送给别人了。过了一会， 排队的人越来越多，已经有人表示不满了，可是收银员已经满头大汗，忙到极致了。

架构师：你看他这个系统缺乏弹性扩容， 现在这么多人，应该增加收银台，可以没有其他收银设备，老板再着急也没用。
老板看到在收银这里帮不了忙，后厨的订单也累积得越来越多， 赶紧跑到后厨亲自去做米线去了。

架构师又发话了：幸亏这个系统的后台有并行处理能力，可以随意地增加资源来处理请求（做米线）。
我说：他就这点儿资源了，除了老板没人再会做米线了。
不知不觉，我们等了20分钟， 但是米线还没上来。
架构师：你看，系统的处理能力达到极限，超时了吧。
这时候收银台前排队的人已经不多了，但是还有很多人在等米线。

老板跑过来让这个打扫卫生的去收银，让收银小妹也到后厨帮忙。打扫卫生的做收银也磕磕绊绊的，没有原来的小妹灵活。
架构师：这就叫服务降级，为了保证米线的服务，把别的服务都给关闭了。
又过了20分钟，后厨的厨师叫道：237号， 您点的排骨米线没有排骨了，能换成番茄的吗？
架构师低声对我说：瞧瞧， 人太多， 系统异常了。然后他站了起来：不行，系统得进行补偿操作：退费。

说完，他拉着我，饿着肚子，头也不回地走了。

2.4.1、同步

调用者要一直等待调用结果的通知后才能进行后续的执行
现在就要，我可以等，等出结果为止

2.4.2、异步

被调用方先返回应答让调用者先回去，然后再计算调用结果，计算完最终结果后再通知并返回给调用方
异步调用要想获得结果一般通过回调

2.4.3、同步与异步的理解

同步、异步的讨论对象是被调用着(服务提供者)，重点在于获得调用结果的消息通知方式上

2.4.4、阻塞

调用方一直在等待而且别的事情什么都不做，当前进/线程会被挂起，啥也不干

2.4.5、非阻塞

调用在发出去后，调用方先去忙别的事情，不会阻塞当前进/线程。而会立即返回

2.4.6、阻塞与非阻塞的理解

阻塞、非阻塞的讨论对象是调用者(服务请求者)，重点在于等消息时候的行为，调用者是否能干其他事情

2.4.7、总结

4种组合方式
同步阻塞：
服务员说快到你了，先别离开我后台看一眼马上通知你，客户在海底捞火锅前台干等着，啥也不干

同步非阻塞
服务员说快到你了，先别离开，客户在海底捞火锅前台边刷抖音边等着叫号

异步阻塞
服务员说还要再等等，你先去逛逛，一会通知你，客户怕过号在海底捞火锅前台拿着排队小号啥也不干，一直等着店员通知

异步非阻塞
服务员说还要再等等，你先去逛逛，一会通知你，客户拿着排队小号+刷着抖音，等着店员通知