何以解我那心中对长连接的惧?

      与高人沟通,是最好的成长,解我那心中对长连接的惧!

       一直以来,我对长连接都是怀着深深地恐惧。因为在我的印象中,如果每个用户都保持长连接,那么,假设有稀稀松松有几个用户来到你的服务面前,那么你的并发瞬间就飚高了,那么你的服务能力一下就下去了。所以,我害怕,害怕啥事没干,服务就被干垮了!

      长连接与短连接的概念:前者是整个通讯过程,客户端和服务端只用一个Socket对象,长期保持Socket的连接;后者是每次请求,都新建一个Socket,处理完一个请求就直接关闭掉Socket。所以,其实区分长短连接就是:整个客户和服务端的通讯过程是利用一个Socket还是多个Socket进行的。

       长连接的好处:最大的好处就是让服务器知道客户端在哪里(个人感觉),可以随时向客户端发送消息。最大二好处是,省去了每次建立连接时的性能破费,c/s互发消息,直接复用原来建立的连接即可,无需再进行三次握手啥的。坏处自然也明显,也就是我一直以来担心的,能力下降得厉害,(当然还得看业务场景)。因为我做的业务都是,请求应答型的业务,所以,针对这种场景,并发数取决于实时请求的人数。此时,如果使用长连接,就会导致很多无用的客户端也被当作了并发的来源了,所以服务能力一下子就下来了。最终的结果就是,没几个业务就把自己干死了,所以我是真虚啊。

       短连接就比较方便了,需要我就请求,不需要就关闭,用完就走。缺点就是,每次请求时,需要耗费力气去重新建立连接,然后才能与服务端通信。所以,短连接的单个操作性能是很差的。(遇到连续n个请求发出时,负担就比较可观了,当然还是有其他解决办法的,如设置较短的超时关闭时间)

      那么,回到我的担心:如果都用长连接,后备服务器得准备多少啊?比如,我有100w的uv。往最坏了打算,有多少uv就保持多少连接,咱们来算算。为了保持100w的连接,咱们单机自然是做不了,所以就要测算单机的最大连接数能保持多少,假设单机服务能力为最大保持2000连接(这个值不大,也不小),那么,为了保持100w的能力,咱们就必须至少要有500台服务器存在,这是在完全没有任何灾备,满打满算得到的,否则的话就得更多了。服务器台数嘛说多也不多,还行吧,咱们先说到这里。

      咱们再来假设一个不合宜的场景,咱们100w的uv,买了那么多的服务器,假设咱们的pv是200w,也就是每个客户端就访问了2次服务端。200w/24h/3600s=2.314814814814815。即咱们的平均并发数为2.32,看到了吧,这是什么概念,我们同时就2-3个人访问了有用的东西,为此我们却付出了惨重的代价。当然,这也是我以前的算盘,这导致了我对长连接的恐惧。

       然而,算盘是不该这么打的。如果真这么干的话,老板绝对第一个把你干掉。当然,你还有有个挽回的办法,就是去把你的用户都激活了,求求你们,一直操作吧,这样我们的服务器就不会浪费了。嘿嘿,想得美。

       所谓的长连接,其实也只是相对的,即你有活动时,保持真正的长连接,如果很长时间你都没有真实操作了,那么,仍然把你的连接给你断掉,这样压力不就下来了嘛。再回头看一下刚才那个场景,每个ip就访问了2次有效数据,那么过一会我就把你连接给你断掉,到最后,都把连接关完了,咱们又满血复活了,100w的能力回来了。

      我靠,不会吧,这么牛逼的招数,你想过后果没?后续你服务端怎么给客户端发消息?是的,这是个难题。但是,解决方案总是有的。那就是找个替代者嘛你的连接断开了,就另外去找一个保持了连接的点嘛,让他来代替你找到客户端,把消息发过去就ok了。看起来很完美!那么问题来了,怎么样去找到这样的一个点呢?这个,确实有点难,各个设备的找寻方式是不一样的,比如苹果手机,那么这个点就是苹果的总服务器,如果是华为手机,那么就变成了华为的总服务器了,而pc呢,这个我也不知道了,求你告诉我,哈哈!当客户端收到这个消息后,再次主动建立一个通道连接,然后又开始愉快的沟通生活了,如此反复。

      那么,通过以上方式,咱们就解决了长连接带来的问题,是不是很happy啊。

      在业务量很大的时候,其实咱们就不应该考虑成本问题了,比如你想做及时通讯,却又不愿付长连接一字带来的成本,那就麻烦了(当然了,有厂商愿意给你做,只要你有钱)。再比如你的业务量很大,但是你却不愿意付出很多的存储服务器来存放用户的各种行为数据,或者其他流水数据,老是想着怎样省这一毛两毛的存储费用。这活咱就别干了,越到后面,数据就越是宝贵的资源,所以,有用的数据你就存吧,别整那些没用的。宽带不够,咱们用户量够大,咱们就加吧,这种好事咱别求!

posted @ 2018-07-14 09:05 等你归去来 阅读(...) 评论(...) 编辑 收藏