看了極光推送技術原理的幾點思考
移動網際網路應用現狀
因為手機平臺本身、電量、網路流量的限制,移動網際網路應用在設計上跟傳統 PC 上的應用很大不一樣,需要根據手機本身的特點,儘量的節省電量和流量,同時又要儘可能的保證資料能及時到達客戶端。
為了解決資料同步的問題,在手機平臺上,常用的方法有2種。一種是定時去伺服器上查詢資料,也叫Polling,還有一種手機跟伺服器之間維護一個 TCP 長連線,當伺服器有資料時,實時推送到客戶端,也就是我們說的 Push。
從耗費的電量、流量和資料送達的及時性來說,Push 都會有明顯的優勢,但 Push 的實現和維護成本相對較高。在移動無線網路下維護長連線,相對也有一些技術上的難度。本文試圖給大家介紹一下我們
移動無線網路的特點
因為 IP v4 的 IP 量有限,運營商分配給手機終端的 IP 是運營商內網的 IP,手機要連線 Internet,就需要通過運營商的閘道器做一個網路地址轉換(Network Address Translation,NAT)。簡單的說運營商的閘道器需要維護一個外網 IP、埠到內網 IP、埠的對應關係,以確保內網的手機可以跟 Internet 的伺服器通訊。
圖片源自 cisco.com.
NAT 功能由圖中的 GGSN 模組實現。
大部分移動無線網路運營商都在鏈路一段時間沒有資料通訊時,會淘汰 NAT 表中的對應項,造成鏈路中斷。
Android 平臺上長連線的實現
為了不讓 NAT 表失效,我們需要定時的發心跳,以重新整理 NAT 表項,避免被淘汰。
Android 上定時執行任務常用的方法有2種,一種方法用 Timer,另一種是AlarmManager。
Timer
Android 的 Timer 類可以用來計劃需要迴圈執行的任務,Timer 的問題是它需要用 WakeLock 讓 CPU 保持喚醒狀態,這樣會大量消耗手機電量,大大減短手機待機時間。這種方式不能滿足我們的需求。
AlarmManager
AlarmManager 是 Android 系統封裝的用於管理 RTC 的模組,RTC (Real Time Clock) 是一個獨立的硬體時鐘,可以在 CPU 休眠時正常執行,在預設的時間到達時,通過中斷喚醒 CPU。
這意味著,如果我們用 AlarmManager 來定時執行任務,CPU 可以正常的休眠,只有在需要執行任務時醒來一段很短的時間。極光推送的 Android SDK 就是基於這種技術實現的。
伺服器設計
當有大量的手機終端需要與伺服器維持長連線時,對伺服器的設計會是一個很大的挑戰。
假設一臺伺服器維護10萬個長連線,當有1000萬用戶量時,需要有多達100臺的伺服器來維護這些使用者的長連線,這裡還不算用於做備份的伺服器,這將會是一個巨大的成本問題。那就需要我們儘可能提高單臺伺服器接入使用者的量,也就是業界已經討論很久了的 C10K 問題。
C2000K
針對這個問題,我們專門成立了一個專案,命名為C2000K,顧名思義,我們的目標是單機維持200萬個長連線。最終我們採用了多訊息迴圈、非同步非阻塞的模型,在一臺雙核、24G記憶體的伺服器上,實現峰值維持超過300萬個長連線。
後記
穩定維護長連線是推送平臺的一個基礎,極光推送團隊將會在這方面長期投入,以保證使用者能有效的節省電量、流量,同時資料能實時送達。
以上是極光推送官方的文章,但是看了之後不免有幾個疑問。
1)他們號稱最高峰值可以達到300W的長連線,但是活躍連結的處理最高是多少呢?
2)訊息的平均長度和限制各是多少?
3)訊息的及時性怎麼樣,延時是多少?
4)不知道現在,極光推送的使用者大概有多少,所以這個峰值是在生產環境,還是測試環境的數值?
5)我想不通的是為什麼,客戶端要用AlarmManager來做推送訊息的獲取?這個訊息獲取還及時嗎?鄙人結識android也有N載。
6)我感興趣的是,不是極光方案一個月推送了幾百萬條資料,而是幾秒鐘或者一分鐘可以處理多少。