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

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

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)易信支持上億的同時在線規(guī)模消息發(fā)送的密度與頻率高于消息推送平臺，私信的TPS達(dá)10萬級，群聊的TPS達(dá)1萬級網(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í)時性消息到達(dá)率高可用易信聊天部分高可用消息推送經(jīng)過的所有功能服務(wù)進(jìn)程無單點(diǎn)故障高可用消息隊(duì)列服務(wù)確保消息可靠性多種流控和退避機(jī)制確保系統(tǒng)可靠性無狀態(tài) VS 有狀態(tài)在線狀態(tài)連接

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

4、塞退避斷線重連機(jī)制簽名認(rèn)證機(jī)制支持消息去重支持自動/手動AckSDK升級策略（兼容+并存）APK1Push SDKAPK2Push SDKPush ServicePush ServerAndroid目錄挑戰(zhàn)與難點(diǎn)架構(gòu)篇性能篇總結(jié)性能性能指標(biāo)消息實(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%消息推送平臺（node.js mqtt協(xié)議），3W連接，600M內(nèi)存，內(nèi)存占用約 18

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

6、oxyTime經(jīng)常飆升到1秒另一個產(chǎn)品toProxyTime升到3秒消息實(shí)時性消息路徑toProxyTime = endTime startTime排除法定位出nginx問題抓包1秒問題3秒問題解決辦法解決辦法：Nginx到后端開啟keepAlive消息推送平臺挑戰(zhàn) - 新聞客戶端的實(shí)時性要求一分鐘內(nèi)廣播消息給數(shù)千萬個客戶端測試結(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ù)量過大時， 適當(dāng)退避，讓出CPU消息實(shí)時性 - GCNode.js的GC基于V8，分代收集單進(jìn)程吃不了太多內(nèi)存，保持在600M以下Young GC的時間很短， 在內(nèi)存低的情況下FullGC也能控制在30ms之內(nèi)-max-new-space- size=2048Java的GC分代收集文檔多，很復(fù)雜的參數(shù)CMS，G1對實(shí)時應(yīng)用很重要一般建議java內(nèi)存4G以 下，但由于連接服務(wù)器 吃內(nèi)存的要求，配到8G 或以上易信GC長連接服務(wù)器的內(nèi)存管理吃內(nèi)存實(shí)時性要求高，千萬不能出現(xiàn)幾秒的full gc， 需要采用CMS新生代的產(chǎn)生數(shù)據(jù)較多，不符合新產(chǎn)生的數(shù)據(jù)生命周期短的年青代規(guī)則使用CMS時千萬不要promotion failure易信GC+UseConcMarkSweepGC-XX:SurvivorRatio=3-Xms12G -Xmx12G -Xmn2g-XX:CMSInitiatingOccupancyFraction=80-XX:+PrintPromotionFailure-XX:+UseCMSCompactAtFullCollection-XX:MaxTenuringThreshold=8-XX:+CMSClassUnloadingEnabled總結(jié)實(shí)時應(yīng)用架構(gòu)C/C+微信Node.js & po