? ? ? ? ? ? 本文來自http://blog.csdn.net/liuxian13183/?，引用必須注明出處！


即時通信：前端獲得消息發送到服務端，服務端處理后通過推送的方式，發給接收方；Android使用長連機制，聯通網絡長連十幾分鐘，電信僅五六分鐘，因此需要根據測試的芯片類型，為了保活，可能要三四分鐘就要去連一次，叫心跳機制；IOS通過APN機制推送。即時通訊是在一種平等、開放情況下的互動，這點很重要。


推送：采用增量推送的方式，設置一個sequence，服務端一個客戶端一個，每次同步時客戶端將cur_seq發給服務端，獲得增量數據同步到本地。每個seq都是long型占8byte，考慮到微信用戶6億，Qps達到千萬級別，則每秒要處理100兆的IO，相對來說比較大，如何降低呢，微信有一個AllocSvr和StoreSvr兩個服務，分別來處理分配和存儲，設計一個max_Seq和步長，將一定數量的用戶比如連續ID一萬個，設計在同一個Section，加上一個max_Seq，步長設為10000，此時可以10^3個等級的數據量，相對AllocSvr處理就簡單一些，所以任何一個簡單的事情在海量數據下，都會變成一個復雜的問題。另外添加步長，就涉及Old AllocSvr和New AllocSvr，需要根據已知配置文件，有哪些服務器可以切換，考慮到容災還要做備份服務器，因此做互為備份是服務器能力不浪費的優秀設計；路由的切換也是根據seq的方式，使用路由表來切換的。




紅包：活動前將資源通過消息的方式同步到客戶端，防止活動當天同步資源造成浪費。每十萬級的紅包放一個包裹，加入票據，爭取更多的資金能夠進來，將分配規則寫入客戶端，然后將紅包寫入用戶，異步對賬后同步到賬戶里；要避免1、不存在的紅包分配給用戶2、紅包分配金額有誤 3、紅包發給不存在的人 4、紅包重復發給一個人 5、紅包重復發給其他人6、防止黑客攻擊，每個包裹寫一個公私鑰，同時可以手工屏蔽某些密鑰對，保證其中一對密鑰被盜，其他仍然可以正常使用。以及采用qos將請求主動失敗，分兩種系統失敗可以重試，邏輯失敗則失敗 ；由于對大廣告主如5000萬以上的做過系統配合，但也要在參與用戶少的時候，保證用戶搶紅包的流暢性，進行降級處理。


Android：剛開始業務為主，隨著業務量增大，逐漸改為功能為主，然后規劃多個dex，甚至將相應服務新開進程執行；秉承用戶體驗的觀點，復雜的邏輯一般放在服務端做，客戶端僅做展示功能；安全方面，每次登錄給予一個票據，用于服務端檢驗發送的信息是否合法；將主業務與工具和后臺業務分開，分多個進程處理，可以明顯降低內存和電量的消耗。


斑馬廣告：采用對一群人畫像如1萬人，而不對1個人進行畫像分析，每個人加入標簽，如年齡、旅游、科技等，如果需要5000萬定向客戶，而實際標簽不足時，需要通過lookalike系統查找潛在的和之前尚未分析出的客戶，準確率達到16%左右；標簽標的有：朋友圈發的消息、廣告的點擊和互動、公眾號的類型、店家wifi的登入等，對聊天記錄騰訊有天然的敏感性，不進行分析。


朋友圈：自己的timeline即自己發的信息，好友的timeline即公用區域發的信息，這個都以用戶為單位，將timeline分兩類，自己和好友，自己的直接顯示，好友的插入自己的消息，這是實現的第一步；第二位是交互，好友發一條消息，第一：哪些人可見哪些人不可見，好友這邊呢，操作是直接插入到可見好友的timleline，不可見好友收到的是相反的消息即不插入，第二：哪些是共同的好友，評論和點贊彼此收的到，實際出現三個對象，你、我、其他人，三者均需要一個消息推送（實際情況更復雜，多個直接跟你互相的人即是你，你的好友中非彼此好友的人即是其他人），最終采用增量推送的方式。

后端：消息分五類，紅包，文本和語音，圖片和視頻、群消息、朋友圈，優先保證第一項服務可用，然后保證第二項服務可用，最后再保證朋友圈可用，這是消息優先級，在信息量巨大時可以人工觸發開關處理；考慮到國內外通訊，香港地區延時100-200ms，歐美約300-500ms，國外的消息即就近處理，并且放在就近的服務器上，上海保證北方區，深圳保證南方區，香港保證東亞區，加拿大保證歐美區，這樣一方面保證應用的國外戰略得以實施，另一方面消息分流減輕服務器的壓力；值得講的一點是不同區之間的消息通訊，比如北方區的A和東南亞區的B，A發送消息，存儲在上海服務器，然后推送到香港服務器，由香港區推送給B，減少https公網的等待時間，另外一點如果此人經常全球跑，則數據會漫游到國內數據中心處理，否則經常切換數據中心和服務備份，會浪費大量資源，增加系統冗余。

接下來聊幾個服務端的點

數據接入-數據處理（邏輯處理-數據讀寫）-數據持久化（數據存儲）

Qos：quality of service 服務質量，網絡請求會分發到很多數據中心進行處理，而每個路由都有一個buffer，超過后則丟棄，否則數據積壓導致各方數據均不能有效處理，引起各種服務癱瘓；傳輸順序出錯和其他出錯，需要有相關協議保證重試。

Cgi：common gateway interface 大量用戶發送的請求，后臺會有無數個cgi程序都保證正確處理，比如消息推送和消息同步

容災：設計3的倍數個數據中心，保證每個數據中心有2/3的數據處理峰值，這樣在其中1/3個中心癱瘓時，其他2/3的中心可以接收它的處理能力。

埋點：與測試團隊溝通容易出錯的地方，做key-value增加策略，key為關鍵點的id，value為關鍵點數據+1的值，在后臺展示和處理，達到預警則及時處理，達到早發現、早處理的目的，這也是容災的一部分；另一部分是與產品團隊，共同開發出業務的使用頻率，為后面的產品設計和架構設計提供良好的數據支撐。

RPC：Remote Procedure Protocal 同步處理的消息往往是有限的，異步可以大限度的壓榨服務器的處理能力，如微信開發的SvrKit，用戶發出請求后，交付中間件異步處理，并提供出錯重試協議，保證消息被正確處理。

數據IO：讀寫在大量數據交互的應用上顯示尤為重要，提供memcache防止頻繁訪問數據庫，提供多Master-Slave提供數據讀寫服務，如海外A的消息存儲在加拿大，國內B的消息存儲在上海，這就是兩個Master，兩者通信通過RPC推送到對方數據中心即可，Slave用在Master出問題時的備用存儲方案，事后要兩者要互相同步。

圖片：用戶發送后放到CDN處理，返回大圖和縮略圖鏈接，加到消息對象中，返回客戶端。
同步：采用seq增量下發消息的方式，對郵件、漂流瓶等進行key-value的判斷拉取數據。

安全：每次登錄都帶有票據，票據用密鑰對+ID來處理，可以隨時定向失效密鑰。

本文來自http://blog.csdn.net/liuxian13183/?，引用必須注明出處！

總結

以上是生活随笔為你收集整理的研究微信即时通讯的服务端、朋友圈、红包、推送等方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。