即時通訊：前端得到消息發送到服務端，服務端處理後經過推送的方式，給到接收方；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的方式，使用路由表來切換的。
紅包：活動前將資源經過消息的方式同步到客戶端，防止活動當天同步資源形成浪費。每十萬級的紅包放一個包裹，加入票據，爭取更多的資金可以進來，將分配規則寫入客戶端，而後將紅包寫入用戶，異步對帳後同步到帳戶裏；要避免一、不存在的紅包分配給用戶二、紅包分配金額有誤 三、紅包發給不存在的人 四、紅包重複發給一我的 五、紅包重複發給其餘人六、防止黑客攻擊，每一個包裹寫一個公私鑰，同時能夠手工屏蔽某些密鑰對，保證其中一對密鑰被盜，其餘仍然能夠正常使用。以及採用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：同步處理的消息每每是有限的，異步能夠大限度的壓榨服務器的處理能力，如微信開發的SvrKit，用戶發出請求後，交付中間件異步處理，並提供出錯重試協議，保證消息被正確處理。
數據IO：讀寫在大量數據交互的應用上顯示尤其重要，提供memcache防止頻繁訪問數據庫，提供多Master-Slave提供數據讀寫服務，如海外A的消息存儲在加拿大，國內B的消息存儲在上海，這就是兩個Master，二者通訊經過RPC推送到對方數據中心便可，Slave用在Master出問題時的備用存儲方案，過後要二者要互相同步。
圖片：用戶發送後放到CDN處理，返回大圖和縮略圖連接，加到消息對象中，返回客戶端。
同步：採用seq增量下發消息的方式，對郵件、漂流瓶等進行key-value的判斷拉取數據。
安全：每次登陸都帶有票據，票據用密鑰對+ID來處理，能夠隨時定向失效密鑰。
