本文为原创，转载请注明：http://www.cnblogs.com/gistao/
Background
网络术语里的阻塞和非阻塞，哪个模式相对好些？大多数都会选择非阻塞模式，不过技术向来都是矛盾的，这里分析和总结下。
Blocking
一般使用非阻塞来提高IO并发度（Linux的native aio只对文件有效，windows有完成端口）。但当IO并发度很低时，非阻塞模式不一定比阻塞模式更高效，因为后者完全由内核负责，而read/write这类系统调用已经高度优化，效率显然高于一般还得多个线程协作的非阻塞模式。比如Android里的很多http server，大部分只是维持几个连接，更别说并发IO了。
Non-blocking
但当IO并发度很提高时，阻塞函数会阻塞住一个线程，我们只能通过加大线程数量来应付，这样的弊端很明显：由于内核的线程调度遵循公平原则，所以内核会不停地切换线程，在一个cpu core(核)上可能只做了一点点事情，马上又换成了另一个线程，cpu cache没得到充分利用。
不过非阻塞模式一般由少量event-driven线程和一些运行用户逻辑的worker线程组成，这些线程往往会被复用。event-driven和worker可以同时在不同的核运行(流水线化)，内核不用频繁的切换就能完成有效的工作。线程总量也不用很多，这时候非阻塞IO就往往比阻塞IO快了。
Leader/Follower
event-driven和worker模式也有叫leader/follower模式的(leader和follower的角色不能互换)。不过leader/follower模式也有自己的问题，由于leader线程不受业务代码干扰，当IO并发度很高时，需要很大的数据内存和消息队列或者提供内存限制功能，反而会增加程序复杂性，同时leader线程和follower线程的每次协作几乎都造成了无谓的cache miss，性能必然也不算完美。
后来又有了leader/follower模式的变种：leader和follower角色可以切换。
Leader/Follower2
这种模式本质上就是为了去掉leader对follower的调度开销，leader获取事件后就直接进行下一步有效的操作，比如read。对于要求低延时的网络任务，比如rpc，影响相当的大，因为一个计算往往耗时也就纳秒级别，而线程调度开销却需要大几个量级的开销。同时leader变为follower后，直接承载业务逻辑，这样就可以避免前边提到的内存限制功能。当然这种模式逻辑也会更加复杂，比如leader同时获取多事件情况下的应对策略，多follower争抢leader的避免策略等。