默認
發表評論 10
想開發IM:買成品怕坑?租第3方怕貴?找開源自已擼?盡量別走彎路了... 找站長給點建議
求教基于Netty4的消息推送系統的實時性問題,要求200萬并發、5秒推完
閱讀(987) | 評論(10 收藏1 淘帖
    最近一個項目,要求最大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測試客戶端是單例模式的,有沒有非單例模式的代碼可參考?

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:全面盤點當前Android后臺保活方案的真實運行效果(截止2019年前)
推薦方案
評論 10
你這個推送系統是要用在什么場景下?
200萬并發?你是指同時向200萬客戶端推送200萬條消息嗎?
簽名: 《主流移動端賬號登錄方式的原理及設計思路》http://www.uktmgv.tw/thread-2863-1-1.html
推送主要是用于預警系統,安裝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臺的效率相差不會太多,如果相差太多,那你得找找是不是推送指令下達到這兩臺服務器時有延遲。
簽名: 《主流移動端賬號登錄方式的原理及設計思路》http://www.uktmgv.tw/thread-2863-1-1.html
推送系統, 如果講效率, 肯定是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  

[email protected] (82.71 KB, 下載次數: )

QQ20191122-003923@2x.png
簽名: 性能不達標
另外還有一個嘗試的思路,就是再建一個UDP的推送。初始化客戶端同時建立TCP和UDP的通道,預警消息到了之后,服務端先用UDP推送一遍,客戶端收到后,用tcp鏈路反饋回執。4秒后服務端對沒收到回執的客戶端用TCP通道再發一次~
簽名: 性能不達標
引用:gaion 發表于 2019-11-22 01:18
另外還有一個嘗試的思路,就是再建一個UDP的推送。初始化客戶端同時建立TCP和UDP的通道,預警消息到了之后 ...

先拋開別的問題不說,你開兩臺,延遲居然變成15秒以上,這顯然不合理,理論上講,因為每臺服務器和負載并沒有變化。我建議你先找這個原因。

還有,你要觀察,公網的帶寬有沒有打滿。
簽名: 《主流移動端賬號登錄方式的原理及設計思路》http://www.uktmgv.tw/thread-2863-1-1.html
我覺得應用程序之外的幾個方面需要排查:
1)消息-》AMQ-》之間的延遲是多少?
2)客戶機(內網) -》服務器(公網)之間的延遲是多少?
3)如 JackJiang 說的,帶寬是否存在瓶頸?如果沒計算錯誤的話,0.05K的消息,10W客戶端,至少需要38.14M(50*100000/1048576*8 ~= 38.14 Mbit)的帶寬。
4)客戶端所在網絡入口帶寬是多少?是否存在瓶頸 等。
簽名: 52im day 2
兩臺并發的時候帶寬是問題,這個我去調整一下測試的報文再試試,另外,單機的吞吐率還有哪些提升建議么?
簽名: 性能不達標
消息→AMQ→推送服務器,這一條線路都是在內網,延遲在3ms以下。
客戶端的公網有100M,客戶機的內網與推送服務器之間的延遲在15ms左右
客戶端內網,60M的文件傳輸,1~2秒
簽名: 性能不達標
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特