移動(dòng)互聯(lián)網(wǎng)應(yīng)用現(xiàn)狀


因?yàn)槭謾C(jī)平臺(tái)本身、電量、網(wǎng)絡(luò)流量的限制，移動(dòng)互聯(lián)網(wǎng)應(yīng)用在設(shè)計(jì)上跟傳統(tǒng) PC 上的應(yīng)用很大不一樣，需要根據(jù)手機(jī)本身的特點(diǎn)，盡量的節(jié)省電量和流量，同時(shí)又要盡可能的保證數(shù)據(jù)能及時(shí)到達(dá)客戶端。


為了解決數(shù)據(jù)同步的問題，在手機(jī)平臺(tái)上，常用的方法有2種。一種是定時(shí)去服務(wù)器上查詢數(shù)據(jù)，也叫Polling，還有一種手機(jī)跟服務(wù)器之間維護(hù)一個(gè) TCP 長(zhǎng)連接，當(dāng)服務(wù)器有數(shù)據(jù)時(shí)，實(shí)時(shí)推送到客戶端，也就是我們說的 Push。


從耗費(fèi)的電量、流量和數(shù)據(jù)送達(dá)的及時(shí)性來說，Push 都會(huì)有明顯的優(yōu)勢(shì)，但 Push 的實(shí)現(xiàn)和維護(hù)成本相對(duì)較高。在移動(dòng)無線網(wǎng)絡(luò)下維護(hù)長(zhǎng)連接，相對(duì)也有一些技術(shù)上的難度。本文試圖給大家介紹一下我們極光推送在 Android 平臺(tái)上是如何維護(hù)長(zhǎng)連接。


移動(dòng)無線網(wǎng)絡(luò)的特點(diǎn)


因?yàn)?IP v4 的 IP 量有限，運(yùn)營(yíng)商分配給手機(jī)終端的 IP 是運(yùn)營(yíng)商內(nèi)網(wǎng)的 IP，手機(jī)要連接 Internet，就需要通過運(yùn)營(yíng)商的網(wǎng)關(guān)做一個(gè)網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation，NAT）。簡(jiǎn)單的說運(yùn)營(yíng)商的網(wǎng)關(guān)需要維護(hù)一個(gè)外網(wǎng) IP、端口到內(nèi)網(wǎng) IP、端口的對(duì)應(yīng)關(guān)系，以確保內(nèi)網(wǎng)的手機(jī)可以跟 Internet 的服務(wù)器通訊。


大部分移動(dòng)無線網(wǎng)絡(luò)運(yùn)營(yíng)商都在鏈路一段時(shí)間沒有數(shù)據(jù)通訊時(shí)，會(huì)淘汰 NAT 表中的對(duì)應(yīng)項(xiàng)，造成鏈路中斷。


Android 平臺(tái)上長(zhǎng)連接的實(shí)現(xiàn)


為了不讓 NAT 表失效，我們需要定時(shí)的發(fā)心跳，以刷新 NAT 表項(xiàng)，避免被淘汰。


Android 上定時(shí)運(yùn)行任務(wù)常用的方法有2種，一種方法用 Timer，另一種是AlarmManager。


Timer


Android 的 Timer 類可以用來計(jì)劃需要循環(huán)執(zhí)行的任務(wù)，Timer 的問題是它需要用 WakeLock 讓 CPU 保持喚醒狀態(tài)，這樣會(huì)大量消耗手機(jī)電量，大大減短手機(jī)待機(jī)時(shí)間。這種方式不能滿足我們的需求。


AlarmManager


AlarmManager 是 Android 系統(tǒng)封裝的用于管理 RTC 的模塊，RTC (Real Time Clock) 是一個(gè)獨(dú)立的硬件時(shí)鐘，可以在 CPU 休眠時(shí)正常運(yùn)行，在預(yù)設(shè)的時(shí)間到達(dá)時(shí)，通過中斷喚醒 CPU。


這意味著，如果我們用 AlarmManager 來定時(shí)執(zhí)行任務(wù)，CPU 可以正常的休眠，只有在需要運(yùn)行任務(wù)時(shí)醒來一段很短的時(shí)間。極光推送的 Android SDK 就是基于這種技術(shù)實(shí)現(xiàn)的。


服務(wù)器設(shè)計(jì)


當(dāng)有大量的手機(jī)終端需要與服務(wù)器維持長(zhǎng)連接時(shí)，對(duì)服務(wù)器的設(shè)計(jì)會(huì)是一個(gè)很大的挑戰(zhàn)。


假設(shè)一臺(tái)服務(wù)器維護(hù)10萬個(gè)長(zhǎng)連接，當(dāng)有1000萬用戶量時(shí)，需要有多達(dá)100臺(tái)的服務(wù)器來維護(hù)這些用戶的長(zhǎng)連接，這里還不算用于做備份的服務(wù)器，這將會(huì)是一個(gè)巨大的成本問題。那就需要我們盡可能提高單臺(tái)服務(wù)器接入用戶的量，也就是業(yè)界已經(jīng)討論很久了的 C10K 問題。


C2000K


針對(duì)這個(gè)問題，我們專門成立了一個(gè)項(xiàng)目，命名為C2000K，顧名思義，我們的目標(biāo)是單機(jī)維持200萬個(gè)長(zhǎng)連接。最終我們采用了多消息循環(huán)、異步非阻塞的模型，在一臺(tái)雙核、24G內(nèi)存的服務(wù)器上，實(shí)現(xiàn)峰值維持超過300萬個(gè)長(zhǎng)連接。


后記


穩(wěn)定維護(hù)長(zhǎng)連接是推送平臺(tái)的一個(gè)基礎(chǔ)，極光推送團(tuán)隊(duì)將會(huì)在這方面長(zhǎng)期投入，以保證用戶能有效的節(jié)省電量、流量，同時(shí)數(shù)據(jù)能實(shí)時(shí)送達(dá)。


以上是極光推送官方的文章，但是看了之后不免有幾個(gè)疑問。


1）他們號(hào)稱最高峰值可以達(dá)到300W的長(zhǎng)連接，但是活躍鏈接的處理最高是多少呢？


2）消息的平均長(zhǎng)度和限制各是多少？


3）消息的及時(shí)性怎么樣，延時(shí)是多少？


4）不知道現(xiàn)在，極光推送的用戶大概有多少，所以這個(gè)峰值是在生產(chǎn)環(huán)境，還是測(cè)試環(huán)境的數(shù)值？


5）我想不通的是為什么，客戶端要用AlarmManager來做推送消息的獲取？這個(gè)消息獲取還及時(shí)嗎？鄙人結(jié)識(shí)android也有N載。


6）我感興趣的是，不是極光方案一個(gè)月推送了幾百萬條數(shù)據(jù)，而是幾秒鐘或者一分鐘可以處理多少。

總結(jié)

以上是生活随笔為你收集整理的移动互联网推送的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。