《易筋经》。天下武功出少林，而易筋经是少林寺的镇寺之宝。学好了易筋经就可以轻易地学好其它武功，只不过很少人学到了它的全部精髓。游坦之只是碰巧学了一点点就变成了武林高手，从中可以看出易筋经的威力的确很大。
之前以及写过三篇NIO文章，NIO相关基础篇一、NIO相关基础篇二、NIO相关基础篇三，今天我们来提下NIO中的易筋经Reactor模型。
说明不会说故事的程序员不是好厨子，下面就来听听故事吧。
故事改编与网络。
以A地公众号：匠心零度菜馆为例，以客人就餐为例。
我们服务对象以桌（一桌>=1）为最小单位
公众号：匠心零度菜馆刚刚成立，客人还不是特别多的时候。
来一桌客人就餐，一个服务员去服务，然后客人会看菜单，点菜。 服务员将菜单给后厨。
来二桌客人就餐，二个服务员去服务……
……
来五桌客人就餐，五个服务员去服务……
公众号：匠心零度菜馆越来越忙，人越来越多，零度老板开始着急了：
缺乏弹性伸缩能力，当顾客越来越多，并行增加之后，服务员与顾客人数关系1:1关系。
现在人员太贵，再请人就攒不到钱了，当顾客到达一定之后零度就承担不了聘用那么的工作人员了，要不然公众号：匠心零度菜馆会垮掉了。
零度思来想去：
算了下成本，零度决定只聘用十个服务员。
这样当顾客越来越多，并行增加之后，服务员与顾客人数关系10:N(N大于等于10）关系。
这样公众号：匠心零度菜馆也不会因为聘用人员太多而承担不起。
那么又有什么问题呢？ 如果某桌客人点菜非常慢，导致有些桌客人会一直等很久，当体验不好的时候可能
有些桌的可以立马走了，有些桌的客人以后不来了。
虽然钱省下来了，但是也没有挣到，零度又开始想办法了，看看下面的故事二吧。
故事二：哈哈哈哈，零度之前是干编程的，知道很多事情需要拆拆拆（特别在中国要是拆房子，那不得了啊，发啦！！！）
上面的事情由于所有的事情都是一个服务器从头负责到尾，而有很多时候，顾客在交流讨论的时候，服务员其实
没啥事情干的，就在那里等着（能不能让等的时候去做其他事情呢，充分利用起来呢？？？）。
零度思来想去：
终于发现了一个新的方法，那就是：
当客人点菜的时候，服务员就可以去招呼其他客人了，等客人点好了菜，直接招呼一声"服务员"，
马上就有个服务员过去服务。之后零度进行了一次裁员，只留了一个服务员！
这样公众号：匠心零度菜馆生意越来越好，又出现了二个问题：
就算该服务员在怎么忙，也无法应对成百上千桌的客人了。
一个服务员如果请假或者有事情怎么办？（经常说服务不要出现单点，这样也一样啊！！！）
虽然钱省下来了，但是该挣的钱没有挣到，零度又开始想办法了，看看下面的故事三吧。
零度决定公众号：匠心零度菜馆再聘二名服务员，现在有三名服务员了，零度给他们划分是
一个负责填写各各桌的菜单，另外二名负责端菜（上菜的忙些），接下来的生意都很好，也忙的过来，请假了，另外二个相互配合下
临时处理也来得及，由于这样，生意越来越好，有一次被不三不四的人进来了，搞的公众号：匠心零度菜馆事情很大。
如果服务员还要检查人员，那么又忙不开了。
零度又开始思考了，看看下面的故事四吧。
零度聘了一个保安，需要检查下是否为不三不四人员，如果不是，把他交给服务员让服务员带入，之后服务员带入
继续由客人直接招呼一声"服务员"点菜好了，之后由其他服务员端菜……生意很好。
已经到了一个公众号：匠心零度菜馆忙不过来了 （到达上限了，那么要扩了，开分店……）
故事N:零度，反正以前干编程的，自己开发了一个app，客人过来之前就已经网上下单，零度专门找了一个人负责这块，当app有
新订单的时候会有声音提醒，那个负责人告诉后厨，这样当没有提醒的时候，该负责人可以去帮忙照顾店里的客人……
编不下去了…………
本文最重要的参考文献是Doug Lea大神的"Scalable IO in Java”，搜索公众号【匠心零度】或者扫描最下方二维码进行关注，回复：nio ，获取该资料，建议电脑下载，下文中的截图也是截取自中。
传统的BIO编程、伪异步I/O编程