高性能實(shí)時(shí)應(yīng)用架構(gòu)設(shè)計(jì)

1、高性能實(shí)時(shí)應(yīng)用架構(gòu)設(shè)計(jì)目錄挑戰(zhàn)與難點(diǎn)架構(gòu)篇性能篇總結(jié)實(shí)時(shí)應(yīng)用簡(jiǎn)介易信 - java網(wǎng)易的流行移動(dòng)聊天工具千萬級(jí)別在線消息推送平臺(tái) - node.js + java千萬級(jí)別在線新聞客戶端 有道云筆記 云音樂 云閱讀 移動(dòng)消息推送的平臺(tái)消息推送平臺(tái)推送消息到移動(dòng)端、web端的通用平臺(tái)，接入了網(wǎng)易幾乎所有主要的移動(dòng)產(chǎn)品挑戰(zhàn)與難點(diǎn)消息推送平臺(tái)平臺(tái)需高可用，并支持水平擴(kuò)展支持千萬級(jí)高并發(fā)下的實(shí)時(shí)推送網(wǎng)絡(luò)不穩(wěn)定情況下的消息可靠性（QoS1）系統(tǒng)需具備高度穩(wěn)定性和可靠性針對(duì)不同消息推送需求制定不同解決方案移動(dòng)終端的4S要求：Slim、Save power、 Save traffic、Stable消息推送平臺(tái)

2、-挑戰(zhàn)與難點(diǎn)網(wǎng)絡(luò)不穩(wěn)定狀況下消息仍可達(dá)，私信到達(dá) 率99.9%以上99.9%的消息1S以內(nèi)到達(dá)Android SDK月流量消耗1000，全域廣播TPS10w挑戰(zhàn)與難點(diǎn)易信支持上億的同時(shí)在線規(guī)模消息發(fā)送的密度與頻率高于消息推送平臺(tái)，私信的TPS達(dá)10萬級(jí)，群聊的TPS達(dá)1萬級(jí)網(wǎng)絡(luò)不穩(wěn)定狀況下消息仍可達(dá)，私信到達(dá) 率99.99%以上99.99%的消息1S以內(nèi)到達(dá)高質(zhì)量語音通訊目錄挑戰(zhàn)與難點(diǎn)架構(gòu)篇性能篇總結(jié)架構(gòu)討論基礎(chǔ)架構(gòu)消息實(shí)時(shí)性消息到達(dá)率高可用易信聊天部分高可用消息推送經(jīng)過的所有功能服務(wù)進(jìn)程無單點(diǎn)故障高可用消息隊(duì)列服務(wù)確保消息可靠性多種流控和退避機(jī)制確保系統(tǒng)可靠性無狀態(tài) VS 有狀態(tài)在線狀態(tài)連接

3、服務(wù)器 維護(hù)長(zhǎng)連接Redis高可用集群方案 zookeeper+presharding高可用redis集群高可用redis集群presharding + 二級(jí)Hash負(fù)載均衡消息推送平臺(tái)的負(fù)載均衡策略 LVSDR,RR模式socket.io采用source hash易信的負(fù)載均衡策略 LBS使用智能DNS支持異地部署一組IP，多個(gè)端口重連保證消息到達(dá)率高可用隊(duì)列qos=1消息備份Redis高可用，slave存盤離線消息Redis備份消息，Ack后才刪除客戶端保存接收最后一條消息的時(shí)間戮客戶端重連拉未消費(fèi)消息消息到達(dá)流程移動(dòng)端 - android客戶端鏈路復(fù)用基于MQTT協(xié)議心跳周期退避服務(wù)端擁

4、塞退避斷線重連機(jī)制簽名認(rèn)證機(jī)制支持消息去重支持自動(dòng)/手動(dòng)AckSDK升級(jí)策略（兼容+并存）APK1Push SDKAPK2Push SDKPush ServicePush ServerAndroid目錄挑戰(zhàn)與難點(diǎn)架構(gòu)篇性能篇總結(jié)性能性能指標(biāo)消息實(shí)時(shí)性廣播的性能優(yōu)化GC- node.js 與 java性能支持的連接數(shù) 易信（netty） ，25W連接，12G內(nèi)存(前提： 不 出現(xiàn)頻繁Full GC）,內(nèi)存占用約40K/連接1.5W連web易信(netty)， 如果使用long polling,接，CPU 90%消息推送平臺(tái)（node.js mqtt協(xié)議），3W連接，600M內(nèi)存，內(nèi)存占用約 18

5、K/連接消息推送平臺(tái)web端（node.js socket.io）， 如果是long polling, 只能支撐3000個(gè)連接性能QPS易信單進(jìn)程6.8w并發(fā)用戶時(shí)，發(fā)送點(diǎn)對(duì)點(diǎn)消息，14000/S響應(yīng)時(shí)間 4ms以下CPU 70%內(nèi)存8G消息推送平臺(tái)單進(jìn)程2w并發(fā)用戶時(shí)，點(diǎn)對(duì)點(diǎn)消息， 3000/s數(shù)千萬條廣播，5秒內(nèi)發(fā)完消息的實(shí)時(shí)性實(shí)時(shí)性要求高需要不停的測(cè)試與優(yōu)化消息路徑劃分與報(bào)警一次故障排查GC消息實(shí)時(shí)性 - 消息路徑劃分實(shí)時(shí)性要求按消息路徑劃分處理時(shí)間， 對(duì)各級(jí)響應(yīng)時(shí)間打點(diǎn)細(xì)粒度監(jiān)控、報(bào)警優(yōu)化所有的參數(shù) 服務(wù)器、應(yīng)用、網(wǎng)絡(luò)消息實(shí)時(shí)性 - 一次故障排查實(shí)例現(xiàn)象：產(chǎn)品反映聊天時(shí)響應(yīng)較慢toPr

6、oxyTime經(jīng)常飆升到1秒另一個(gè)產(chǎn)品toProxyTime升到3秒消息實(shí)時(shí)性消息路徑toProxyTime = endTime startTime排除法定位出nginx問題抓包1秒問題3秒問題解決辦法解決辦法：Nginx到后端開啟keepAlive消息推送平臺(tái)挑戰(zhàn) - 新聞客戶端的實(shí)時(shí)性要求一分鐘內(nèi)廣播消息給數(shù)千萬個(gè)客戶端測(cè)試結(jié)果廣播推送：15秒內(nèi)推完按附件推送： 100萬需要5分鐘，瓶頸在filterclientconnectorredisreceiverfilter廣播優(yōu)化策略批處理所有操作批處理查redis批量發(fā)消息到連接服務(wù)器優(yōu)化后附件廣播100萬條在50秒之內(nèi)推完退避策略通過MQ自

7、身的機(jī)制退避，廣播消息在push完之后ack當(dāng)廣播的數(shù)量過大時(shí)， 適當(dāng)退避，讓出CPU消息實(shí)時(shí)性 - GCNode.js的GC基于V8，分代收集單進(jìn)程吃不了太多內(nèi)存，保持在600M以下Young GC的時(shí)間很短， 在內(nèi)存低的情況下FullGC也能控制在30ms之內(nèi)-max-new-space- size=2048Java的GC分代收集文檔多，很復(fù)雜的參數(shù)CMS，G1對(duì)實(shí)時(shí)應(yīng)用很重要一般建議java內(nèi)存4G以 下，但由于連接服務(wù)器 吃內(nèi)存的要求，配到8G 或以上易信GC長(zhǎng)連接服務(wù)器的內(nèi)存管理吃內(nèi)存實(shí)時(shí)性要求高，千萬不能出現(xiàn)幾秒的full gc， 需要采用CMS新生代的產(chǎn)生數(shù)據(jù)較多，不符合新產(chǎn)生的數(shù)據(jù)生命周期短的年青代規(guī)則使用CMS時(shí)千萬不要promotion failure易信GC+UseConcMarkSweepGC-XX:SurvivorRatio=3-Xms12G -Xmx12G -Xmn2g-XX:CMSInitiatingOccupancyFraction=80-XX:+PrintPromotionFailure-XX:+UseCMSCompactAtFullCollection-XX:MaxTenuringThreshold=8-XX:+CMSClassUnloadingEnabled總結(jié)實(shí)時(shí)應(yīng)用架構(gòu)C/C+微信Node.js & po