APP聊天功能開發(fā)怎樣處理Radis協(xié)議格式，深圳APP開發(fā)公司在前面的文章中介紹過開發(fā)APP聊天功能MySQL通信協(xié)議的流程與技巧，移動網(wǎng)絡(luò)時代我們幾乎所有的APP項目都離不開在線溝通，基于此因素，博納網(wǎng)絡(luò)本文繼續(xù)分享APP聊天功能開發(fā)時怎樣高效Radis協(xié)議格式。
Redis協(xié)議是以CR LF (CRLF)結(jié)尾，協(xié)議格式如下。
*參數(shù)個數(shù)CR LF
S第一個參數(shù)的字符串占用字節(jié)數(shù)CR LF
參數(shù)數(shù)據(jù)CR LF
....................
S第N個參數(shù)的字符串占用字節(jié)數(shù)字CR LF
參數(shù)數(shù)據(jù)CR LF
Redis命令“set name jeff”根據(jù)Redis協(xié)議可表示如下。
*3\r\n$3\nsete\n$4\rnname\r\n$4\r\njeff\r\n
根據(jù)公開的資料，陌陌是采用了和Redis協(xié)議相似的協(xié)議作為陌陌的通信協(xié)議。
根據(jù)Redis協(xié)議的格式，程序也很容易完整地獲取個數(shù)據(jù)包的所有數(shù)據(jù)，APP開發(fā)愛好者如果需要開發(fā)私有協(xié)議，可以上面介紹的兩種協(xié)議格式作為模板，打造屬于自己的協(xié)議
由于移動互聯(lián)網(wǎng)的弱網(wǎng)絡(luò)性，經(jīng)常會出現(xiàn)丟包的情況（即客戶端收不到服務(wù)器發(fā)送的數(shù)據(jù)），對于推送、聊天這類應(yīng)用來說，丟包后有下面兩個問題需要處理。
·怎么確定客戶端是否接收到消息7
·怎么確定需要重發(fā)哪些消息？
深圳APP開發(fā)公司下面先介紹基于隊列的協(xié)議在解決上面兩個問題上的缺點，APP開發(fā)公司現(xiàn)在介紹新式的協(xié)議是如何有效解決以上的兩個問題
1．聊天功能基于隊列的消息協(xié)議
傳統(tǒng)的IM協(xié)議一般是基于隊列的消息發(fā)送和反饋機制。假設(shè)服務(wù)器中要發(fā)送的消息隊列如下。
服務(wù)器按順序把消息隊列中的消息依次發(fā)送給客戶端，當客戶端收到消息后給服務(wù)端發(fā)送“確認收到”的應(yīng)答。如果過了一段時間服務(wù)器還沒收到客戶端的應(yīng)答，就重發(fā)該條消息。服務(wù)器與客戶端之間的消息交互過程如圖9-10所示
。
APP開發(fā)聊天功能隊列協(xié)議處理示意圖9-10基于隊列的服務(wù)器和App的消B交互過程
這種方式有下面兩個問題：
·如果客戶端已收到消息并且發(fā)送了“確認收到”的應(yīng)答，但由于網(wǎng)絡(luò)中斷等原因造成服務(wù)器收不到應(yīng)答，這樣服務(wù)器就會重發(fā)該消息
導(dǎo)致客戶端收到重復(fù)的消息。
·由于移動互聯(lián)網(wǎng)的弱網(wǎng)絡(luò)性，每條消息都需要應(yīng)答的方式極其費時，服務(wù)器要維護每個消息的狀態(tài)也容易出錯。這種方式對網(wǎng)絡(luò)的要求比較高，適用于基于網(wǎng)線、Wi-Fi等網(wǎng)絡(luò)信號比較強的情況
2.APP開發(fā)聊天功能基于版本號的消息協(xié)議
服務(wù)器上消息按照如下的結(jié)構(gòu)存儲，每個消息有一個自增不重復(fù)的版本號，
服務(wù)器和App之間的消息交互，基于版本號的方式如圖9-11所示。
APP開發(fā)聊天功能消息協(xié)議處理方法示意圖9-11基于版奉號的服務(wù)器和-App之間的交互過程
在圖9-11中，當服務(wù)器準備推送消息給App時，服務(wù)器向App發(fā)送“消息推送”消息，App收到這個信息向服務(wù)器返回“消息同步”消息（附上最后收到的消息版本號），服務(wù)器根據(jù)這個版本號，把大于該版本號的所有消息按照版本號依次推送給App。
假設(shè)在圖9-11中．App收到消息(2.msg2)后網(wǎng)絡(luò)中斷了，等網(wǎng)絡(luò)恢復(fù)后App向服務(wù)端發(fā)送“消息同步”信號（默認情況下App連上網(wǎng)絡(luò)后發(fā)送這個信號到服務(wù)器同步消息）．附上最后收到的版本號2，服務(wù)器把版本號大于2的所有消息再次推送到App。
這種交互方式最大的好處是減少了交互的次數(shù)，而且依賴客戶端維護消息版本號的方式保證服務(wù)器上的消息都能同步到客戶端，不會丟失消息。據(jù)公開的資料，陌陌和微信采用了類似上面所描述的基于版本號的消息協(xié)議
聊天還有個常見的功能：發(fā)送圖片、聲音等文件。APP開發(fā)公司建議是在聊天中采用純文本的方案發(fā)送這些數(shù)據(jù)，流程如下。
(1)假設(shè)用戶a向用戶b發(fā)送了張圖片，發(fā)送前App先把該圖片上傳到文件服務(wù)器后得到個可訪問的URL: http://file. test. com/l.Jpg.
(2) App聊天模塊對接收到的下面幾種文本類型的數(shù)據(jù)做不同的處理，如下所示。
發(fā)送圖片聲音等文件流程如圖9-12所示。
APP聊天功能開發(fā)經(jīng)驗示意圖9-12發(fā)送圖片聲音等文件流程
采用純文本傳輸圖片、聲音等消息的好處如下：
（1）無論是App端或者是聊天后臺，只處理又本的話都比較簡單
（2）把文件放在文件服務(wù)中，可以統(tǒng)優(yōu)化文件的性能（例如使用文件云存儲或者CDN），不需要單獨優(yōu)化聊天相關(guān)的文件。好了，APP開發(fā)公司本文關(guān)于聊天功能開發(fā)時對于消息隊列協(xié)議處理的流程與經(jīng)驗本文就分享到這里。謝謝關(guān)注，博納網(wǎng)絡(luò)編輯整理。
