開發(fā)大牛實戰(zhàn)經(jīng)驗：千萬級并發(fā)下的推送系統(tǒng)建設(shè)策略解析

1、千萬級并發(fā)下的推送系統(tǒng)建設(shè)策略解析葉新江/Anson Ye個推個信互動AgendaPart 1. 推送系統(tǒng)總體要求Part 2. 面臨的主要挑戰(zhàn)和解決方案Part 3. 小團隊打造大平臺的實施策略Part 1推送系統(tǒng)總體要求One Push Can Change E推送 = 通知通知 + 消息消息推送不能僅僅是通知，推送不能僅僅是通知，而更需要突出消息屬性而更需要突出消息屬性 集中展示集中展示 內(nèi)容預(yù)覽內(nèi)容預(yù)覽 消息管理消息管理推送的目的：消息價值推送的目的：消息價值最大化最大化推送是什么？為甚么需要它？周知的推送平臺均偏重基礎(chǔ)能力、存在痛點！移動運營商時代的推送訴求SMS 推送時代被證明了推

2、送的價值但是： - 內(nèi)容不夠豐富 - 大小限制 - 無法滿足端對端的完成業(yè)務(wù)鏈 - 被濫用移動互聯(lián)時代的推送訴求 - 更低成本更高效率 - 展示的內(nèi)容豐富，有聲有色有視頻 - 智能判斷內(nèi)容對應(yīng)的應(yīng)用，智能下載安裝 - 和應(yīng)用能互動, 能促進(jìn)應(yīng)用的活躍 - 對用戶分段，針對性要強 - 不要騷擾用戶 - 用戶具有管理權(quán)力理想的推送系統(tǒng)不僅僅是一個具備推送能力的平臺，更是一個為滿足整個生態(tài)發(fā)展，加強互動和協(xié)作的服務(wù)需要具備的基因- 支持大規(guī)模高并發(fā)（千萬級）- 支持億級用戶規(guī)模- 至少 99.9 可用性- 網(wǎng)絡(luò)不穩(wěn)定環(huán)境下的生存力- 低耗電、低流量下的客戶側(cè)控制- 開發(fā)集成- 運營集成- 滿足生態(tài)系

3、統(tǒng)各角色需求的接入和控制Part 2面臨的主要挑戰(zhàn)和解決方案移動推送需要面對的主要技術(shù)挑戰(zhàn)推送方式選擇- Pull 方式 優(yōu)點： 由客戶端進(jìn)行控制，服務(wù)端開發(fā)相對簡單 可以使用通用的 http client/server 缺點： 無論是否有內(nèi)容，均需要消耗流量 適合場景： 比較適合數(shù)據(jù)變化比較快，實時要求不高的場合 頻率的選擇是關(guān)鍵頻率的選擇是關(guān)鍵推送方式選擇- PUSH 方式 優(yōu)點： 由客戶端和服務(wù)端均可以進(jìn)行控制 實時性較高 缺點： 服務(wù)端開發(fā)復(fù)雜，需要解決大并發(fā)連接的問題 適合場景： 比較適合數(shù)據(jù)不是經(jīng)常變化 或者實時要求比較高的場合 可選擇技術(shù)： BOSH/Comet 長連接 推送方式

4、選擇 優(yōu)先采用 Push+長連接方式 * 可以提供高實時性要求 * 建立在解決省電省流量基礎(chǔ)上 * 有大并發(fā)同時連接系統(tǒng)的經(jīng)驗 可根據(jù)應(yīng)用特性配置使用類 Pull 方式移動終端側(cè)要求- 作為集成到應(yīng)用的一個層，需要做到： Slim ： 苗條、小樣 Save power ： 省電 Save traffic ： 省量 Stable ： 穩(wěn)定 端側(cè) 4S 要求和標(biāo)準(zhǔn)。 端側(cè) 4S 如何做到- Slim 這個相對容易，消除無用或者重復(fù)的代碼，控制圖片等資源的使用 - Save power 手機電源的續(xù)航能力比較差，所以要從各個細(xì)節(jié)去摳 不要使用過多線程，可以采用類似ActiveObject 的方法用單

5、線程模擬多任務(wù)處理 盡量少使用多個連接（采用連接復(fù)用、主從模式） 減少不必要的計算（通過 profiler 等工具來看哪些最好資源等) 要摒除編寫一般 Java 程序的習(xí)慣 同時要防止 CPU 在需要的時候休眠（使用 PM WakeLock 和 AlarmManager)端側(cè) 4S 如何做到- Save traffic 協(xié)議選擇 (XMPP 還是私有協(xié)議？） XMPP: 開放、跨平臺、分布式、安全；但是在窄帶網(wǎng)絡(luò)以及易斷網(wǎng)絡(luò)中，不一定是最好的選擇 私有協(xié)議：不開放、無法互通、安全策略需要自己考慮；但是可以定制、節(jié)省流量 心跳頻率的控制，以實際設(shè)備網(wǎng)絡(luò)、CPU 休眠時間作為主要依據(jù) 數(shù)據(jù)壓縮 數(shù)

6、據(jù)盡量Bundle傳輸 斷點續(xù)傳 有 WiFi 就優(yōu)先使用 Wifi 云端代理（這個目前使用第三方服務(wù)）- Stable 獨立的進(jìn)程， 盡量不影響應(yīng)用本身 Android Bind/AIDL 機制端側(cè)另外需要的引擎- 內(nèi)建的 Content Render Engine (CRE) 布局 內(nèi)容抓取 Text, Image, Web View, Video- 內(nèi)建的 Action Chain Engine (ACE) 把一系列的動作形成相關(guān)的數(shù)據(jù)鏈 Action 類型可以是： - 消息提示、顯示 - 消息透傳 - 跳轉(zhuǎn)到 browser - 啟動應(yīng)用 - 下載應(yīng)用 - 激活應(yīng)用適應(yīng)生態(tài)的云端云端需

7、要的基礎(chǔ)部件框架化、組件化、插件化：u 配置管理u 群集 （負(fù)載均衡、容錯、動態(tài)伸縮）u 流控u 服務(wù)管理（注冊、尋址）u 依賴管理u 灰度控制u 分布數(shù)據(jù)操作u 大數(shù)據(jù)處理u 監(jiān)控與告警一個可以參考的系統(tǒng)架構(gòu)單實例并發(fā)處理能力 50萬吞吐量較v1 * 10 倍動態(tài)集群形成（處理&數(shù)據(jù)單元）較靈活的可擴展數(shù)據(jù)層集中配置管理灰度控制支持 初步大數(shù)據(jù)處理框架業(yè)務(wù)運營框架具備 云端的幾個關(guān)鍵點解析- 大并發(fā)長下的技術(shù)要點 盡量減少應(yīng)用內(nèi)存的footprint. 高效使用內(nèi)存(pre-alloc mem pool, thread-local-mem pool) 選擇合適 OS 和 語言組合 如果是 J

8、ava, NIO 是必須的. NIO 事件處理模式的選擇 如果是 Java, JVM 的調(diào)優(yōu)也是關(guān)鍵 （Heap size, GC etc) 注意一些已知的問題（譬如 JDK 7 之前的 Select Spin） 內(nèi)核調(diào)優(yōu)（特別是網(wǎng)絡(luò)參數(shù)方面） 云端的幾個關(guān)鍵點解析- 異步系統(tǒng)的痛并快樂 要增加系統(tǒng)的吞吐量，系統(tǒng)內(nèi)部需要異步調(diào)用 異步會使復(fù)雜度增加，但是在很多時候是值得的 需要內(nèi)部有統(tǒng)一的通訊框架(支持同步、異步、回調(diào)；廣播、隨機、輪詢等機制）- 去狀態(tài)化，全 cluster 狀態(tài)化會導(dǎo)致資源的 affinity, 在 scalability 方面有較大影響。易于水平擴展。狀態(tài)轉(zhuǎn)移到公用設(shè)置上

9、（如分布緩存或者 DB 中，但是必須考慮故障時的轉(zhuǎn)移效率和成本） 各個組件均 cluster 化，隨時擴展容量，系統(tǒng)自調(diào)整能力強。云端的幾個關(guān)鍵點解析- 分布式組件 分布式緩存 自動平衡、自動復(fù)制、容錯 或者應(yīng)用自行根據(jù)需要來進(jìn)行功能補充（例如雙寫、多寫等） 分布式數(shù)據(jù)庫存儲層 自動分發(fā)、路由設(shè)置、邏輯上去除不同數(shù)據(jù)庫的差異。- 數(shù)據(jù)分析和 BI 大數(shù)據(jù)量處理 （Hadoop, Hive， infoBright w/ MySQL等 ) 如果成本或者資源不允許，可以租用公共云服務(wù) 云端的幾個關(guān)鍵點解析 - 應(yīng)用域隔離/灰度控制 不同的應(yīng)用有時候需要邏輯上進(jìn)行隔離 不同的版本很多時候需要滾動升級，

10、只能在不同的時間進(jìn)行升級，而且在可用性要求下必須動態(tài)調(diào)整 實現(xiàn)策略： 整合到 cluster 方案中，使用高可靠的協(xié)作組建（zk) 來進(jìn)行組件配置及狀態(tài)管理 云端的幾個關(guān)鍵點解析 - 保證推送到達(dá)率 目標(biāo) 99% 有效用戶到達(dá)率 推送時間 3s (端對端） 策略： 用戶冷熱狀態(tài)內(nèi)存緩存 在線用戶：使用最接近端側(cè)的傳輸?shù)竭_(dá)機制 離線用戶： 冷熱用戶分層 數(shù)據(jù)存儲分層 精細(xì)化的要求- 運營與服務(wù)驅(qū)動- 業(yè)務(wù)制作可視化- 業(yè)務(wù)種類細(xì)分（系統(tǒng)需適應(yīng)性演進(jìn)）- 最終用戶種類細(xì)分（系統(tǒng)需適應(yīng)性演進(jìn)）- 合作者種類細(xì)分（系統(tǒng)需適應(yīng)性演進(jìn)）- 不同合作模式下的系統(tǒng)版本分離（SaaS, Out-of-Box 產(chǎn)品等）Part 3小團隊打造大平臺的策略小團隊，所以必須靈活敏捷的流程及持