本篇文章為大家展示了服務(wù)器推送技術(shù)常用的三個(gè)解決方案分別是什么，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

創(chuàng)新互聯(lián)建站服務(wù)緊隨時(shí)代發(fā)展步伐，進(jìn)行技術(shù)革新和技術(shù)進(jìn)步，經(jīng)過10多年的發(fā)展和積累，已經(jīng)匯集了一批資深網(wǎng)站策劃師、設(shè)計(jì)師、專業(yè)的網(wǎng)站實(shí)施團(tuán)隊(duì)以及高素質(zhì)售后服務(wù)人員，并且完全形成了一套成熟的業(yè)務(wù)流程，能夠完全依照客戶要求對(duì)網(wǎng)站進(jìn)行成都網(wǎng)站制作、網(wǎng)站建設(shè)、建設(shè)、維護(hù)、更新和改版，實(shí)現(xiàn)客戶網(wǎng)站對(duì)外宣傳展示的首要目的，并為客戶企業(yè)品牌互聯(lián)網(wǎng)化提供全面的解決方案。

現(xiàn)在的app大多都有IM服務(wù)，在選擇上無外乎有兩種選擇：一是自建IM服務(wù)，二是用第三方的云服務(wù)。

暫不表第三方的云服務(wù)如何如何。
在自建IM服務(wù)上，每家公司的選擇往往逃不出下面的三個(gè)方案：
一是普通的http解決方案：app端通用http服務(wù)定時(shí)拉取消息，比例每隔3秒，雖然你和我可能都很鄙視這個(gè)方案，但確實(shí)有公司在用。
二是基于comet的解決方案(其實(shí)也是基于http）：app端通過comet服務(wù)拉取消息，即app端發(fā)起一次http請(qǐng)求，然后服務(wù)端檢查有無待接收的消息，如果有立即返回給app端，如果無，則把當(dāng)前http請(qǐng)示掛起多少多少秒，如30秒，在這30秒內(nèi)，如果他人給當(dāng)前的app用戶發(fā)送消息，服務(wù)端能在這30秒任意一點(diǎn)立即結(jié)束當(dāng)前掛起的http請(qǐng)求，并把消息一起返回給app端。此方案我熟悉的有icomet服務(wù)。
三是socket解決方案：app端通過socket與服務(wù)端通信，目前比較常用的服務(wù)端socket解決方案有nodejs，swoole，workerman等等。一般游戲類app服務(wù)端和app端采用此方案的比較多。
在耗電量和耗流量上第一個(gè)是最耗電的，第二個(gè)次之，第三個(gè)是最優(yōu)，但通過下面的設(shè)計(jì)方案，第二個(gè)方案和第三個(gè)在耗電量和耗流量上差別不大：主要理由是考慮到用戶在線的時(shí)長(zhǎng)及socket也要維持一套心跳服務(wù)上來推論。
前提條件：服務(wù)器端先維護(hù)一自增的消息id服務(wù)，不管是點(diǎn)聊消息和群聊消息，自增id不要用同一套（主要是基于兩者的消息量上來考慮），但所有用戶的點(diǎn)聊都用同一套自增的針點(diǎn)聊的消息id服務(wù)，所有用戶的群聊消息都用同一套自增的針群聊的消息id服務(wù)。這樣每發(fā)送的每一條消息都有一個(gè)唯一的id。注意：點(diǎn)聊消息和群聊消息都只存儲(chǔ)一條，哪怕一個(gè)群內(nèi)有2000個(gè)群成員，在數(shù)據(jù)庫中存儲(chǔ)的也只有一條消息記錄。
ASLINE的服務(wù)器提供全國(guó)最先進(jìn)、快速網(wǎng)絡(luò)設(shè)計(jì)及國(guó)際頂級(jí)設(shè)備 。
免備案、速度快，受到國(guó)內(nèi)站長(zhǎng)的歡迎。為各類用戶提供優(yōu)質(zhì)服務(wù)器，五星級(jí)式售后
免費(fèi)重裝系統(tǒng)，重啟，系統(tǒng)測(cè)試
app端直接請(qǐng)求icomet服務(wù)（注意：app不是直接請(qǐng)求php或java或nodejs或其它服務(wù)），每個(gè)app端用戶分配一個(gè)專用的icomet通道接收消息和提供長(zhǎng)連接服務(wù)，由icomet服務(wù)來負(fù)責(zé)維持與app端的長(zhǎng)連接。然后用php或java或其它語言負(fù)責(zé)往發(fā)送消息，還是以我熟悉的php為例，當(dāng)php端接收到發(fā)送消息請(qǐng)求時(shí)，在處理完相關(guān)業(yè)務(wù)邏輯后，往消息接收方的icomet通道中推送消息(包括消息唯一id和具體消息內(nèi)容等)，這樣如果app端用戶在線的話，且還維持著icomet的長(zhǎng)連接的話，就能立即接收到消息。app端接收到消息后處理完成后再發(fā)起下次長(zhǎng)連接請(qǐng)求（注意：app端接收到消息后沒有回調(diào)告訴服務(wù)器端已接收到，沒有回調(diào)，沒有回調(diào)！重要的事說三遍！）。
或許會(huì)有這樣的需求：要支持查看歷史消息的功能，即使是換終端設(shè)備了，也要能支持查看歷史消息。此時(shí)該如何進(jìn)一步優(yōu)化？
很簡(jiǎn)單：由于消息id都是自增的，只需要另開一個(gè)http消息查詢接口，按消息id的大小往前或往后查詢即可
app端調(diào)用php寫的接口實(shí)現(xiàn)發(fā)消息功能，php負(fù)責(zé)處理相關(guān)業(yè)務(wù)邏輯，并把消息寫入MongoDB和rabbitmq隊(duì)列中寫，然后由java與app端做的一套socket服務(wù)消費(fèi)rabbitmq隊(duì)列，來實(shí)現(xiàn)通知app端再調(diào)用php的消息查詢接口去拉取消息。
單臺(tái)服務(wù)器不可避免的問題
首先，要明白單臺(tái)服務(wù)器常見的問題，無非就是并發(fā)、大數(shù)據(jù)、單點(diǎn)
并發(fā)問題：一個(gè)時(shí)間點(diǎn)，同時(shí)有海量用戶去對(duì)服務(wù)器進(jìn)行訪問
大數(shù)據(jù)：例如海量數(shù)據(jù)的存儲(chǔ)和傳輸（性能方面的問題）
單點(diǎn)問題：例如只有一臺(tái)服務(wù)器，如果服務(wù)器出現(xiàn)故障了后果不堪設(shè)想。
針對(duì)以上問題，出現(xiàn)了以下幾種解決方式（后面我這個(gè)博客會(huì)持續(xù)更新，目前我就了解兩種）：
集群架構(gòu)思想：
可以處理并發(fā)問題和單點(diǎn)問題，集群的目標(biāo)是多臺(tái)服務(wù)器做相同的業(yè)務(wù)處理，可以緩解用戶的并發(fā)問題（也叫作負(fù)載均衡），同時(shí)因?yàn)槎嗯_(tái)服務(wù)器做相同的操作，所以一臺(tái)掛了并不影響另一臺(tái)的操作，所以可以避免單點(diǎn)問題。（以前使用apache做分布式集群負(fù)載均衡的前端服務(wù)器，現(xiàn)在流行Ngix做分布式集群負(fù)載均衡的前端服務(wù)器）。舉個(gè)例子，集群就像大家用的筆記本電腦和外接鍵盤的關(guān)系，筆記本的鍵盤壞了，可以用外接鍵盤，提供持續(xù)服務(wù)，或者筆記本鍵盤沒壞，用外接鍵盤可以更好的保護(hù)筆記本

今天為上與app配合做接口的經(jīng)驗(yàn)也有三年了，現(xiàn)在的app大多都有IM服務(wù)，在選擇上無外乎有兩種選擇：一是自建IM服務(wù)，二是用第三方的云服務(wù)。

暫不表第三方的云服務(wù)如何如何。
在自建IM服務(wù)上，每家公司的選擇往往逃不出下面的三個(gè)方案：
一是普通的http解決方案：app端通用http服務(wù)定時(shí)拉取消息，比例每隔3秒，雖然你和我可能都很鄙視這個(gè)方案，但確實(shí)有公司在用。
二是基于comet的解決方案(其實(shí)也是基于http）：app端通過comet服務(wù)拉取消息，即app端發(fā)起一次http請(qǐng)求，然后服務(wù)端檢查有無待接收的消息，如果有立即返回給app端，如果無，則把當(dāng)前http請(qǐng)示掛起多少多少秒，如30秒，在這30秒內(nèi)，如果他人給當(dāng)前的app用戶發(fā)送消息，服務(wù)端能在這30秒任意一點(diǎn)立即結(jié)束當(dāng)前掛起的http請(qǐng)求，并把消息一起返回給app端。此方案我熟悉的有icomet服務(wù)。
三是socket解決方案：app端通過socket與服務(wù)端通信，目前比較常用的服務(wù)端socket解決方案有nodejs，swoole，workerman等等。一般游戲類app服務(wù)端和app端采用此方案的比較多。
在耗電量和耗流量上第一個(gè)是最耗電的，第二個(gè)次之，第三個(gè)是最優(yōu)，但通過下面的設(shè)計(jì)方案，第二個(gè)方案和第三個(gè)在耗電量和耗流量上差別不大：主要理由是考慮到用戶在線的時(shí)長(zhǎng)及socket也要維持一套心跳服務(wù)上來推論。
前提條件：服務(wù)器端先維護(hù)一自增的消息id服務(wù)，不管是點(diǎn)聊消息和群聊消息，自增id不要用同一套（主要是基于兩者的消息量上來考慮），但所有用戶的點(diǎn)聊都用同一套自增的針點(diǎn)聊的消息id服務(wù)，所有用戶的群聊消息都用同一套自增的針群聊的消息id服務(wù)。這樣每發(fā)送的每一條消息都有一個(gè)唯一的id。注意：點(diǎn)聊消息和群聊消息都只存儲(chǔ)一條，哪怕一個(gè)群內(nèi)有2000個(gè)群成員，在數(shù)據(jù)庫中存儲(chǔ)的也只有一條消息記錄。
ASLINE的服務(wù)器提供全國(guó)最先進(jìn)、快速網(wǎng)絡(luò)設(shè)計(jì)及國(guó)際頂級(jí)設(shè)備 。
免備案、速度快，受到國(guó)內(nèi)站長(zhǎng)的歡迎。為各類用戶提供優(yōu)質(zhì)服務(wù)器，五星級(jí)式售后
免費(fèi)重裝系統(tǒng)，重啟，系統(tǒng)測(cè)試
app端直接請(qǐng)求icomet服務(wù)（注意：app不是直接請(qǐng)求php或java或nodejs或其它服務(wù)），每個(gè)app端用戶分配一個(gè)專用的icomet通道接收消息和提供長(zhǎng)連接服務(wù)，由icomet服務(wù)來負(fù)責(zé)維持與app端的長(zhǎng)連接。然后用php或java或其它語言負(fù)責(zé)往發(fā)送消息，還是以我熟悉的php為例，當(dāng)php端接收到發(fā)送消息請(qǐng)求時(shí)，在處理完相關(guān)業(yè)務(wù)邏輯后，往消息接收方的icomet通道中推送消息(包括消息唯一id和具體消息內(nèi)容等)，這樣如果app端用戶在線的話，且還維持著icomet的長(zhǎng)連接的話，就能立即接收到消息。app端接收到消息后處理完成后再發(fā)起下次長(zhǎng)連接請(qǐng)求（注意：app端接收到消息后沒有回調(diào)告訴服務(wù)器端已接收到，沒有回調(diào)，沒有回調(diào)！重要的事說三遍?。?。
或許會(huì)有這樣的需求：要支持查看歷史消息的功能，即使是換終端設(shè)備了，也要能支持查看歷史消息。此時(shí)該如何進(jìn)一步優(yōu)化？
很簡(jiǎn)單：由于消息id都是自增的，只需要另開一個(gè)http消息查詢接口，按消息id的大小往前或往后查詢即可
app端調(diào)用php寫的接口實(shí)現(xiàn)發(fā)消息功能，php負(fù)責(zé)處理相關(guān)業(yè)務(wù)邏輯，并把消息寫入mongodb和rabbitmq隊(duì)列中寫，然后由java與app端做的一套socket服務(wù)消費(fèi)rabbitmq隊(duì)列，來實(shí)現(xiàn)通知app端再調(diào)用php的消息查詢接口去拉取消息。
單臺(tái)服務(wù)器不可避免的問題
首先，要明白單臺(tái)服務(wù)器常見的問題，無非就是并發(fā)、大數(shù)據(jù)、單點(diǎn)
并發(fā)問題：一個(gè)時(shí)間點(diǎn)，同時(shí)有海量用戶去對(duì)服務(wù)器進(jìn)行訪問
大數(shù)據(jù)：例如海量數(shù)據(jù)的存儲(chǔ)和傳輸（性能方面的問題）
單點(diǎn)問題：例如只有一臺(tái)服務(wù)器，如果服務(wù)器出現(xiàn)故障了后果不堪設(shè)想。
針對(duì)以上問題，出現(xiàn)了以下幾種解決方式（后面我這個(gè)博客會(huì)持續(xù)更新，目前我就了解兩種）：
集群架構(gòu)思想：
可以處理并發(fā)問題和單點(diǎn)問題，集群的目標(biāo)是多臺(tái)服務(wù)器做相同的業(yè)務(wù)處理，可以緩解用戶的并發(fā)問題（也叫作負(fù)載均衡），同時(shí)因?yàn)槎嗯_(tái)服務(wù)器做相同的操作，所以一臺(tái)掛了并不影響另一臺(tái)的操作，所以可以避免單點(diǎn)問題。（以前使用apache做分布式集群負(fù)載均衡的前端服務(wù)器，現(xiàn)在流行Ngix做分布式集群負(fù)載均衡的前端服務(wù)器）。舉個(gè)例子，集群就像大家用的筆記本電腦和外接鍵盤的關(guān)系，筆記本的鍵盤壞了，可以用外接鍵盤，提供持續(xù)服務(wù)，或者筆記本鍵盤沒壞，用外接鍵盤可以更好的保護(hù)筆記本鍵盤不會(huì)加速衰老
集群的種類：
高可用集群：主要是為了保障用戶的應(yīng)用程序持久、不簡(jiǎn)單提供服務(wù)
負(fù)載均衡集群：可以做到把一個(gè)高負(fù)荷的應(yīng)用分散到多個(gè)節(jié)點(diǎn)共同完成，適合業(yè)務(wù)繁忙、大負(fù)荷訪問的系統(tǒng)
科學(xué)計(jì)算集群（HPC集群）：提供單個(gè)計(jì)算機(jī)不能提供的強(qiáng)大計(jì)算能力，追求與綜合性能
分布式架構(gòu)思想：
和集群的實(shí)現(xiàn)不同，集群是多臺(tái)服務(wù)器集中實(shí)現(xiàn)同一種業(yè)務(wù)，而分布式則是把多臺(tái)服務(wù)器集中在一起，每臺(tái)服務(wù)器實(shí)現(xiàn)不同的業(yè)務(wù)，做不同的事情，并且缺一不可，如果一臺(tái)服務(wù)器掛了，就有可能影響整個(gè)服務(wù)器的功能的運(yùn)行。
分布式集群綜合架構(gòu)思想：
就如上面所述，集群有集群的好處，分布式有分布式的好處，可否做到兩個(gè)架構(gòu)進(jìn)行合并呢，當(dāng)然可以。我們可以讓分布式的每一個(gè)節(jié)點(diǎn)都進(jìn)行集群，這種架構(gòu)通常叫做分布式集群架構(gòu)。

鍵盤不會(huì)加速衰老
集群的種類：
高可用集群：主要是為了保障用戶的應(yīng)用程序持久、不簡(jiǎn)單提供服務(wù)
負(fù)載均衡集群：可以做到把一個(gè)高負(fù)荷的應(yīng)用分散到多個(gè)節(jié)點(diǎn)共同完成，適合業(yè)務(wù)繁忙、大負(fù)荷訪問的系統(tǒng)
科學(xué)計(jì)算集群（HPC集群）：提供單個(gè)計(jì)算機(jī)不能提供的強(qiáng)大計(jì)算能力，追求與綜合性能
分布式架構(gòu)思想：
和集群的實(shí)現(xiàn)不同，集群是多臺(tái)服務(wù)器集中實(shí)現(xiàn)同一種業(yè)務(wù)，而分布式則是把多臺(tái)服務(wù)器集中在一起，每臺(tái)服務(wù)器實(shí)現(xiàn)不同的業(yè)務(wù)，做不同的事情，并且缺一不可，如果一臺(tái)服務(wù)器掛了，就有可能影響整個(gè)服務(wù)器的功能的運(yùn)行。
分布式集群綜合架構(gòu)思想：
就如上面所述，集群有集群的好處，分布式有分布式的好處，可否做到兩個(gè)架構(gòu)進(jìn)行合并呢，當(dāng)然可以。我們可以讓分布式的每一個(gè)節(jié)點(diǎn)都進(jìn)行集群，這種架構(gòu)通常叫做分布式集群架構(gòu)。

上述內(nèi)容就是服務(wù)器推送技術(shù)常用的三個(gè)解決方案分別是什么，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。