最近沉迷Redis网络模型，无法自拔！终于知道Redis为啥

　　1。用户空间和内核态空间1。1为什么要区分用户和内核
　　服务器大多都采用Linux系统，这里我们以Linux为例来讲解：
　　ubuntu和Centos都是Linux的发行版，发行版可以看成对linux包了一层壳，任何Linux发行版，其系统内核都是Linux。我们的应用都需要通过Linux内核与硬件交互
　　用户的应用，比如redis，mysql等其实是没有办法去执行访问我们操作系统的硬件的，所以我们可以通过发行版的这个壳子去访问内核，再通过内核去访问计算机硬件
　　计算机硬件包括，如cpu，内存，网卡等等，内核（通过寻址空间）可以操作硬件的，但是内核需要不同设备的驱动，有了这些驱动之后，内核就可以去对计算机硬件去进行内存管理，文件系统的管理，进程的管理等等
　　我们想要用户的应用来访问，计算机就必须要通过对外暴露的一些接口，才能访问到，从而简介的实现对内核的操控，但是内核本身上来说也是一个应用，所以他本身也需要一些内存，cpu等设备资源，用户应用本身也在消耗这些资源，如果不加任何限制，用户去操作随意的去操作我们的资源，就有可能导致一些冲突，甚至有可能导致我们的系统出现无法运行的问题，因此我们需要把用户和内核隔离开1。2进程寻址空间
　　进程的寻址空间划分成两部分：内核空间、用户空间
　　什么是寻址空间呢？我们的应用程序也好，还是内核空间也好，都是没有办法直接去物理内存的，而是通过分配一些虚拟内存映射到物理内存中，我们的内核和应用程序去访问虚拟内存的时候，就需要一个虚拟地址，这个地址是一个无符号的整数。
　　比如一个32位的操作系统，他的带宽就是32，他的虚拟地址就是2的32次方，也就是说他寻址的范围就是02的32次方，这片寻址空间对应的就是2的32个字节，就是4GB，这个4GB，会有3个GB分给用户空间，会有1GB给内核系统
　　在linux中，他们权限分成两个等级，0和3，用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问内核空间可以执行特权命令（Ring0），调用一切系统资源，所以一般情况下，用户的操作是运行在用户空间，而内核运行的数据是在内核空间的，而有的情况下，一个应用程序需要去调用一些特权资源，去调用一些内核空间的操作，所以此时他俩需要在用户态和内核态之间进行切换。
　　比如：
　　Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区
　　针对这个操作：我们的用户在写读数据时，会去向内核态申请，想要读取内核的数据，而内核数据要去等待驱动程序从硬件上读取数据，当从磁盘上加载到数据之后，内核会将数据写入到内核的缓冲区中，然后再将数据拷贝到用户态的buffer中，然后再返回给应用程序，整体而言，速度慢，就是这个原因，为了加速，我们希望read也好，还是waitfordata也最好都不要等待，或者时间尽量的短。
　　2。网络模型2。1阻塞IO过程1：应用程序想要去读取数据，他是无法直接去读取磁盘数据的，他需要先到内核里边去等待内核操作硬件拿到数据，这个过程是需要等待的，等到内核从磁盘上把数据加载出来之后，再把这个数据写给用户的缓存区。过程2：如果是阻塞IO，那么整个过程中，用户从发起读请求开始，一直到读取到数据，都是一个阻塞状态。
　　用户去读取数据时，会去先发起recvform一个命令，去尝试从内核上加载数据，如果内核没有数据，那么用户就会等待，此时内核会去从硬件上读取数据，内核读取数据之后，会把数据拷贝到用户态，并且返回ok，整个过程，都是阻塞等待的，这就是阻塞IO
　　总结如下：
　　顾名思义，阻塞IO就是两个阶段都必须阻塞等待：
　　阶段一：用户进程尝试读取数据（比如网卡数据）此时数据尚未到达，内核需要等待数据此时用户进程也处于阻塞状态
　　阶段二：数据到达并拷贝到内核缓冲区，代表已就绪将内核数据拷贝到用户缓冲区拷贝过程中，用户进程依然阻塞等待拷贝完成，用户进程解除阻塞，处理数据
　　可以看到，阻塞IO模型中，用户进程在两个阶段都是阻塞状态。
　　2。2非阻塞IO
　　顾名思义，非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程
　　阶段一：用户进程尝试读取数据（比如网卡数据）此时数据尚未到达，内核需要等待数据返回异常给用户进程用户进程拿到error后，再次尝试读取循环往复，直到数据就绪
　　阶段二：将内核数据拷贝到用户缓冲区拷贝过程中，用户进程依然阻塞等待拷贝完成，用户进程解除阻塞，处理数据可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。
　　2。3信号驱动
　　信号驱动IO是与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待。
　　阶段一：用户进程调用sigaction，注册信号处理函数内核返回成功，开始监听FD用户进程不阻塞等待，可以执行其它业务当内核数据就绪后，回调用户进程的SIGIO处理函数
　　阶段二：收到SIGIO回调信号调用recvfrom，读取内核将数据拷贝到用户空间用户进程处理数据
　　当有大量IO操作时，信号较多，SIGIO处理函数不能及时处理可能导致信号队列溢出，而且内核空间与用户空间的频繁信号交互性能也较低。2。4异步IO
　　这种方式，不仅仅是用户态在试图读取数据后，不阻塞，而且当内核的数据准备完成后，也不会阻塞
　　他会由内核将所有数据处理完成后，由内核将数据写入到用户态中，然后才算完成，所以性能极高，不会有任何阻塞，全部都由内核完成，可以看到，异步IO模型中，用户进程在两个阶段都是非阻塞状态。
　　2。5IO多路复用场景引入
　　为了更好的理解IO，现在假设这样一种场景：一家餐厅A情况：这家餐厅中现在只有一位服务员，并且采用客户排队点餐的方式，就像这样：
　　每排到一位客户要吃到饭，都要经过两个步骤：
　　思考要吃什么
　　顾客开始点餐，厨师开始炒菜
　　由于餐厅只有一位服务员，因此一次只能服务一位客户，并且还需要等待当前客户思考出结果，这浪费了后续排队的人非常多的时间，效率极低。这就是阻塞IO。
　　当然，为了缓解这种情况，老板完全可以多雇几个人，但这也会增加成本，而在极大客流量的情况下，仍然不会有很高的效率提升B情况：这家餐厅中现在只有一位服务员，并且采用客户排队点餐的方式。
　　每排到一位客户要吃到饭，都要经过两个步骤：思考要吃什么顾客开始点餐，厨师开始炒菜
　　与A情况不同的是，此时服务员会不断询问顾客：你想吃番茄鸡蛋盖浇饭吗？那滑蛋牛肉呢？那肉末茄子呢？
　　虽然服务员在不停的问，但是在网络中，这并不会增加数据的就绪速度，主要还是等顾客自己确定。所以，这并不会提高餐厅的效率，说不定还会招来更多差评。这就是非阻塞IO。C情况：这家餐厅中现在只有一位服务员，但是不再采用客户排队的方式，而是顾客自己获取菜单并点餐，点完后通知服务员，就像这样：
　　每排到一位客户要吃到饭，还是都要经过两个步骤：看着菜单，思考要吃什么通知服务员，我点好了
　　与AB不同的是，这种情况服务员不必再等待顾客思考吃什么，只需要在收到顾客通知后，去接收菜单就好。这样相当于餐厅在只有一个服务员的情况下，同时服务了多个人，而不像AB，同一时刻只能服务一个人。此时餐厅的效率自然就提高了很多。
　　映射到我们的网络服务中，就是这样：客人：客户端请求点餐内容：客户端发送的实际数据老板：操作系统人力成本：系统资源菜单：文件状态描述符。操作系统对于一个进程能够同时持有的文件状态描述符的个数是有限制的，在linux系统中ulimitn查看这个限制值，当然也是可以（并且应该）进行内核参数调整的。服务员：操作系统内核用于IO操作的线程（内核线程）厨师：应用程序线程（当然厨房就是应用程序进程咯）餐单传递方式：包括了阻塞式和非阻塞式两种。方法A：阻塞IO方法B：非阻塞IO方法C：多路复用IO2。6多路复用IO的实现
　　目前流程的多路复用IO实现主要包括四种：select、poll、epoll、kqueue。下表是他们的一些重要特性的比较：
　　IO模型
　　相对性能
　　关键思路
　　操作系统
　　JAVA支持情况
　　select
　　较高
　　Reactor
　　windowsLinux
　　支持，Reactor模式（反应器设计模式）。Linux操作系统的kernels2。4内核版本之前，默认使用select；而目前windows下对同步IO的支持，都是select模型
　　poll
　　较高
　　Reactor
　　Linux
　　Linux下的JAVANIO框架，Linuxkernels2。6内核版本之前使用poll进行支持。也是使用的Reactor模式
　　epoll
　　高
　　ReactorProactor
　　Linux
　　Linuxkernels2。6内核版本及以后使用epoll进行支持；Linuxkernels2。6内核版本之前使用poll进行支持；另外一定注意，由于Linux下没有Windows下的IOCP技术提供真正的异步IO支持，所以Linux下使用epoll模拟异步IO
　　kqueue
　　高
　　Proactor
　　Linux
　　目前JAVA的版本不支持
　　多路复用IO技术最适用的是高并发场景，所谓高并发是指1毫秒内至少同时有上千个连接请求准备好。其他情况下多路复用IO技术发挥不出来它的优势。另一方面，使用JAVANIO进行功能实现，相对于传统的Socket套接字实现要复杂一些，所以实际应用中，需要根据自己的业务需求进行技术选择。2。6。1select
　　select是Linux最早是由的IO多路复用技术：
　　linux中，一切皆文件，socket也不例外，我们把需要处理的数据封装成FD，然后在用户态时创建一个fdset的集合（这个集合的大小是要监听的那个FD的最大值1，但是大小整体是有限制的），这个集合的长度大小是有限制的，同时在这个集合中，标明出来我们要控制哪些数据。
　　其内部流程：
　　用户态下：创建fdset集合，包括要监听的读事件、写事件、异常事件的集合确定要监听的fdset集合将要监听的集合作为参数传入select（）函数中，select中会将集合复制到内核buffer中
　　内核态：内核线程在得到集合后，遍历该集合没数据就绪，就休眠当数据来时，线程被唤醒，然后再次遍历集合，标记就绪的fd然后将整个集合，复制回用户buffer中用户线程遍历集合，找到就绪的fd，再发起读请求。
　　不足之处：集合大小固定为1024，也就是说最多维持1024个socket，在海量数据下，不够用集合需要在用户buffer和内核buffer中反复复制，涉及到用户态和内核态的切换，非常影响性能2。6。2poll
　　poll模式对select模式做了简单改进，但性能提升不明显。
　　IO流程：创建pollfd数组，向其中添加关注的fd信息，数组大小自定义调用poll函数，将pollfd数组拷贝到内核空间，转链表存储，无上限内核遍历fd，判断是否就绪数据就绪或超时后，拷贝pollfd数组到用户空间，返回就绪fd数量n用户进程判断n是否大于0，大于0则遍历pollfd数组，找到就绪的fd
　　与select对比：select模式中的fdset大小固定为1024，而pollfd在内核中采用链表，理论上无上限，但实际上不能这么做，因为的监听FD越多，每次遍历消耗时间也越久，性能反而会下降
　　2。6。3epoll
　　epoll模式是对select和poll的改进，它提供了三个函数：eventpoll、epollctl、epollwaiteventpoll函数内部包含了两个东西：红黑树：用来记录所有的fd链表：记录已就绪的fdepollctl函数，将要监听的fd添加到红黑树上去，并且给每个fd绑定一个监听函数，当fd就绪时就会被触发，这个监听函数的操作就是将这个fd添加到链表中去。epollwait函数，就绪等待。一开始，用户态buffer中创建一个空的events数组，当就绪之后，我们的回调函数会把fd添加到链表中去，当函数被调用的时候，会去检查链表（当然这个过程需要参考配置的等待时间，可以等一定时间，也可以一直等），如果链表中没有有fd则fd会从红黑树被添加到链表中，此时再将链表中的的fd复制到用户态的空events中，并且返回对应的操作数量，用户态此时收到响应后，会从events中拿到已经准备好的数据，在调用读方法去拿数据。2。6。4总结：
　　select模式存在的三个问题：能监听的FD最大不超过1024每次select都需要把所有要监听的FD都拷贝到内核空间每次都要遍历所有FD来判断就绪状态
　　poll模式的问题：poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降
　　epoll模式中如何解决这些问题的？基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高每个FD只需要执行一次epollctl添加到红黑树，以后每次epolwait无需传递任何参数，无需重复拷贝FD到内核空间利用eppollcallback机制来监听FD状态，无需遍历所有FD，因此性能不会随监听的FD数量增多而下降2。7基于epoll的服务器端流程
　　一张图搞定：
　　我们来梳理一下这张图服务器启动以后，服务端会去调用epollcreate，创建一个epoll实例，epoll实例中包含两个数据红黑树（为空）：rbroot用来去记录需要被监听的FD链表（为空）：listhead，用来存放已经就绪的FD创建好了之后，会去调用epollctl函数，此函数会会将需要监听的fd添加到rbroot中去，并且对当前这些存在于红黑树的节点设置回调函数。当这些被监听的fd一旦准备就绪，与之相关联的回调函数就会被调用，而调用的结果就是将红黑树的fd添加到listhead中去（但是此时并没有完成）fd添加完成后，就会调用epollwait函数，这个函数会去校验是否有fd准备就绪（因为fd一旦准备就绪，就会被回调函数添加到listhead中），在等待了一段时间（可以进行配置）。如果等够了超时时间，则返回没有数据，如果有，则进一步判断当前是什么事件，如果是建立连接事件，则调用accept（）接受客户端socket，拿到建立连接的socket，然后建立起来连接，如果是其他事件，则把数据进行写出。2。8五种网络模型对比：
　　最后用一幅图，来说明他们之间的区别
　　3。redis通信协议3。1RESP协议
　　Redis是一个CS架构的软件，通信一般分两步（不包括pipeline和PubSub）：客户端（client）向服务端（server）发送一条命令，服务端解析并执行命令返回响应结果给客户端，因此客户端发送命令的格式、服务端响应结果的格式必须有一个规范，这个规范就是通信协议。
　　而在Redis中采用的是RESP（RedisSerializationProtocol）协议：Redis1。2版本引入了RESP协议Redis2。0版本中成为与Redis服务端通信的标准，称为RESP2Redis6。0版本中，从RESP2升级到了RESP3协议，增加了更多数据类型并且支持6。0的新特性客户端缓存
　　但目前，默认使用的依然是RESP2协议。在RESP中，通过首字节的字符来区分不同数据类型，常用的数据类型包括5种：单行字符串：首字节是‘’，后面跟上单行字符串，以CRLF（r）结尾。例如返回OK：OKr错误（Errors）：首字节是‘’，与单行字符串格式一样，只是字符串是异常信息，例如：Errormessager数值：首字节是‘：’，后面跟上数字格式的字符串，以CRLF结尾。例如：：10r多行字符串：首字节是‘’，表示二进制安全的字符串，最大支持512MB：如果大小为0，则代表空字符串：0rr如果大小为1，则代表不存在：1r数组：首字节是‘’，后面跟上数组元素个数，再跟上元素，元素数据类型不限：