用户空间和内核态空间

进程的寻址空间划分成两部分：内核空间、用户空间

应用程序也好，还是内核空间也好，都是没有办法直接去物理内存的，而是通过分配一些虚拟内存映射到物理内存中，内核和应用程序去访问虚拟内存时，就需要一个虚拟地址，地址是一个无符号的整数

比如一个32位的操作系统，他的带宽就是32，他的虚拟地址就是2的32次方，也就是说他寻址的范围就是0~2的32次方， 这片寻址空间对应的就是2的32个字节，就是4GB，这个4GB，会有3个GB分给用户空间，会有1GB给内核系统

在linux中，他们权限分成两个等级，0和3，用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问内核空间可以执行特权命令（Ring0），调用一切系统资源，所以一般情况下，用户的操作是运行在用户空间，而内核运行的数据是在内核空间的，而有的情况下，一个应用程序需要去调用一些特权资源，去调用一些内核空间的操作，所以此时他俩需要在用户态和内核态之间进行切换。

比如，Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：

  • 写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备

  • 读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

针对这个操作：

用户在写读数据时，会去向内核态申请，想要读取内核的数据，而内核数据要去等待驱动程序从硬件上读取数据，当从磁盘上加载到数据之后，内核会将数据写入到内核的缓冲区中，然后再将数据拷贝到用户态的buffer中，然后再返回给应用程序，整体而言，速度慢，就是这个原因，为了加速，我们希望read也好，还是wait for data也最好都不要等待，或者时间尽量的短。

IO模型

阻塞IO

IO模型：

  • 阻塞IO（Blocking IO）
  • 非阻塞IO（Nonblocking IO）
  • IO多路复用（IO Multiplexing）
  • 信号驱动IO（Signal Driven IO）
  • 异步IO（Asynchronous IO）

如果是阻塞IO，那么整个过程中，用户从发起读请求开始，一直到读取到数据，都是一个阻塞状态。

  1. 应用程序想要去读取数据，是无法直接去读取磁盘数据的，需要先到内核里边去等待内核操作硬件拿到数据

  2. 等到内核从磁盘上把数据加载出来之后，再把这个数据写给用户的缓存区，

具体流程如图

用户去读取数据时，会去先发起recvform一个命令，去尝试从内核上加载数据，如果内核没有数据，那么用户就会等待，此时内核会去从硬件上读取数据，内核读取数据之后，会把数据拷贝到用户态，并且返回ok，整个过程，都是阻塞等待的，这就是阻塞IO

总结 ：阻塞IO就是两个阶段都必须阻塞等待：

阶段一：

  • 用户进程尝试读取数据（比如网卡数据）
  • 此时数据尚未到达，内核需要等待数据
  • 此时用户进程也处于阻塞状态

阶段二：

  • 数据到达并拷贝到内核缓冲区，代表已就绪
  • 将内核数据拷贝到用户缓冲区
  • 拷贝过程中，用户进程依然阻塞等待
  • 拷贝完成，用户进程解除阻塞，处理数据

非阻塞IO

非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程

阶段一：

  • 用户进程尝试读取数据（比如网卡数据）
  • 此时数据尚未到达，内核需要等待数据
  • 返回异常给用户进程
  • 用户进程拿到error后，再次尝试读取
  • 循环往复，直到数据就绪

阶段二：

  • 将内核数据拷贝到用户缓冲区
  • 拷贝过程中，用户进程依然阻塞等待
  • 拷贝完成，用户进程解除阻塞，处理数据
  • 非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

IO多路复用

FD

文件描述符（File Descriptor）：简称FD，是一个从0 开始的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字（Socket）。

通过FD，我们的网络模型可以利用一个线程监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

IO多路复用是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。不过监听FD的方式、通知的方式又有多种实现，常见的有：

  • select
  • poll
  • epoll

其中select和poll相当于是当被监听的数据准备好之后，会把你监听的FD整个数据都发给你，你需要到整个FD中去找，哪些是处理好的，需要通过遍历的方式，所以性能也并不是那么好；而epoll，则相当于内核准备好了之后，他会把准备好的数据，直接发给你，就省去了遍历的动作。

阶段一：

  • 用户进程调用select，指定要监听的FD集合
  • 核监听FD对应的多个socket
  • 任意一个或多个socket数据就绪则返回readable
  • 此过程中用户进程阻塞

阶段二：

  • 用户进程找到就绪的socket
  • 依次调用recvfrom读取数据
  • 内核将数据拷贝到用户空间
  • 用户进程处理数据

当用户去读取数据的时候，不再去直接调用recvfrom了，而是调用select的函数，select函数会将需要监听的数据交给内核，由内核去检查这些数据是否就绪了，如果说这个数据就绪了，就会通知应用程序数据就绪，然后来读取数据，再从内核中把数据拷贝给用户态，完成数据处理，如果N多个FD一个都没处理完，此时就进行等待。

总结

select模式存在的三个问题

  • 能监听的FD最大不超过1024
  • 每次select都需要把所有要监听的FD都拷贝到内核空间
  • 每次都要遍历所有FD来判断就绪状态

poll模式的问题

  • poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降

epoll模式中如何解决这些问题的

  • 基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高
  • 每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epol_wait无需传递任何参数，无需重复拷贝FD到内核空间
  • 利用ep_poll_callback机制来监听FD状态，无需遍历所有FD，因此性能不会随监听的FD数量增多而下降

信号驱动IO

信号驱动IO是与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待。

阶段一：

  • 用户进程调用sigaction，注册信号处理函数
  • 内核返回成功，开始监听FD
  • 用户进程不阻塞等待，可以执行其它业务
  • 当内核数据就绪后，回调用户进程的SIGIO处理函数

阶段二：

  • 收到SIGIO回调信号
  • 调用recvfrom，读取
  • 内核将数据拷贝到用户空间
  • 用户进程处理数据

当有大量IO操作时，信号较多，SIGIO处理函数不能及时处理可能导致信号队列溢出，而且内核空间与用户空间的频繁信号交互性能也较低。

异步IO

这种方式，不仅仅是用户态在试图读取数据后，不阻塞，而且当内核的数据准备完成后，也不会阻塞

他会由内核将所有数据处理完成后，由内核将数据写入到用户态中，然后才算完成，所以性能极高，不会有任何阻塞，全部都由内核完成，可以看到，异步IO模型中，用户进程在两个阶段都是非阻塞状态。

总结

Redis是单线程的吗？为什么使用单线程

Redis到底是单线程还是多线程？

  • 如果仅仅聊Redis的核心业务部分（命令处理），答案是单线程
  • 如果是聊整个Redis，那么答案就是多线程

在Redis版本迭代过程中，在两个重要的时间节点上引入了多线程的支持：

  • Redis v4.0：引入多线程异步处理一些耗时较旧的任务，例如异步删除命令unlink
  • Redis v6.0：在核心网络模型中引入 多线程，进一步提高对于多核CPU的利用率

因此，对于Redis的核心网络模型，在Redis 6.0之前确实都是单线程。是利用epoll（Linux系统）这样的IO多路复用技术在事件循环中不断处理客户端情况。

为什么Redis要选择单线程？

  • 抛开持久化不谈，Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，因此多线程并不会带来巨大的性能提升。
  • 多线程会导致过多的上下文切换，带来不必要的开销
  • 引入多线程会面临线程安全问题，必然要引入线程锁这样的安全手段，实现复杂度增高，而且性能也会大打折扣

Redis的单线程模型-Redis单线程和多线程网络模型变更

当客户端想要去连接服务器，会去先到IO多路复用模型去进行排队，会有一个连接应答处理器，他会去接受读请求，然后又把读请求注册到具体模型中去，此时这些建立起来的连接

如果是客户端请求处理器去进行执行命令时，他会去把数据读取出来，然后把数据放入到client中， client去解析当前的命令转化为redis认识的命令，接下来就开始处理这些命令，从redis中的command中找到这些命令，然后就真正的去操作对应的数据，当数据操作完成后，会去找到命令回复处理器，再由他将数据写出。