服務器推送技術常用的三個解決方案分別是什么

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

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

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

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

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

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

上述內(nèi)容就是服務器推送技術常用的三個解決方案分別是什么，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業(yè)資訊頻道。