linux多线程服务端编程第六章-muduo网络库简介 读后感
linux 服务端 多线程 c++   发布于 2018-12-30   521人围观  0条评论
linux 服务端 多线程 c++   发表于 2018-12-30   521人围观  0条评论

前言

最近在读陈硕的moduo网络库的书,记录总结一些东西。

本章内容主要介绍muduo网络库的简单使用和muduo多线程模型,以及比较muduo网络库和其他一些网络库的性能。muduo网络库的使用在此不赘述,和大部分网络库使用差不多。本章内容中让我收获比较大的是,6.6节在详解muduo多线程模型时,比较了常见的并发网络服务程序设计方案。读完这章的我有一个巨大的疑问,就是到底应该如何有效的提高并发连接数?这个问题暂时还没想的太明白

常见的并发网络服务程序设计方案

陈硕在附录A中举了三大TCP网络编程案例:echo服务器、chat聊天/聊天室以及proxy代理服务器。

方案0 单线程 accpet + read/write 最最基本的模型 

方案1 accept + fork 即每个连接均以一个进程来处理 process-per-connection

方案2 accpet + thread 即每个连接均以一个线程来处理 thread-per-connection

方案3 pre  fork 

方案4 pre threaded

方案5 单线程reactor 即单线程poll然后read/write

方案6 (过渡方案)单线程reactor + thread-per-task 依旧是单线程poll,不同的是,每个请求(不是每个链接)创建一个线程

方案7 (过渡方案)单线程reactor + work thread 依旧是单线程poll,不同的是,每个连接创建一个线程,相同链接上的请求由同一个计算线程处理,以此保证同一个连接上请求结果的顺序性,而方案6无法保证这一点。该方案的问题在于,可能还不如直接用方案2了呢。因为该方案并发连接数限制于线程数目。

方案8 单线程reactor + thread-pool 基于方案6,构造线程池,Reactor线程处理IO,计算任务交个线程。每个请求分发给计算线程池处理。该方案的每个连接上的一长串请求有乱序返回的可能,所以需要依靠id来梳理响应

方案9 reactor in threads,即one loop per thread,一个main Reactor 负责accept(2)连接,然后将连接分发到其他线程的sub Reactor上。

方案10 reactor in process,nginx内置方案。和方案9大同小异

方案11 多reactors + thread-pool,基于方案8和方案9,构造多个Reacto负责IO,然后将请求方法到计算线程池中

上一篇: C++版本的基于FFMPEG的Helloworld程序

下一篇: linux多线程服务端编程第五章-高效的多线程日志 读后感

立即登录,发表评论
没有帐号?立即注册
0 条评论