码迷,mamicode.com
首页 > 其他好文 > 详细

NIO中的易筋经

时间:2018-01-04 10:57:38      阅读:164      评论:0      收藏:0      [点我收藏+]

标签:相关   水平   点菜   重要   基础   阻塞   文献   程序   weixin   

匠心零度 转载请注明原创出处,谢谢!

前言

技术分享图片

《易筋经》。天下武功出少林,而易筋经是少林寺的镇寺之宝。学好了易筋经就可以轻易地学好其它武功,只不过很少人学到了它的全部精髓。游坦之只是碰巧学了一点点就变成了武林高手,从中可以看出易筋经的威力的确很大。

之前已经写过三篇NIO文章,NIO相关基础篇一NIO相关基础篇二NIO相关基础篇三,今天我们来提下NIO中的易筋经Reactor模型

说明

不会说故事的程序员不是好厨子,下面就来听听故事吧。

故事改编与网络。

以A地公众号:匠心零度菜馆为例,以客人就餐为例。
我们服务对象以桌(一桌>=1)为最小单位

故事一:

公众号:匠心零度菜馆刚刚成立,客人还不是特别多的时候。
来一桌客人就餐,一个服务员去服务,然后客人会看菜单,点菜。 服务员将菜单给后厨。
来二桌客人就餐,二个服务员去服务……
……
来五桌客人就餐,五个服务员去服务……

公众号:匠心零度菜馆越来越忙,人越来越多,零度老板开始着急了:
缺乏弹性伸缩能力,当顾客越来越多,并行增加之后,服务员与顾客人数关系1:1关系。
现在人员太贵,再请人就攒不到钱了,当顾客到达一定之后零度就承担不了聘用那么的工作人员了,要不然公众号:匠心零度菜馆会垮掉了。

零度思来想去:
算了下成本,零度决定只聘用十个服务员。
这样当顾客越来越多,并行增加之后,服务员与顾客人数关系10:N(N大于等于10)关系。
这样公众号:匠心零度菜馆也不会因为聘用人员太多而承担不起。

那么又有什么问题呢? 如果某桌客人点菜非常慢,导致有些桌客人会一直等很久,当体验不好的时候可能
有些桌的可以立马走了,有些桌的客人以后不来了。

虽然钱省下来了,但是也没有挣到,零度又开始想办法了,看看下面的故事二吧。

故事二:

哈哈哈哈,零度之前是干编程的,知道很多事情需要拆拆拆(特别在中国要是拆房子,那不得了啊,发啦!!!)
上面的事情由于所有的事情都是一个服务器从头负责到尾,而有很多时候,顾客在交流讨论的时候,服务员其实
没啥事情干的,就在那里等着(能不能让等的时候去做其他事情呢,充分利用起来呢???)。

零度思来想去:
终于发现了一个新的方法,那就是:
当客人点菜的时候,服务员就可以去招呼其他客人了,等客人点好了菜,直接招呼一声"服务员",
马上就有个服务员过去服务。之后零度进行了一次裁员,只留了一个服务员!
这样公众号:匠心零度菜馆生意越来越好,又出现了二个问题:
就算该服务员在怎么忙,也无法应对成百上千桌的客人了。
一个服务员如果请假或者有事情怎么办?(经常说服务不要出现单点,这样也一样啊!!!)
虽然钱省下来了,但是该挣的钱没有挣到,零度又开始想办法了,看看下面的故事三吧。

故事三:

零度决定公众号:匠心零度菜馆再聘二名服务员,现在有三名服务员了,零度给他们划分是
一个负责填写各各桌的菜单,另外二名负责端菜(上菜的忙些),接下来的生意都很好,也忙的过来,请假了,另外二个相互配合下
临时处理也来得及,由于这样,生意越来越好,有一次被不三不四的人进来了,搞的公众号:匠心零度菜馆事情很大。
如果服务员还要检查人员,那么又忙不开了。
零度又开始思考了,看看下面的故事四吧。

故事四:

零度聘了一个保安,需要检查下是否为不三不四人员,如果不是,把他交给服务员让服务员带入,之后服务员带入
继续由客人直接招呼一声"服务员"点菜好了,之后由其他服务员端菜……生意很好。

已经到了一个公众号:匠心零度菜馆忙不过来了 (到达上限了,那么要扩了,开分店……)

故事N:

零度,反正以前干编程的,自己开发了一个app,客人过来之前就已经网上下单,零度专门找了一个人负责这块,当app有
新订单的时候会有声音提醒,那个负责人告诉后厨,这样当没有提醒的时候,该负责人可以去帮忙照顾店里的客人……
编不下去了…………

Reactor模型介绍

本文最重要的参考文献是Doug Lea大神的"Scalable IO in Java”,搜索公众号【匠心零度】或者扫描最下方二维码进行关注,回复:nio ,获取该资料,建议电脑下载,下文中的截图也是截取自中。

传统的BIO编程、伪异步I/O编程

技术分享图片

BIO主要的问题在于每当有一个新的客户端请求接入时,服务端必须创建一个新的线程来处理这条链路,在需要满足高性能、高并发的场景是没法应用的(大量创建新的线程会严重影响服务器性能,使用线程池也是存在问题,如果发生大量并发请求,超过最大数量的线程就只能等待,会一直阻塞)

单线程模型

技术分享图片

单线程模型会存在如果链接太多,性能可能无法满足,而且如果nio线程出现意外啥的会影响这个系统不可用。

多线程模型

技术分享图片

多线程模型一般场景都满足了,但是在特别高的并发,以及一些非常消耗性能的验证等,会存在一些不足之处。

主从多线程模型

技术分享图片

主从多线程模型,通过mainReactor线程、subReactor线程继续拆分,mainReactor线程负责一些客户端TCP连接请求预处理(验证等),subReactor线程处理真正的IO。

参考:
http://daimojingdeyu.iteye.com/blog/828696

结束语

本人水平有限,难免会有一些理解偏差的地方,如果发现,欢迎各位积极指出,感谢!!!


如果读完觉得有收获的话,欢迎点赞、关注、加公众号【匠心零度】,查阅更多精彩历史!!!
技术分享图片

NIO中的易筋经

标签:相关   水平   点菜   重要   基础   阻塞   文献   程序   weixin   

原文地址:https://www.cnblogs.com/lirenzuo/p/8191064.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!