刚做 IM 时，曾经有个疑惑，就是 IM 的长连接接入系统，到底单机接入多少长连接算合适的？很早时运维对于长连接有个报警指标是单机 1 万，但当时我用 Java NIO 开 2G 最大堆内存，在可接受的 GC 停顿下，在一台 4 核物理机上测试极限支撑 10 万长连接是可用的。那么平时保守点，使用测试容量的一半 5 万应该是可以的。
之后一次机会去拜访了当时阿里旺旺的后端负责人，我们也讨论到了这个长连接的数量问题。当时淘宝有 600 万卖家同时在线，另外大概还有 600 万买家实时在线。所以同时大概有 1200 万用户在线，而当时他们后端的接入服务器有 400 台，也就是每台保持 3 万连接。他说，这不是一个技术限制，而是业务限制。因为单机故障率高，一旦机器挂了，上面的所有用户会短暂掉线并重连。若一次性掉线用户数太多，恢复时间会加长，这会对淘宝的订单交易成交产生明显的影响。
他还说了一次事故，整个机房故障，导致单机房 600 万用户同时掉线。整个故障和自动切换恢复时间持续了数十分钟，在此期间淘宝交易额也同比下降了约 40% 左右。因为这种旺旺在线和交易的高度相关性，所以才限制了单机长连接的数量，而当时已经有百万级的单机长连接实验证明是可行的。
在微信春晚红包的那篇文章里提到：
在上海跟深圳两地建立了十八个接入集群，每个城市有三网的接入，总共部署了 638 台接入服务器，可以支持同时 14.6 亿的在线。
简单算一下，大概就是 228.8 万单机长连接的容量规划，14.6 亿怕是以当时全国人口作为预估上限了。实际当然没有那么多，但估计单机百万长连接左右应该是有的。这是一个相当不错的数量了，而采用 Java 技术栈要实现这个单机数量，恐怕也需要多进程，不然大堆的 GC 停顿就是一个不可接受和需要单独调优的工作了。
连结，便是这样一个针对同一个问题或场景，将你已知的部分连结上新的知识和实践，形成更大的网，再去探索更多的未知。
...
如何去吸收和消化信息，这是一个智者见智的事情，但在信息爆炸的时代都在忙于过滤和收集信息，却从不分配点时间去处理和提炼信息，也许你已经忘记了收集的初心了。
最后，是有关微信后台技术的一些参考文章， 有些在本文中引用了，有些没引用，但都值得一看。
参考与文后阅读[1] 张文瑞. 从0到1：微信后台系统的演进之路. 2016.01
[2] 张文瑞. 100亿次的挑战：如何实现一个“有把握”的春晚摇一摇系统. 2016.12
[3] 陈明. 微信朋友圈技术之道：三个人的后台团队与每日十亿的发布量. 2015.12
[4] 曾钦松. 万亿级调用系统：微信序列号生成器架构设计及演变. 2016.06
写点文字，画点画儿，记录成长瞬间。
微信公众号「瞬息之间」，既然遇见，不如一起成长。
posted @
相关文章
精彩导读
热门资讯
关注我们
