移动互联网长连接方案实例

 

1.笔者本人现在在一家创业公司担当整个平台架构的角色，而这家公司是做一移动互联网相关的一些应用产品，由其现在正在和中国最大的互联网公司之一进行合作，负责该互联网公司的手机终端的长连接推送服务，所以有一些总结特在此和大家分享一下。

2.下面这篇文章是笔者在几个月前做的一篇长连接的总结，所以可能写的不是非常严谨，特给javaer们进行一些参考即可，有如下几个数据和大家一起分享下：

    1) 单JVM实现了50W以上长连接，每秒消息处理“Hello Word”和心跳包6W次

    2）该长连接，不仅实现了手机终端的摸拟，而且该框架也是一个成熟的RPC框架，已经在笔者所在的公司使用。比阿里巴巴开源版本出来的"dubbo"性能要高，而且更节省带宽，大家可以测试比较一下。

    3）因为netty支持的长连接，每条连接占有用内存是5K，笔者经过包装之后每条连接占用5.3K， 每条长连接系统要占用8K；所以大家可以计算一下每条长连接一共要消耗的系统内存量。

    4）通过“3）”我们可以计算，50W长连接需要多少内存量（JVM）：500000*5.3K=2650000K=2.53G，50W长连接需要多少内存量（OS）：500000*8K=3.8G

          也就是说，50W长连接的话，大约需要总占用系统10G的内存空间（当然这是保守值，也希望大家多测试测试给出更多的一些数据）

3.好了，说了这么多，看看笔者的一些测试数据吧（笔者只是把几个月前的测试邮件内容发出，因为某些原因笔者不能发出现在公司正在使用的完全代码实现）

    1）如果要支持这么多的长连接，一定要修改一下系统的一些内核参数，如下：

 

vi /etc/sysctl.conf
 
 
net.ipv4.tcp_max_syn_backlog = 65536
 
net.core.netdev_max_backlog =  32768
 
net.core.somaxconn = 32768
 
 
net.core.wmem_default = 8388608
 
net.core.rmem_default = 8388608
 
net.core.rmem_max = 16777216
 
net.core.wmem_max = 16777216
 
 
net.ipv4.tcp_timestamps = 0
 
net.ipv4.tcp_synack_retries = 2
 
net.ipv4.tcp_syn_retries = 2
 
 
net.ipv4.tcp_tw_recycle = 1
 
#net.ipv4.tcp_tw_len = 1
 
net.ipv4.tcp_tw_reuse = 1
 
 
net.ipv4.tcp_mem = 94500000 915000000 927000000
 
net.ipv4.tcp_max_orphans = 3276800
 
 
#net.ipv4.tcp_fin_timeout = 30
 
#net.ipv4.tcp_keepalive_time = 120
 
net.ipv4.ip_local_port_range = 1024  65535
 
 
/sbin/sysctl -p
 
最后个命令是让配置生效的。
 
 
vi /etc/security/limits.conf
 
添加
 
*                -       nofile          1006154

 

    注：a.因为移动终端经常会因为网络问题断开，所以要修改内核参数支持连接断开后快速回收

            b.OS虽然默认TCP的缓冲内存已经足够大，但是因为系统要支持很多的长连接，所以缓冲内存还需要调整，要不然会发生丢包情况（这个也是笔者当时和58同城的资深VP聊天的时候了解并学习到的）

            c.文件句柄数要加大，因为OS默认支持的长连接数量比较小

 

    2）下面是测试的邮件正文

    写道

1. 有消息收发之间的间隔，比如说。Client --> Server端发消息。
如果Server端默认1分钟没有收到消息（包括心跳），则断开连接，可配间隔时间。
同理，如果Client端没有Server推过来的消息（包括心跳），则断开连接，可配间隔时间。

当然，如果没有消息，心跳包也是可以Client <--> Server互发的。如果没有消息，心跳就会互发，为了保证长连接不断。如果要是在接收方没有消息过来，则认为连接断了。之前设计这个的时候，就是考虑到了手机端的长连接的各种应用场景。

2. 每个登录用户没有用户session，不过有这个接口，可以每个连接可以添加一个attchment，可以跟据连接绑定信息。
测试的时候没有给attchment加信息。
其实真的不是为了代替他的方案，当时设计的时候就是为了RPC和手机服务端长连接设计的。
用户session信息比较占用内存，我是建议用户session信息放在堆外，这样不影响JVM。

3. 现在内存表现是用的CMS回收策略，所以没有出现full gc回收停顿的情况。但是因为netty的长连接本身就占了5K，而且我们这边又加了一些扩展信息，所以现在一个连接占了5.3K。

4. 为什么说现在超过50W了，是因为现在内存上限设成6G了，然后又进行了50W以上的长连接和每秒60000以上的消息发送（Hello Word）。
年轻代和老年代回收的时间都在0.4秒左右，所以对应用没有影响才敢说50W长连接了。
（注：年轻代回收，其实整个应用会停的，老年代的 full gc也是整个应用会停的；不过gc.log我看了，在0.4秒左右，所以没有影响应用）
（其实理论上还可以加内存，不过没有经过压力测试也没有时间弄了，没有测试机测试一回太累了，不过至少保证50W长连接没有啥问题）
（我估计也差不多了是上限了，应用内存回收已经占了0.4秒了，再加大如果回收时间占有的太长也不好）

5. 之前为什么说加到6G测试后，不行。是因为我发现jvm的年轻代不能开太大，好像年轻代开的太大会影响整个应用的停顿时间。所以这次是把年轻代保持不变，heap推放大到6G，所就是说多出来的2G空间给老年代了。而长连接正好在老年代保存，所以新加的2G给长连接正好把长连接推到了50W长连接。而且还有1G以上的空闲空间，而且老年代的full gc也控制在了0.4秒，我感觉比例正好。

 

 

下面是测试数据：

1.  同时在线人数 ： 508691

2. JVM 参数配置：

 

3.  资源使用情况：

 

 

5.  每秒消息数：60000msg/s

6. gc.log 信息如下：

 

ParNew ：是新生代的回收时间，会让整个应用停止，real 是真实的应用停止时间：0.4x

GC[YG occupancy] 这一段是老年代full gc ：会让整个应用停止，real 是真实时间，0.42

因为gc 新年代和老年代收回不频繁，所以对应用没有影响。内存我也其实也不想再加了，在60000 个消息并发和50W 心跳包的情况下能做到这个效果，我感觉不错了。

刚才问了手机QQ 的长连接，这前他们是15~20W 长连接一台，现在新的架构也就能做35~40W ，我感觉现在应该行了。

 

该长连接测试用例，笔者是用summercool-hsf开源框架(笔者的另一个开源的RPC框架)的基础上实现的。笔者正在用grizzly实现另一个手机终端长连接版本，因为grizzly更加节省内存，能支持更多的长连接数量，虽然性能可能不会达到netty，但是对不是高压力该问，但是对长连接数量有非常高要求的应用，grizzly还是非常适合的。笔者因为时间的关系，不再列出grizzly的详细测试数据，后面的章节会继续给出，请大家关注。

 

summercool-hsf框架地址（已经在某些公司的大型应用成熟使用1年时间） ：http://code.google.com/p/summercool-hsf/

 

 

 

 

 

 

 

 

 

 

 

评论

34 楼 nothing.whoami 2015-05-08  

dragonsoar 写道

本人本来不想多说啥，但是本人从某一家互联网公司出来后，发表这篇论文实际是为开源社区想做一些事，但是被前公司告知说以前公司某人不高兴。。。

这是为何？
1. 我的代码是他写的？我操，这可能吗？
2. 我的代码是他研究的方案？我操，这可能吗？
3. 以为我走了接了我的位置，我的成果就都成某人的了？我操，这可能吗？

做技术，不是靠说别人不行来证明自己行，这个世界是小人得势的世界，但是知道的人都心知肚明，我也承认我不是啥大度的人，我是看那些成天只吹牛逼的人得到领导的欢心上去。本来想删除此文，毕竟一家小公司也没有啥技术实力，我弄的这些东西也是给某家公司有一些积累。但是，说别人不开心的理由让我关闭此博客，我想来想去不太好。

1. 我删了证明我是真的拿原公司的产品或是方案了，我不怕上法庭，因为代码一比便知，这些资料和成果是上一家公司没有的
2. 我删了证明接我班的人的成果被某人占有，所以想来想去还是不删了

支持！

33 楼 mordecai 2014-10-11  

楼主不错，先慢慢看，研究一下

32 楼 dragonsoar 2013-09-06  

zhangzhijian 写道

呵呵。貌似像阿里人.....

这个和阿里的方案没有半毛钱关系了

31 楼 zhangzhijian 2013-09-04  

呵呵。貌似像阿里人.....

30 楼 dragonsoar 2013-07-02  

yunnysunny 写道

dragonsoar 写道

yunnysunny 写道

同志们，我建议吧楼主的代码弄到github上，不知大家感觉怎么样，来投票吧。

1. 放在githut上面是没有问题的，不过真的怕被封了而且速度说实在的也真的不快
2. 占用内存的问题是因为有内存缓冲区，所以速度快。大家可以看一下kryo序列化工具类的实现，里面有一个context缓冲

国内的开源软件大多数是放到了github上，现在已经很少看到有开源软件不在github上放了。github不可能被封掉，之前出现短暂的不能访问的情况，是技术原因还是政治原因未知，不过国内的反响很大。即使真的万一有这么一天，但是对于网站被封掉的问题，对于程序员来说问题不大。github使用git来做版本库，像这种版本库平时都是往本地提交，本地和远程库是可以相互独立的两个库，即使网上的被封掉了，也不会对你造成损失；但是svn就不同了。政府即使要封锁国外网站，首当其冲的也应该是google，现在放置在google code（跟google.com用相同的ip）上，不论是从代码安全性还是访问速度上都不如github。github在国内有几百万的用户，如果速度没保障，会严重影响他们的收入。
在这github的pull request机制就是为开源而生的，大家都可以提交代码供作者审核。
另外，svn库是可以无缝迁移到git上的，具体可以参考我的博文http://blog.csdn.net/yunnysunny/article/details/8072571

强大啊，这也研究啊，呵呵~

29 楼 yunnysunny 2013-06-29  

dragonsoar 写道

yunnysunny 写道

同志们，我建议吧楼主的代码弄到github上，不知大家感觉怎么样，来投票吧。

1. 放在githut上面是没有问题的，不过真的怕被封了而且速度说实在的也真的不快
2. 占用内存的问题是因为有内存缓冲区，所以速度快。大家可以看一下kryo序列化工具类的实现，里面有一个context缓冲

国内的开源软件大多数是放到了github上，现在已经很少看到有开源软件不在github上放了。github不可能被封掉，之前出现短暂的不能访问的情况，是技术原因还是政治原因未知，不过国内的反响很大。即使真的万一有这么一天，但是对于网站被封掉的问题，对于程序员来说问题不大。github使用git来做版本库，像这种版本库平时都是往本地提交，本地和远程库是可以相互独立的两个库，即使网上的被封掉了，也不会对你造成损失；但是svn就不同了。政府即使要封锁国外网站，首当其冲的也应该是google，现在放置在google code（跟google.com用相同的ip）上，不论是从代码安全性还是访问速度上都不如github。github在国内有几百万的用户，如果速度没保障，会严重影响他们的收入。
在这github的pull request机制就是为开源而生的，大家都可以提交代码供作者审核。
另外，svn库是可以无缝迁移到git上的，具体可以参考我的博文http://blog.csdn.net/yunnysunny/article/details/8072571

28 楼 dragonsoar 2013-06-28  

yunnysunny 写道

同志们，我建议吧楼主的代码弄到github上，不知大家感觉怎么样，来投票吧。

1. 放在githut上面是没有问题的，不过真的怕被封了而且速度说实在的也真的不快
2. 占用内存的问题是因为有内存缓冲区，所以速度快。大家可以看一下kryo序列化工具类的实现，里面有一个context缓冲

27 楼 yunnysunny 2013-06-13  

同志们，我建议吧楼主的代码弄到github上，不知大家感觉怎么样，来投票吧。

26 楼 yunnysunny 2013-06-13  

抛出一枚硬币 写道

博主的代码我下过来了，但是感觉内存占用很大，序列化这种方式传递的数据量占用的带宽会不会比json的多呢？

感觉数据量应该比json小，因为他用的是二进制进行序列化。

25 楼 抛出一枚硬币 2013-06-09  

博主的代码我下过来了，但是感觉内存占用很大，序列化这种方式传递的数据量占用的带宽会不会比json的多呢？

24 楼 dragonsoar 2013-01-21  

java_user 写道

强烈支持这些技术开源，对于小公司特别有用，不然自己再弄一边类似的功能代价太大了

嗯，可以加入群里面我们大家一起讨论讨论，呵

23 楼 java_user 2013-01-21  

强烈支持这些技术开源，对于小公司特别有用，不然自己再弄一边类似的功能代价太大了

22 楼 dragonsoar 2012-12-25  

k_june 写道

楼主，http://code.google.com/p/summercool-hsf/ 这个框架删掉了？

没有删掉，你不要去download里去去下，你要去source里面去下。只是我这边源代码提交不了了了，https上不去了，不知道为啥。不过你那边应该是可以的~

21 楼 k_june 2012-12-23  

楼主，http://code.google.com/p/summercool-hsf/ 这个框架删掉了？

20 楼 hs1988 2012-12-10  

谢谢开源，正好能用到！

19 楼 dragonsoar 2012-11-14  

ywzhang2000 写道

看了博主的分享，很是受用啊，但是能不能把这个框架的使用说一下，我看了那么多代码，无处下手啊，兄弟，在你方便的时候能否公布一下使用说明书，最好给一个简单的demo让我们开开眼界了

这个例子里面有demo的，我只要把里面的demo分析一下就OK了，呵呵。

18 楼 ywzhang2000 2012-10-23  

看了博主的分享，很是受用啊，但是能不能把这个框架的使用说一下，我看了那么多代码，无处下手啊，兄弟，在你方便的时候能否公布一下使用说明书，最好给一个简单的demo让我们开开眼界了

17 楼 yunnysunny 2012-09-11  

dragonsoar 写道

本人本来不想多说啥，但是本人从某一家互联网公司出来后，发表这篇论文实际是为开源社区想做一些事，但是被前公司告知说以前公司某人不高兴。。。

这是为何？
1. 我的代码是他写的？我操，这可能吗？
2. 我的代码是他研究的方案？我操，这可能吗？
3. 以为我走了接了我的位置，我的成果就都成某人的了？我操，这可能吗？

做技术，不是靠说别人不行来证明自己行，这个世界是小人得势的世界，但是知道的人都心知肚明，我也承认我不是啥大度的人，我是看那些成天只吹牛逼的人得到领导的欢心上去。本来想删除此文，毕竟一家小公司也没有啥技术实力，我弄的这些东西也是给某家公司有一些积累。但是，说别人不开心的理由让我关闭此博客，我想来想去不太好。

1. 我删了证明我是真的拿原公司的产品或是方案了，我不怕上法庭，因为代码一比便知，这些资料和成果是上一家公司没有的
2. 我删了证明接我班的人的成果被某人占有，所以想来想去还是不删了

我已经下载了，你现在删除了没啥用。你没有用代码赚钱，他们告你没有用。再说版权怎么能说是他们的呢，如果他们告你，你就反告他们，拿开源代码赚钱。

16 楼 dragonsoar 2012-09-11  

本人本来不想多说啥，但是本人从某一家互联网公司出来后，发表这篇论文实际是为开源社区想做一些事，但是被前公司告知说以前公司某人不高兴。。。

这是为何？
1. 我的代码是他写的？我操，这可能吗？
2. 我的代码是他研究的方案？我操，这可能吗？
3. 以为我走了接了我的位置，我的成果就都成某人的了？我操，这可能吗？

做技术，不是靠说别人不行来证明自己行，这个世界是小人得势的世界，但是知道的人都心知肚明，我也承认我不是啥大度的人，我是看那些成天只吹牛逼的人得到领导的欢心上去。本来想删除此文，毕竟一家小公司也没有啥技术实力，我弄的这些东西也是给某家公司有一些积累。但是，说别人不开心的理由让我关闭此博客，我想来想去不太好。

1. 我删了证明我是真的拿原公司的产品或是方案了，我不怕上法庭，因为代码一比便知，这些资料和成果是上一家公司没有的
2. 我删了证明接我班的人的成果被某人占有，所以想来想去还是不删了

15 楼 dragonsoar 2012-08-25  

lingyulin 写道

你好，请问你用的Kryo是2.16版本吗？为什么KryoKryoSerializer里面有很多类编译找不到的
如
com.esotericsoftware.kryo.Context
com.esotericsoftware.kryo.Kryo.RegisteredClass
com.esotericsoftware.kryo.serialize.BigDecimalSerializer
com.esotericsoftware.kryo.serialize.BigIntegerSerializer
import com.esotericsoftware.kryo.serialize.DateSerializer

那不能吧，我们用的是1.04，现在是05了。经过测试，2版本性能不够高，因为Object缓冲对象无法缓存