开发笔记:SocketServer的N种并发模型汇总

篇首语：本文由编程笔记#小编为大家整理，主要介绍了Socket Server的N种并发模型汇总相关的知识，希望对你有一定的参考价值。

    在了解并发模型之前，我们需要两个必备的前置知识：

• socket网络编程




• 多路IO复用机制




• 多线程/多进程等并发编程理论

• socket编程流程清晰且简单，适合学习使用，了解socket基本编程流程。

• 该模型并非并发模型，是串行的服务器，同一时刻，监听并响应最大的网络请求量为1。即并发量为1。




• 仅适合学习基本socket编程，不适合任何服务器Server构建。

• 基于模型一：单线程Accept（无IO复用） 支持了并发的特性。




• 使用灵活，一个客户端对应一个线程单独处理，server处理业务内聚程度高，客户端无论如何写，服务端均会有一个线程做资源响应。

• 随着客户端的数量增多，需要开辟的线程也增加，客户端与server线程数量1:1正比关系，一次对于高并发场景，线程数量受到硬件上限瓶颈。




• 对于长链接，客户端一旦无业务读写，只要不关闭，server的对应线程依然需要保持连接(心跳、健康监测等机制)，占用连接资源和线程开销资源浪费。




• 仅适合客户端数量不大，并且数量可控的场景使用。

• 单流程解决了可以同时监听多个客户端读写状态的模型，不需要1:1与客户端的线程数量关系。




• 多路I/O复用阻塞，非忙轮询状态，不浪费CPU资源， CPU利用率较高。

• 虽然可以监听多个客户端的读写状态，但是同一时间内，只能处理一个客户端的读写操作，实际上读写的业务并发为1。




• 多客户端访问Server，业务为串行执行，大量请求会有排队延迟现象，如图中⑤所示，当Client3占据main thread流程时，Client1,Client2流程卡在IO复用等待下次监听触发事件。

• 对于模型三, 将业务处理部分，通过工作池分离出来，减少多客户端访问Server，业务为串行执行，大量请求会有排队延迟时间。




• 实际上读写的业务并发为1，但是业务流程并发为worker pool线程数量，加快了业务处理并行效率。

• 读写依然为main thread单独处理，最高读写并行通道依然为1.




• 虽然多个worker线程处理业务，但是最后返回给客户端，依旧需要排队，因为出口还是main thread的Read + Write

• 将main thread的单流程读写，分散到多线程完成，这样增加了同一时刻的读写并行通道，并行通道数量N， N为线程池Thread数量。




• server同时监听的ConnFd套接字数量几乎成倍增大，之前的全部监控数量取决于main thread的多路I/O复用机制的最大限制(select 默认为1024， epoll默认与内存大小相关，约3~6w不等)，所以理论单点Server最高响应并发数量为N*(3~6W)(N为线程池Thread数量，建议与CPU核心成比例1:1)。




• 如果良好的线程池数量和CPU核心数适配，那么可以尝试CPU核心与Thread进行绑定，从而降低CPU的切换频率，提升每个Thread处理合理业务的效率，降低CPU切换成本开销。

• 虽然监听的并发数量提升，但是最高读写并行通道依然为N，而且多个身处同一个Thread的客户端，会出现读写延迟现象，实际上每个Thread的模型特征与模型三：单线程多路IO复用一致。

• 进程和线程的内存布局不同导致，main process(主进程)不再进行Accept操作，而是将Accept过程分散到各个子进程(process)中.




• 进程的特性，资源独立，所以main process如果Accept成功的fd，其他进程无法共享资源，所以需要各子进程自行Accept创建链接




• main process只是监听ListenFd状态，一旦触发读事件(有新连接请求). 通过一些IPC(进程间通信：如信号、共享内存、管道)等, 让各自子进程Process竞争Accept完成链接建立，并各自监听。

• 在模型五、单线程IO复用+多线程IO复用(链接线程池)基础上，除了能够保证同时响应的最高并发数，又能解决读写并行通道局限的问题。




• 同一时刻的读写并行通道，达到最大化极限，一个客户端可以对应一个单独执行流程处理读写业务，读写并行通道与客户端数量1:1关系。

• 该模型过于理想化，因为要求CPU核心数量足够大。




• 如果硬件CPU数量可数(目前的硬件情况)，那么该模型将造成大量的CPU切换成本浪费。因为为了保证读写并行通道与客户端1:1的关系，那么Server需要开辟的Thread数量就与客户端一致，那么线程池中做多路I/O复用的监听线程池绑定CPU数量将变得毫无意义。




• 如果每个临时的读写Thread都能够绑定一个单独的CPU，那么此模型将是最优模型。但是目前CPU的数量无法与客户端的数量达到一个量级，目前甚至差的不是几个量级的事。