并发模型与IO模型梳理

快来打我* 2023-08-17 17:01 77阅读 0赞

并发模型

常见的并发模型一般包括3类，基于线程与锁的内存共享模型，actor模型和CSP模型，其中尤以线程与锁的共享内存模型最为常见。由于go语言的兴起，CSP模型也越来越受关注。基于锁的共享内存模型与后两者的主要区别在于，到底是通过共享内存来通信，还是通过通信来实现访问共享内存。由于actor模型和CSP模型，本人并不是特别了解，我主要说说最基本的并发模型，基于线程与锁的内存共享模型。

为什么要并发，本质都是为了充分利用多核CPU资源，提高性能。但并发又不能乱，为了保证正确性，需要通过共享内存来协调并发，确保程序正确运转。无论是多进程并发，还是多线程并发，要么通过线程间互斥同步(spinlock，rwlock，mutex,condition,信号量)，要么通过进程间通信(共享内存，管道，信号量，套接字)，本质都是为了协同。多线程和多进程本质类似，尤其是linux环境下的pthread库，本质是用轻量级进程实现线程。下面以网络服务为例，简单讨论下多线程模型的演进。

最简单的模型是单进程单线程模型，来一个请求处理一个请求，这样效率很低，也无法充分利用系统资源。那么可以简单的引入多线程，其中抽出一个线程监听，每来一个请求就创建一个工作线程服务，多个请求多个线程，这就是多线程并发模型。这种模式下，资源利用率是上去了，但是却有很多浪费，线程数与请求数成正比，意味着频繁的创建/销毁线程开销，频繁的上下文切换开销，这些都是通过系统调用完成，需要应用态到内核态的切换，导致sys-cpu偏高，资源并没有充分利用在处理请求上。

为了缓解这个问题，引入线程池模型，简单来说，就是预先创建好一批线程，并且加大线程的复用能力，将线程数控制在一定数目内，缓解上下文切换开销。以MySQL线程池为例，原来多线程模型是单连接单线程，现在变成单语句单线程，提高了线程复用效率。如果线程在执行过程中遇到等待(锁等待，IO等待)，那么线程挂起，并减少活跃线程数，告知线程池系统活跃线程可能不够，需要追加线程，然后等系统空闲时，再减少线程数目，做到根据系统负载平衡线程数目。为了做到极致，更进一步减少上下文切换开销，引入了协程，协程只是一种用户态的轻量线程，它运行在用户空间，不受系统调度。它有自己的调度算法。在上下文切换的时候，协程在用户空间切换，而不是陷入内核做线程的切换，减少了开销。协程的并发，是单线程内控制权的轮转，相比抢占式调度，协程是主动让权，实现协作。协程的优势在于，相比回调的方式，写的异步代码可读性更强。缺点在于，因为是用户级线程，利用不了多核机器的并发执行。简单总结下：

单线程-->(单线程轮询处理，太慢)  
多线程-->(多线程会频繁地创建、销毁线程，这对系统也是个不小的开销。这个问题可以用线程池来解决。)  
线程池-->(仍然有多线程上下文切换的问题，调度由内核调度)  
协程-->(应用层调度，不touch内核)

I/O模型  
    linux中所有物理设备对于系统而言都可以抽象成文件，包括网卡，对应的就是套接字，磁盘对应的文件，以及管道等。因此所有对物理设备的读写操作都可以抽象为IO操作，典型的IO操作模型分为以下几类，阻塞IO，非阻塞IO，I/O多路复用，异步非阻塞IO以及异步IO等。

IO模型分类  
阻塞I/O--> 原生的read/write系统调用，默认导致线程阻塞；  
非阻塞I/O -->通过指定系统调用read/write的参数为非阻塞，告知内核fd没就绪时，不阻塞线程，而是返回一个错误码，应用死循环轮询，直到fd就绪；  
I/O多路复用-->(select/poll/epoll)，对通知事件堵塞，对于I/O调用不堵塞。  
异步I/O(异步非阻塞)-->告知内核某个操作(读写I/O)，并让内核在整个操作（包括将数据复制到我们的进程缓冲区）完成后通知。

I/O多路复用  
    常见的I/O多路复用主要用于网络IO场景，主要有select，poll和epoll机制。对比同步I/O，实际上是对I/O请求加了一层代理，由这些代理去监听通知事件(是否网络包到来)，然后再通知用户去读写数据。这种方式也是一种阻塞I/O，代理对通知事件阻塞，这里的代理一般指监听线程。对比select，poll提升了最大支持文件描述符数目，从1024提升到65535，MySQL中的半同步复制还因为使用select的这个限制，导致半同步中断的bug([链接][Link 1])。

对比select和poll机制，epoll通过事件表管理用户感兴趣的事件，无需反复传入用户感兴趣事件，处理事件通知的时间复杂度是O(1)，而select，poll机制的时间复杂度是O(N)。另外select/poll只能工作在LT模式(水平触发模式)；而epoll不仅支持LT模式，还支持ET模式(边缘触发模式)。两种模式的主要区别是，有数据可读时，LT模式会不停的通知，直到数据被获取，这种模式不用担心通知事件丢失；ET模式只会通知一次，因此对比LT少很多epoll系统调用，效率更高。epoll对编程要求高，需要细致的处理每个请求，否则容易发生丢失事件的情况。从本质上讲，与LT相比，ET模型是通过减少系统调用来达到提高并行效率的。

libev/libeasy  
      epoll很好用，但是要使用epoll，fd，signal，timer分别要采用不同的机制才能一起工作。libev第一个要做的事情就是把系统资源统一成一种调用方式。因为都需要在读写事件就绪后自己负责进行读写，也就是读写过程是阻塞的。libev的核心是事件处理框架，最常见的是就是一个所谓的Reactor事件处理框架和设计模式。Reactor对象负责实现主循环(其中有事件分离器的调用)，定义事件处理接口，用户程序向Reactor注册事件回调的实现类(从接口继承)，Reactor主循环在收到事件的时候调用相应的回调函数。libeasy实现类似libev和libevent的功能，包括HTTP服务器等，不同的是，它基于libev做了包装，提供了同一个的资源fd和loop机制，线程池，异步框架等实现。

AIO  
说到AIO，一般是说磁盘的异步I/O，linux早期的版本并没有真正的AIO接口，所谓的AIO其实是多线程模拟的，在应用态完成。具体而言就是有一个队列存储IO请求，通过一组工作线程提取任务，并发起同步IO，待IO完成后，再通知用户已经完成了。对于用户而言，由于是提交IO请求后就直接返回，然后再被通知IO已经完成，所以可以认为是异步I/O，这种异步I/O实现机制主要指POXIS AIO，MySQL的InnoDB引擎也实现了一套类似的AIO机制。后面linux内核引入了真正的AIO，主要区别在于发起I/O调用不再是同步调用，IO请求统一在内核层面排队，并且一次可以提交一批异步IO请求，然后通过轮询或者回调的方式接收完成通知即可。相比于POXIS AIO，底层有更多的IO并行，IO和CPU能充分并发，大大提升性能。在使用中，通过-lrt链接使用AIO库是POXIS接口，而通过-laio链接使用的AIO库是linux Native AIO接口。常用接口包括 io\_setup，io\_destroy，io\_submit，io\_cacel和io\_getevents等。

同步IO：  
优点：简单  
缺点：IO阻塞，无法充分利用IO和CPU资源，效率低

Native AIO：  
优点：AIO可以支持一次发送多个不连续的异步IO请求，性能更好(同步IO需要发送多次)  
缺陷：需要文件系统支持O\_DIRECT选项，如果不支持，io\_submit实际上是“退化”成同步操作。

POSIX AIO：  
优点：不依赖O\_DIRECT选项，有一定的合并能力(相邻地址的请求，可以做merge)。  
缺点：并发的IO请求受限于线程数目；另外就是，可能慢速磁盘，可能导致其它新的请求没有及时处理(工作线程数不够了)。

参考文档  
[https://cloud.tencent.com/developer/article/1349213][https_cloud.tencent.com_developer_article_1349213]  
[https://my.oschina.net/dclink/blog/287198][https_my.oschina.net_dclink_blog_287198]  
[https://www.cnblogs.com/lojunren/p/3856290.html][https_www.cnblogs.com_lojunren_p_3856290.html]  
[https://www.ibm.com/developerworks/cn/linux/l-async/][https_www.ibm.com_developerworks_cn_linux_l-async]

转载于:https://www.cnblogs.com/cchust/p/11366096.html

[Link 1]: https://www.cnblogs.com/cchust/p/5100067.html
[https_cloud.tencent.com_developer_article_1349213]: https://cloud.tencent.com/developer/article/1349213
[https_my.oschina.net_dclink_blog_287198]: https://my.oschina.net/dclink/blog/287198
[https_www.cnblogs.com_lojunren_p_3856290.html]: https://www.cnblogs.com/lojunren/p/3856290.html
[https_www.ibm.com_developerworks_cn_linux_l-async]: https://www.ibm.com/developerworks/cn/linux/l-async/