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

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

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

      长连接与短连接的概念：前者是整个通讯过程，客户端和服务端只用一个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啊。

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