zoukankan      html  css  js  c++  java
  • NIO中的易筋经

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

    前言

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

    之前已经写过三篇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

    结束语

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


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

  • 相关阅读:
    撒谎
    可怜的猪
    GIS学习笔记(五)
    国产木马冰河2.2
    矛盾
    GIS学习笔记(六)
    男人如衣服
    VS2005快捷键大全
    慧悟
    DOS命令
  • 原文地址:https://www.cnblogs.com/jiangxinlingdu/p/8191064.html
Copyright © 2011-2022 走看看