《環信支持千萬併發即便通信的技術要點》閱讀摘要

一天早上起來，偶然機會看到《環信支持千萬併發即便通信的技術要點》演示文檔，簡單翻閱以後，感受乾貨不少，因而快速記下如下筆記。

一。IM協議和IM Server

XMPP確實很傳統，WhatsApp選用了，同時通過壓縮、精簡（好比說user字符串使用u字符替代）處理，讓XMPP輕量很多。

MQTT，如何實現羣組、好友呢，這個是業務層面上事情，你們都訂閱某一個主題Topic好了，屬於業務拓展。

SIP，接觸少。

微信私有協議ActivitySync，之前在博客上分享過。

正確拼寫是WhatsApp，呵呵。

針對XMPP協議的改進，頗有參考價值。

心跳單向四個字節，在XMPP協議下，估計應該是極限了吧。在私有協議協議下，一來一往兩個字節足夠。

文件傳輸方式，這是業界通用方式。

移動互聯網環境下，用戶永遠在線，你們的共識。但是取決於手機有沒有鏈接到服務器端，這是沒法逾越的障礙。

Muc聊天室，業務層面改進。

這個針對使用OpenFire的同窗，頗有參考意義。

話說，我之前也安裝過OpenFire，定製過在線聊天/諮詢的代碼。

二。移動網絡環境下的網絡、電量等客戶端優化

IM或推送，創建長鏈接是必須的，能夠節省TCP來回建立的開銷，但斷線以後，是否須要即刻重連，尤爲是處於地鐵、WIFI邊緣地帶，可能會形成重連風暴，須要添加稍加延遲鏈接機制。

針對發送的消息的回執，客戶端必定要發送回執反饋，不然不知道是否發送成功與否。

流量跑馬測速，心跳智能，壓縮傳輸。

Android手機端優化措施，乾貨、細節很實用，能夠直接拿來用，分享很給力，呵呵！

批量、合併數據請求/發送，增量更新，這是一個你們都應該使用的常規節省流量手段，應牢記！

可貴的是，分享了：

2G 文件上傳最佳buffer size 1024個字節，3G/4G下直接設置爲10K

2G 文件下載最佳buffer size 2048個字節，3G/4G下 30K

絕對經驗的總結，贊！

心很細，給出了頻繁的屬性訪問直接聲明protected/publish了，不建立新的Java對象只能static類型了。記得好久之前寫J2ME程序時，就用過這樣的方式。

實踐中走過多少彎路才總結出來的同步、繪圖、渲染頁面驚豔，尤爲是支持離線方式的數據同步機制，很受用。

三。百萬級架構經驗分享

雖然很簡單，熟悉TCP/IP協議，這是毫無疑問。

無狀態協議交互，纔可以很容易水平橫向擴展，也是當今共識。

讓全部操做都要儘量的異步

典型的按照機房進行完整部署，若不可以在DNS層面作到按照用戶ID進行指派（HTTP DNS進行接入IP分配），那麼就必須處理用戶亂入機房的問題，必然要作到一些數據的跨機房的同步，你們都會採用增量式同步方式，跨機房通常常見30毫秒的延遲，批量形式增量同步，那都不叫事。

能夠看到業務垂直切分，各個業務之間水平擴展。

貌似能夠看到單元化CELL/SET架構的影子，但這只是本身的瞎猜而已。

PPT上架構圖文字細節不甚清晰，再加上本身近視，分辨不太老好的，能夠看到消息存儲使用了Kafka（和數據庫集羣之間存定時拉取關係），分佈式鎖基於Zookeeper，前端LVS作負載均衡，業務很是垂直。

在PPT上只看到了兩個機房，若用戶量級上億，可能須要擴展到第三個、第三機房，可能跨機房同步的壓力就就凸顯出來了。

四。小結

總之，乾貨很多，很給力，再次對劉少壯大牛表示感謝！

原PPT下載地址：http://vdisk.weibo.com/s/A0GI9rXObFMd

PS: 如有侵權，請及時告知。