Administrator User
03/21/2023 11:07 am
push：保持長連接（采用異步socket建立tcp連接），能實時無延遲的收到服務推送過來的消息。服務器的域名不會改變，客戶端能夠找到服務器，而手機客戶端是用的是移動運營商的網(wǎng)絡，若30分鐘（不同省份的運營商設置的可能不同，大部分運營商設置的是30分鐘）用戶不使用網(wǎng)絡，運營商可能把這個IP分配給其它的用戶，所以服務器一般不能實時的找到手機客戶端。所要要實現(xiàn)push，那么就要再服務器和手機客戶端建立長連接。由于手機客戶端需要連接服務器的連接很多，通常服務器要支持集群，畢竟一臺服務器要實現(xiàn)少沖突的分配長連接端口號，那么就最好不超過20000個連接。Push的好處是實時，維護通道的流量超少，只需要每30分鐘維護一次通道（為保持安全穩(wěn)定最好每14分鐘維護一次通道，就是發(fā)送一次請求，應用前后臺切換時有繼續(xù)讓線程僵死，所以應用前后切換時要維護一次通道）就可以。個推的透傳和蘋果APNS本質(zhì)就時push長連接，所以他們很省點，也較快。只所以它們沒有做到想象的那么實時是因為蘋果運營的手機是海量的，APNS連接也是海量的，消息的調(diào)度是很費時間的。個推的連接比蘋果少，但是再少也是海量級別的。所以個推付費能提高響應速度，但不能從根本上解決問題。想解決響應慢的問題只有你自己實現(xiàn)push長連接才更安全可能，畢竟是消息隊列調(diào)度問題還是連接問題你都實時的知道，可以用http請求的方案替代暫時連接異常。大部分郵箱和郵箱客戶端都不真正的支持push。微軟的exchange服務器的imap idle從實現(xiàn)機制上它是push。
個推的付費用戶也不是單獨給你搭建一個服務器，而是調(diào)整給你有消息隊列插隊的的特權。如：你是付費用戶，個推服務器有1億條消息在排隊，又一次性來1000萬條消息，其中有5000條消息是付費用戶的，那么這5000條消息肯定排列在1億條消息緊挨著的后面，至于這5000條消息的那么就靠誰先來誰就在前面了。若一條消息處理時間是x毫秒，那么你的等待時間最快就是1億＊x毫秒。所以你可以看到你的個推消息響應時間不但于你的應用使用量，也取決于這個時間段消息擁堵狀況，其它人使用個推發(fā)送消息的瞬時情況，個推的透傳可能發(fā)送很快（長連接大部分情況正常，無需建立通道的時間）但是它們大部分時間被耽誤在消息排隊上了。蘋果的APNS服務器也是一樣，只是沒有插隊的后門而已。自己在服務器上實現(xiàn)蘋果的APNS的通信功能，不但在要求這方面的技術，最關鍵的是它不支持類似的安卓手機遠程。而是個推集成了iOS和android這兩方面的遠程推送，所以你若想用不依賴于手機是否開啟都推送消息，最簡單的方法是使用個推。個推的APNS遠程遠沒有個推的透傳來的快，畢竟少了，在個推推送到蘋果APNS服務，在哪里排隊的時間，蘋果的連接可是海量的。個推的付費用戶對你的及時性有所提高，但是也沒有你想象的那么及時，必定要在個推那里進行大量消息排隊。自己實現(xiàn)push長連接，只排隊等待自己應用的消息和其它應用的消息無關，所以響應最快最準確，不用擔心消息丟失率的問題。
Pull:就是定時獲取。優(yōu)點是實現(xiàn)簡單，技術難點和異常很少。缺點不夠?qū)崟r，若獲取的時間間隔太短，設備的耗電量超快。還有一種實現(xiàn)方案是結(jié)合push和pull兩者的優(yōu)缺點，具有實時收到消息，實現(xiàn)簡單，耗電量界于兩者間。具體的是建立長連接，卻是10秒維護一次通道（服務器或客戶端不夠強大，沒有實現(xiàn)監(jiān)控兩者間異常的機制，才頻繁的發(fā)送心跳消息來代替這種異常監(jiān)控機制）。這種方案的優(yōu)點是基本做到了push的省去了發(fā)送請求才建立tcp通道的時間，達到了實時發(fā)送。它可以是異步socket也可以是同步socket。同步socket的優(yōu)點是實現(xiàn)簡單，異常較少；缺點是阻塞連接線程，異步socket的優(yōu)點是實時發(fā)現(xiàn)異常，不阻塞連接線程；缺點是實現(xiàn)相對復雜，異常較多。綜上所述push的實現(xiàn)方案最優(yōu)，pull的實現(xiàn)方案最簡單，兩者結(jié)合的方案是兩者的折中，具體實現(xiàn)那種實現(xiàn)方案，根據(jù)自己技術團隊的技術水平和項目緊急水平。金笛郵件系統(tǒng)支持推送方式，用最小的心跳包減少手機的電力消耗，同時又保證的消息的及時性。
