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端单向的推送数据流。