aio,epoll,libevent,boost::asio解决的问题

这几天一直在做linux大批量数据的解决方案,不断的深入了解了一下aio,epoll,libevent,boost::asio。以前只知道他们都是做异步/非阻塞的,但是具体解决的问题的关键点是什么,通过这几天的深入了解,把他们总结一下:
aio是linux2.6以后内核实现的异步IO,或者说他才是真正意义上的异步IO。
epoll作为select的linux的替代品,解决了selectfd_set的限制。性能优于select。而在max平台上替代方案是kqueue。
libevent是一个跨平台异步解决方案,他根据不同的平台提供了不同的异步方案,采用Reactor模型实现。
Boost::asio是一个跨平台的网络及底层IO的C++ 编程 库,实现了对TCP、UDP、ICMP、串口的支持。对于读写方式,ASIO支持同步和异步两种方式。采用了epoll来实现,插入了大量的信号处理。Asio库不需要单独便于,但是测试过程中对boost::system的依赖可能会需要编译部分boost中的库。
muduo采用Reactor模型实现的网络库,只支持 Linux  2.6.x下的并发非阻塞TCP网络编程,不跨平台,不支持udp和ipv6。吞吐量方面muduo比libevent2快18%,在事件处理效率方面,muduo与libevent2总体比较接近,muduo吞吐量比boost.asio高15%以上。性能方面作为解决大数据吞吐量很有优势,但是对平台和网络协议支持方面是一个问题。
ACE也是很经典的网络库,出自《C++网络编程》作者之手,设计精妙程度堪称一流,支持协议范围也很广,但是使用复杂度和学习复杂度较高,一直有“学我者生,用我者死”的评价。

需要注意的是他们的定位不同,aio和epoll主要是对异步提供解决方案不是网络库不提供网络支持,而libevent也是主要解决IO的问题只提供简单的http支持,asio和muduo还有ACE一样是高性能网络库。


开源C/C++网络库:
ACE          C++语言 跨平台
Boost的ASIO  C++语言 跨平台
libevent     C语言   主要支持linux,新版增加了对windows的IOCP的支持
libev        C语言   只支持linux,只封装了EPOLL模型


层次架构:
ACE:底层是OS适配层,上一层C++的wrap类,再上一层框架(Accpetor,Connector,Reactor,Proactor等),再上一层框架上的服务。
Boost的ASIO:底层是OS适配层,上一层一些模板类,再上一层模板类的参数化(TCP/UDP),再上一层是服务,它只有一种框架io_service。
libevent :libevent在不同OS下,做了多路复用模型的抽象,可以选择不同的模型,通过事件函数提供服务。


涉及范围:
ACE:ACE包含了日志,IPC,线程池,共享内存,配置服务,递归锁,定时器等。
Boost的ASIO:ASIO只涉及到Socket,提供简单的线程操作。
libevent :libevent只提供了简单的网络API的封装, 线程池, 内存池, 递归锁等均需要自己实现。


开发难度:
ACE:ACE难度较大,必须了解其框架
Boost的ASIO:难度适中要求熟悉boost库中的boost::bind,内存管理等
libevent :相对容易

发布方式:
ACE:ACE不依赖第3方库,以DLL方式提供
Boost的ASIO:依赖Boost,使用时只要include头文件,不需要动态库
libevent :一遍编译为静态库使用


线程调用:
ACE:ACE Reactor是单线程调度,Proactor支持多线程调度。
Boost的ASIO:支持单线程和多线程调度。
libevent :线程调度需要自己来注册不同的时间句柄。


事件分派处理:
ACE:ACE注册handler类,事件分派时,调用其handler的虚挂钩函数,实现ACE_Handler/ACE_Svc_Handler/ACE_Event_handler等类的虚函数。
Boost的ASIO:基于函数对象的hanlder事件分派。任何函数都有可能成为hanlder,少了一堆虚表的维护,调度优于ACE。
libevent :基于注册的事件回调函数来实现事件分发


设计模式:
ACE:ACE 主要应用了Reactor("信号驱动IO"),Proactor(异步IO)
Boost的ASIO:Proactor
libevent :Reactor


http://wanglimin2004.blog.163.com/blog/static/115488498201271611723476/


ZeroMQ:

普通socket是端到端,ZeroMQ却可以N:M的关系
3中通讯模式:
  请求回应模型,请求段发起请求,等待回应端回应请求。 请求端与回应端是1:N的,可以扩展成N:M的。
  发布订阅模型,发布端单向发送数据,不关心信息是否都发送给了订阅端。订阅端只负责接收,不反馈。若交互,需要额外的socket采用请求回应模型实现。
  管道模型,管道是单向的,从PUSH端单向的向PULL端单向的推送数据流。

你可能感兴趣的:(服务器开发)