求教基于Netty4的消息推送系统的实时性问题，要求200万并发、5秒推完

    最近一个项目，要求最大200万并发，一条消息大概0.2K~0.3K，5秒内推送完毕。初期规划的架构是使用netty4，采用tcp长连接    一期测试目的，单机10万并发，测试环境如下        服务器：4核8G

        客户端：4核8G * 2，每个客户端发起5W个长连接，测试客户端也是用netty编写

    测试下来发现，晚上，10万并发5秒内消息可送达客户端；白天，基本在6~10秒不等，有时还会更长
    疑问
        1. 有时10万条消息，就剩下最后的几十条发不出去，要等待30~60秒左右才收到，这个是因为什么？
        2. 影响消息送达效率的是跟晚上和白天的网络情况有关么？这一块，有啥理论计算指标没？比如需求怎样的硬件或网络负载之类的
        3. 单机5万个长连接，跟公网上5万个IP，每个IP一个长连接的发送效率有区别么（假定网络状况都是良好的）？
        4. 一般各大厂商的推送效率是多少？配置如何？主要是TCP还是UDP协议？
        5. 测试过程中，尝试把发送的消息，降低在0.05K以内，相同的连接数下，发送效率并没有提升，这个是因为什么？
        6. MobileIMSDK的java测试客户端是单例模式的，有没有非单例模式的代码可参考？

你这个推送系统是要用在什么场景下？
200万并发？你是指同时向200万客户端推送200万条消息吗？

推送主要是用于预警系统，安装android系统的设备通过网线或wifi接入公网。目前预计最多200万台设备，要在5秒内能收到推送的预警消息。目前计划先实现单机10万并发，5秒内送达。前面又测试了一遍，10万个链接全部送达时间在6~7秒。但是同一个网络下，扩展到2台服务器20万个并发链接的时候，延迟至少15秒以上~

引用：gaion 发表于 2019-11-21 14:07
推送主要是用于预警系统，安装android系统的设备通过网线或wifi接入公网。目前预计最多200万台设备，要在5 ...

先说单台，10万连接，10万消息，全部送达6~7秒，服务端的吞吐效率大约1万4，这个吞吐效率还有优化空间，至少翻1到3倍没什么太大问题，如果吞吐效率上去了的话，估计延迟就能降到5秒内。

至于扩展到2台服务器，推送不像IM，它不需要横向的消息互通，所以多台跟1台的效率相差不会太多，如果相差太多，那你得找找是不是推送指令下达到这两台服务器时有延迟。

推送系统, 如果讲效率, 肯定是udp，如果要降低复杂性的话，用tcp。市面上的那些第3方，推送效率不高的，他们讲的是送达率，不是时效性，必竟普通的推送，比如新闻、天气、通知这些，对于接收的人来说，差个几秒，甚至几分钟没什么大不了的，who care! 你care？不信你看看你的手机上的通知~~~~~~ 你在意那条迟发, 迟发了几秒？几分钟？还是几小时呢？一般人的底线是只要不漏推就行了

如图是我目前的网络结构，两台推送服务器在同一个内网，分别有一个公网IP连接在运营商的交换机上（为了避开路由的影响，之前一台华三的路由只允许60000个连接）。4个模拟客户端是放在公网上的另外一个公司的网络下。两台服务器都是从ActiveMQ获取消息，经观察不存在延迟。在这个网络情况下，把服务端B、客户端C、客户端D停了，仅初始化10万个连接，消息延迟6~7秒，全部上线，每台服务端10万连接后，15秒以上~吞吐率优化的方式有哪些啊？以下是我服务端java的初始化代码和centos7的内核优化参数，有的糊里糊涂，网上参照的~

EventLoopGroup boosGroup = new EpollEventLoopGroup();
EventLoopGroup workerGroup = new EpollEventLoopGroup();
ServerBootstrap serverBootstrap = new ServerBootstrap()
.group(boosGroup, workerGroup) .channel(EpollServerSocketChannel.class) .attr(AttributeKey.newInstance("serverName"), "nettyServer")
.childAttr(clientKey, "clientValue")
.option(EpollChannelOption.SO_BACKLOG, 1024)
.option(EpollChannelOption.SO_REUSEPORT, true)
.childOption(EpollChannelOption.SO_KEEPALIVE, true) .childOption(EpollChannelOption.SO_SNDBUF, 256 * 1024)
.childOption(EpollChannelOption.TCP_NODELAY, true)
.childHandler(mIMServerHandlerInitializer); 

net.ipv4.ip_local_port_range = 15535 65535
fs.file-max = 20000000
fs.nr_open = 20000000
net.core.somaxconn = 102400
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_syncookies = 1
net.core.netdev_max_backlog = 419600
net.ipv4.tcp_max_tw_buckets = 300000
net.ipv4.tcp_tw_reuse = 1  
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_time = 900
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_fin_timeout = 15  
net.ipv4.tcp_max_orphans = 131072  

另外还有一个尝试的思路，就是再建一个UDP的推送。初始化客户端同时建立TCP和UDP的通道，预警消息到了之后，服务端先用UDP推送一遍，客户端收到后，用tcp链路反馈回执。4秒后服务端对没收到回执的客户端用TCP通道再发一次~

引用：gaion 发表于 2019-11-22 01:18
另外还有一个尝试的思路，就是再建一个UDP的推送。初始化客户端同时建立TCP和UDP的通道，预警消息到了之后 ...

先抛开别的问题不说，你开两台，延迟居然变成15秒以上，这显然不合理，理论上讲，因为每台服务器和负载并没有变化。我建议你先找这个原因。

还有，你要观察，公网的带宽有没有打满。

我觉得应用程序之外的几个方面需要排查：
1）消息-》AMQ-》之间的延迟是多少?
2）客户机（内网） -》服务器（公网）之间的延迟是多少？
3）如 JackJiang 说的，带宽是否存在瓶颈？如果没计算错误的话，0.05K的消息，10W客户端，至少需要38.14M（50*100000/1048576*8 ~= 38.14 Mbit)的带宽。
4）客户端所在网络入口带宽是多少？是否存在瓶颈 等。

两台并发的时候带宽是问题，这个我去调整一下测试的报文再试试，另外，单机的吞吐率还有哪些提升建议么？

消息→AMQ→推送服务器，这一条线路都是在内网，延迟在3ms以下。
客户端的公网有100M，客户机的内网与推送服务器之间的延迟在15ms左右
客户端内网，60M的文件传输，1~2秒