首页 > 代码库 > 谈谈Boost网络编程(2)—— 新系统的设计

谈谈Boost网络编程(2)—— 新系统的设计

         写文章之前。我们一般会想要採用何种方式,是“开门见山”,还是”疑问式开头“。写代码也有些类似。在编码之前我们须要考虑系统总体方案,这也就是各种设计文档的作用。在设计新系统之初,我基本的目的是:保证高效率;保证高扩展性。

        效率评价以”任务数/秒“做单位。

因为我的系统仅仅是client,不应该占用太多内存以及CPU。所以内存占用率,CPU使用率也被作为一个硬性指标。那么这里就存在疑问的地方:client有必要採用Boost Asio来做吗?我个人认为这取决于client的规模。假设client须要做到高并发。那么应该採用异步IO方式来做;反之则不必。

        进一步。我们是怎样做到高效率?我们的设计大体流程例如以下:

技术分享

注意:这里的任务都是同一份实例。

       stream_server:负责接收任务。它实际上包含两部分:stream_server和stream_client。stream_server负责accept新连接。当连接到来时,它创建出stream_client。

这个被创建出的stream_client负责详细的任务解析。任务接收。

stream_client并不保存任务信息,它直接将正确的任务交由task_manager去进一步处理。

stream_server内部保存着各个client实例。这是为了方便以后对并发数的限制。

       task_manager实际上包含分发和检測任务超时两个功能。不管是何种功能,task_manager都不保存任务信息。分发时,task_manager将任务分配到相应的runner中去执行;检測超时。则调用各个runner提供的检測超时接口。

       runner是唯一真正持有任务实例的地方。从上面我们对stream_server和task_manager的描写叙述,这二者都不持有任务。我们希望通过这种设计,最大限度地实现0拷贝。runner的划分依据业务而来。比方:下载某个文件之后解压,那么我们可分创先出download_runner和decompress_runner:download_runner进行下载,decompress_runner进行解压。这样细分的优点是:假设decompress_runner失败了。那么能够再交由task_manager分发到download_runner进行重试。

换言之,runner能够得到重用。

       client是实际运行任务的模块。任务可能是完毕一次HTTP请求(长连接或是短连接由client依据任务来决定),也可能是调用一次shell脚本。为了保证任务的成功率以及原子性,client具有超时控制,以及自己主动重试的功能(重试次数由runner指定)。

       写到这里已经非常明显了,假设要做到多任务并发,或者採用多个client同一时候并发。或者採用多个runner同一时候执行任务。这里须要注意的是:runner是同步且被动的。

也就是:runner同一时刻仅仅能执行一个任务,且须要由task_manager主动给予任务。



谈谈Boost网络编程(2)—— 新系统的设计