移动互联网推送
移動(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ù),而是幾秒鐘或者一分鐘可以處理多少。
因?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é)
- 上一篇: 项目管理知识体系
- 下一篇: maven如何将本地jar安装到本地仓库