Jack Jiang

          我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
          posts - 499, comments - 13, trackbacks - 0, articles - 1

          1、引言

          老讀者應(yīng)該還記得我在去年國慶節(jié)前分享過一篇《技術(shù)干貨:從零開始,教你設(shè)計(jì)一個百萬級的消息推送系統(tǒng)》,雖然我在文中有貼一些偽代碼,依然有些朋友希望能直接分享一些可以運(yùn)行的源碼。好吧,質(zhì)疑我窮我無話可說(因?yàn)槭钦娓F。。),懷疑我擼碼的能力那是絕對不行,所以這次準(zhǔn)備拉起鍵盤大干一場——徒手?jǐn)]套分布式IM出來!^_^!

          本文記錄了我開發(fā)的一款面向IM學(xué)習(xí)者的 IM系統(tǒng)——CIM(全稱:CROSS-IM),同時提供了一些組件幫助開發(fā)者構(gòu)建一款屬于自己可水平擴(kuò)展的 IM。

          通過學(xué)習(xí)本文和CIM代碼,你可以獲得以下知識:

          1)如何從頭開發(fā)一套IM(CIM的客戶有點(diǎn)弱,見諒見諒);

          2)如何設(shè)計(jì)分布式的IM架構(gòu);

          3)如何將你的分布式IM架構(gòu)用代碼和相關(guān)技術(shù)實(shí)現(xiàn)出來。

          本文配套的CIM源碼地址:

          主要鏡像:https://github.com/crossoverJie/cim

          備用鏡像:https://github.com/52im/cim

          以下文章與本文類似或相關(guān),同樣有助于您的IM開發(fā)入門:

          * 友情提示:閱讀本文和CIM源碼,需要您具備一定的網(wǎng)絡(luò)編程、IM理論等知識等,如果您還不具備這些,請先閱讀《新手入門一篇就夠:從零開發(fā)移動端IM》,完全來的及!

          學(xué)習(xí)交流:

          - 即時通訊/推送技術(shù)開發(fā)交流5群:215477170[推薦]

          - 移動端IM開發(fā)入門文章:《新手入門一篇就夠:從零開發(fā)移動端IM

          (本文同步發(fā)布于:http://www.52im.net/thread-2775-1-1.html

          2、關(guān)于作者

          crossoverJie(陳杰): 90后,畢業(yè)于重慶信息工程學(xué)院,現(xiàn)供職于重慶豬八戒網(wǎng)絡(luò)有限公司。

          3、運(yùn)行演示

          本次特地錄了兩段視頻演示(群聊、私聊),點(diǎn)擊下方鏈接可以查看視頻版 Demo。

          CIM 私聊視頻演示:https://www.bilibili.com/video/av39405821

          CIM 群聊視頻演示:https://www.bilibili.com/video/av39405501

          4、架構(gòu)設(shè)計(jì)

          下面來看看具體的架構(gòu)設(shè)計(jì):

          架構(gòu)說明:

          1)CIM 中的各個組件均采用 SpringBoot 構(gòu)建;

          2)采用 Netty + Google Protocol Buffer 構(gòu)建底層通信;

          3)Redis 存放各個客戶端的路由信息、賬號信息、在線狀態(tài)等;

          4)Zookeeper 用于 IM-server 服務(wù)的注冊與發(fā)現(xiàn)。

          整體主要由以下模塊組成:

          1)cim-server——IM 服務(wù)端:用于接收 client 連接、消息透傳、消息推送等功能。支持集群部署;

          2)cim-forward-route——消息路由服務(wù)器:用于處理消息路由、消息轉(zhuǎn)發(fā)、用戶登錄、用戶下線以及一些運(yùn)營工具(獲取在線用戶數(shù)等);

          3)cim-client——IM 客戶端:給用戶使用的消息終端,一個命令即可啟動并向其他人發(fā)起通訊(群聊、私聊);同時內(nèi)置了一些常用命令方便使用。

          5、邏輯流程圖

          整體的流程也比較簡單,流程圖如下:

          流程解釋如下:

          1)客戶端向 route 發(fā)起登錄;

          2)登錄成功從 Zookeeper 中選擇可用 IM-server 返回給客戶端,并保存登錄、路由信息到 Redis;

          3)客戶端向 IM-server 發(fā)起長連接,成功后保持心跳;

          4)客戶端下線時通過 route 清除狀態(tài)信息。

          所以當(dāng)我們自己部署時需要以下步驟:

          1)搭建基礎(chǔ)中間件 RedisZookeeper

          2)部署 cim-server,這是真正的 IM 服務(wù)器,為了滿足性能需求所以支持水平擴(kuò)展,只需要注冊到同一個 Zookeeper 即可;

          3)部署 cim-forward-route,這是路由服務(wù)器,所有的消息都需要經(jīng)過它。由于它是無狀態(tài)的,所以也可以利用 Nginx 代理提高可用性;

          4)cim-client 真正面向用戶的客戶端;啟動之后會自動連接 IM 服務(wù)器便可以在控制臺收發(fā)消息了。

          更多使用介紹可以參考快速啟動

          接下來各章將重點(diǎn)看看具體的詳細(xì)設(shè)計(jì)實(shí)現(xiàn),比如群聊、私聊消息如何流轉(zhuǎn);IM 服務(wù)端負(fù)載均衡;服務(wù)如何注冊發(fā)現(xiàn)等等。

          6、IM 服務(wù)端

          先來看看服務(wù)端:主要是實(shí)現(xiàn)客戶端上下線、消息下發(fā)等功能。

          首先是服務(wù)啟動:

          由于是在 SpringBoot 中搭建的,所以在應(yīng)用啟動時需要啟動 Netty 服務(wù)。

          從 pipline 中可以看出使用了 Protobuf 的編解碼(具體報(bào)文在客戶端中分析,相關(guān)知識請見:《Protobuf通信協(xié)議詳解:代碼演示、詳細(xì)原理介紹等》)。

          7、注冊發(fā)現(xiàn)

          需要滿足 IM 服務(wù)端的水平擴(kuò)展需求,所以 cim-server 是需要將自身數(shù)據(jù)發(fā)布到注冊中心的。這里參考之前分享的《搞定服務(wù)注冊與發(fā)現(xiàn)》有具體介紹。

          所以在應(yīng)用啟動成功后需要將自身數(shù)據(jù)注冊到 Zookeeper 中:

          最主要的目的就是將當(dāng)前應(yīng)用的 ip + cim-server-port+ http-port 注冊上去:

          上圖是我在演示環(huán)境中注冊的兩個 cim-server 實(shí)例(由于在一臺服務(wù)器,所以只是端口不同)。這樣在客戶端(監(jiān)聽這個 Zookeeper 節(jié)點(diǎn))就能實(shí)時的知道目前可用的服務(wù)信息。

          8、登錄

          當(dāng)客戶端請求 cim-forward-route 中的登錄接口(詳見下文)做完業(yè)務(wù)驗(yàn)證(就相當(dāng)于日常登錄其他網(wǎng)站一樣)之后,客戶端會向服務(wù)端發(fā)起一個長連接。

          如之前的流程所示:

          這時客戶端會發(fā)送一個特殊報(bào)文,表明當(dāng)前是登錄信息。服務(wù)端收到后就需要將該客戶端的 userID 和當(dāng)前 Channel 通道關(guān)系保存起來。

          同時也緩存了用戶的信息,也就是 userID 和 用戶名。

          9、離線消息

          當(dāng)客戶端斷線后也需要將剛才緩存的信息清除掉。

          同時也需要調(diào)用 route 接口清除相關(guān)信息(具體接口看下文)。

          10、IM 路由

          從架構(gòu)圖中可以看出,路由層是非常重要的一環(huán);它提供了一系列的 HTTP 服務(wù)承接了客戶端和服務(wù)端。

          目前主要是以下幾個接口。

          10.1 注冊接口

          由于每一個客戶端都是需要登錄才能使用的,所以第一步自然是注冊。

          這里就設(shè)計(jì)的比較簡單,直接利用 Redis 來存儲用戶信息;用戶信息也只有 ID 和 userName 而已。只是為了方便查詢在 Redis 中的 KV 又反過來存儲了一份 VK,這樣 ID 和 userName 都必須唯一。

          10.2 登錄接口

          這里的登錄和 cim-server 中的登錄不一樣,具有業(yè)務(wù)性質(zhì):

          具體的流程:

          1)登錄成功之后需要判斷是否是重復(fù)登錄(一個用戶只能運(yùn)行一個客戶端);

          2)登錄成功后需要從 Zookeeper 中獲取服務(wù)列表(cim-server)并根據(jù)某種算法選擇一臺服務(wù)返回給客戶端;

          3)登錄成功之后還需要保存路由信息,也就是當(dāng)前用戶分配的服務(wù)實(shí)例保存到 Redis 中。

          為了實(shí)現(xiàn)只能一個用戶登錄,使用了 Redis 中的 set 來保存登錄信息;利用 userID 作為 key ,重復(fù)的登錄就會寫入失敗。


          類似于 Java 中的 HashSet,只能去重保存。

          獲取一臺可用的路由實(shí)例也比較簡單:

          1)先從 Zookeeper 獲取所有的服務(wù)實(shí)例做一個內(nèi)部緩存;

          2)輪詢選擇一臺服務(wù)器(目前只有這一種算法,后續(xù)會新增)。

          當(dāng)然要獲取 Zookeeper 中的服務(wù)實(shí)例前自然是需要監(jiān)聽 cim-server 之前注冊上去的那個節(jié)點(diǎn)。

          具體代碼如下:

          也是在應(yīng)用啟動之后監(jiān)聽 Zookeeper 中的路由節(jié)點(diǎn),一旦發(fā)生變化就會更新內(nèi)部緩存。這里使用的是 Guava 的 cache,它基于 ConcurrentHashMap,所以可以保證清除、新增緩存的原子性。

          10.3 群聊接口

          這是一個真正發(fā)消息的接口,實(shí)現(xiàn)的效果就是其中一個客戶端發(fā)消息,其余所有客戶端都能收到!流程肯定是客戶端發(fā)送一條消息到服務(wù)端,服務(wù)端收到后在上文介紹的 SessionSocketHolder 中遍歷所有 Channel(通道)然后下發(fā)消息即可。服務(wù)端是單機(jī)倒也可以,但現(xiàn)在是集群設(shè)計(jì)。所以所有的客戶端會根據(jù)之前的輪詢算法分配到不同的 cim-server 實(shí)例中。

          因此就需要路由層來發(fā)揮作用了。

          路由接口收到消息后首先遍歷出所有的客戶端和服務(wù)實(shí)例的關(guān)系。

          路由關(guān)系在 Redis 中的存放如下:

          由于 Redis 單線程的特質(zhì),當(dāng)數(shù)據(jù)量大時;一旦使用 keys 匹配所有 cim-route:* 數(shù)據(jù),會導(dǎo)致 Redis 不能處理其他請求。所以這里改為使用 scan 命令來遍歷所有的 cim-route:*。

          接著會挨個調(diào)用每個客戶端所在的服務(wù)端的 HTTP 接口用于推送消息。

          在 cim-server 中的實(shí)現(xiàn)如下:

          cim-server 收到消息后會在內(nèi)部緩存中查詢該 userID 的通道,接著只需要發(fā)消息即可。

          10.4 在線用戶接口

          這是一個輔助接口,可以查詢出當(dāng)前在線用戶信息。

          實(shí)現(xiàn)也很簡單,也就是查詢之前保存 ”用戶登錄狀態(tài)的那個去重 set “即可。

          10.5 私聊接口

          之所以說獲取在線用戶是一個輔助接口,其實(shí)就是用于輔助私聊使用的。一般我們使用私聊的前提肯定得知道當(dāng)前哪些用戶在線,接著你才會知道你要和誰進(jìn)行私聊。

          類似于這樣:

          在我們這個場景中,私聊的前提就是需要獲得在線用戶的 userID:

          所以私聊接口在收到消息后需要查詢到接收者所在的 cim-server 實(shí)例信息,后續(xù)的步驟就和群聊一致了。調(diào)用接收者所在實(shí)例的 HTTP 接口下發(fā)信息。只是群聊是遍歷所有的在線用戶,私聊只發(fā)送一個的區(qū)別。

          10.6 下線接口

          一旦客戶端下線,我們就需要將之前存放在 Redis 中的一些信息刪除掉(路由信息、登錄狀態(tài))。

          11、IM 客戶端

          客戶端中的一些邏輯其實(shí)在上文已經(jīng)談到一些了。

          11.1 登錄

          第一步也就是登錄,需要在啟動時調(diào)用 route 的登錄接口,獲得 cim-server 信息再創(chuàng)建連接。

          登錄過程中 route 接口會判斷是否為重復(fù)登錄,重復(fù)登錄則會直接退出程序。

          接下來是利用 route 接口返回的 cim-server 實(shí)例信息(ip+port)創(chuàng)建連接。最后一步就是發(fā)送一個登錄標(biāo)志的信息到服務(wù)端,讓它保持客戶端和 Channel 的關(guān)系。

          11.2 自定義協(xié)議

          上文提到的一些登錄報(bào)文、真正的消息報(bào)文這些其實(shí)都是在我們自定義協(xié)議中可以區(qū)別出來的。由于是使用 Google Protocol Buffer 編解碼,所以先看看原始格式。

          其實(shí)這個協(xié)議中目前一共就三個字段:

          1)requestId 可以理解為 userId;

          2)reqMsg 就是真正的消息;

          3)type 也就是上文提到的消息類別。

          目前主要是三種類型,分別對應(yīng)不同的業(yè)務(wù):

          11.3 心跳

          為了保持客戶端和服務(wù)端的連接,每隔一段時間沒有發(fā)送消息都需要自動的發(fā)送心跳。

          目前的策略是每隔一分鐘就是發(fā)送一個心跳包到服務(wù)端:

          這樣服務(wù)端每隔一分鐘沒有收到業(yè)務(wù)消息時就會收到 ping 的心跳包:

          11.4 內(nèi)置命令

          客戶端也內(nèi)置了一些基本命令來方便使用。

          比如輸入 :q 就會退出客戶端,同時會關(guān)閉一些系統(tǒng)資源。

          當(dāng)輸入 :olu(onlineUser 的簡寫)就會去調(diào)用 route 的獲取所有在線用戶接口。

          11.5 群聊

          群聊的使用非常簡單,只需要在控制臺輸入消息回車即可。這時會去調(diào)用 route 的群聊接口。

          11.6 私聊

          私聊也是同理,但前提是需要觸發(fā)關(guān)鍵字;使用 userId;;消息內(nèi)容 這樣的格式才會給某個用戶發(fā)送消息,所以一般都需要先使用 

          lu 命令獲取所以在線用戶才方便使用。

          11.7 消息回調(diào)

          為了滿足一些定制需求,比如消息需要保存之類的。所以在客戶端收到消息之后會回調(diào)一個接口,在這個接口中可以自定義實(shí)現(xiàn)。

          因此先創(chuàng)建了一個 caller 的 bean,這個 bean 中包含了一個 CustomMsgHandleListener 接口,需要自行處理只需要實(shí)現(xiàn)此接口即可。

          11.8 自定義界面

          由于我自己不怎么會寫界面,但保不準(zhǔn)有其他大牛會寫。所以客戶端中的群聊、私聊、獲取在線用戶、消息回調(diào)等業(yè)務(wù)(以及之后的業(yè)務(wù))都是以接口形式提供。

          也方便后面做頁面集成,只需要調(diào)這些接口就行了;具體實(shí)現(xiàn)不用怎么關(guān)心。

          12、本文小結(jié)

          cim 目前只是第一版,BUG 多,功能少(只拉了幾個群友做了測試);不過后續(xù)還會接著完善,至少這一版會給那些沒有相關(guān)經(jīng)驗(yàn)的朋友帶來一些思路。

          后續(xù)計(jì)劃:

          附錄:更多IM相關(guān)文章

          [1] 有關(guān)IM代碼實(shí)踐的文章:
          自已開發(fā)IM有那么難嗎?手把手教你自擼一個Andriod版簡易IM (有源碼)
          一種Android端IM智能心跳算法的設(shè)計(jì)與實(shí)現(xiàn)探討(含樣例代碼)
          手把手教你用Netty實(shí)現(xiàn)網(wǎng)絡(luò)通信程序的心跳機(jī)制、斷線重連機(jī)制
          詳解Netty的安全性:原理介紹、代碼演示(上篇)
          詳解Netty的安全性:原理介紹、代碼演示(下篇)
          微信本地?cái)?shù)據(jù)庫破解版(含iOS、Android),僅供學(xué)習(xí)研究 [附件下載]
          Java NIO基礎(chǔ)視頻教程、MINA視頻教程、Netty快速入門視頻 [有源碼]
          輕量級即時通訊框架MobileIMSDK的iOS源碼(開源版)[附件下載]
          開源IM工程“蘑菇街TeamTalk”2015年5月前未刪減版完整代碼 [附件下載]
          微信本地?cái)?shù)據(jù)庫破解版(含iOS、Android),僅供學(xué)習(xí)研究 [附件下載]
          NIO框架入門(一):服務(wù)端基于Netty4的UDP雙向通信Demo演示 [附件下載]
          NIO框架入門(二):服務(wù)端基于MINA2的UDP雙向通信Demo演示 [附件下載]
          NIO框架入門(三):iOS與MINA2、Netty4的跨平臺UDP雙向通信實(shí)戰(zhàn) [附件下載]
          NIO框架入門(四):Android與MINA2、Netty4的跨平臺UDP雙向通信實(shí)戰(zhàn) [附件下載]
          用于IM中圖片壓縮的Android工具類源碼,效果可媲美微信 [附件下載]
          高仿Android版手機(jī)QQ可拖拽未讀數(shù)小氣泡源碼 [附件下載]
          一個WebSocket實(shí)時聊天室Demo:基于node.js+socket.io [附件下載]
          Android聊天界面源碼:實(shí)現(xiàn)了聊天氣泡、表情圖標(biāo)(可翻頁) [附件下載]
          高仿Android版手機(jī)QQ首頁側(cè)滑菜單源碼 [附件下載]
          開源libco庫:單機(jī)千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]
          分享java AMR音頻文件合并源碼,全網(wǎng)最全
          微信團(tuán)隊(duì)原創(chuàng)Android資源混淆工具:AndResGuard [有源碼]
          一個基于MQTT通信協(xié)議的完整Android推送Demo [附件下載]
          Android版高仿微信聊天界面源碼 [附件下載]
          高仿手機(jī)QQ的Android版鎖屏聊天消息提醒功能 [附件下載]
          高仿iOS版手機(jī)QQ錄音及振幅動畫完整實(shí)現(xiàn) [源碼下載]
          Android端社交應(yīng)用中的評論和回復(fù)功能實(shí)戰(zhàn)分享[圖文+源碼]
          Android端IM應(yīng)用中的@人功能實(shí)現(xiàn):仿微博、QQ、微信,零入侵、高可擴(kuò)展[圖文+源碼]
          仿微信的IM聊天時間顯示格式(含iOS/Android/Web實(shí)現(xiàn))[圖文+源碼]
          Android版仿微信朋友圈圖片拖拽返回效果 [源碼下載]
          適合新手:從零開發(fā)一個IM服務(wù)端(基于Netty,有完整源碼)
          拉起鍵盤就是干:跟我一起徒手?jǐn)]一套分布式IM系統(tǒng)
          >> 更多同類文章 …… 

          [2] 有關(guān)IM架構(gòu)設(shè)計(jì)的文章:
          淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)
          簡述移動端IM開發(fā)的那些坑:架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端
          一套海量在線用戶的移動端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)
          一套原創(chuàng)分布式即時通訊(IM)系統(tǒng)理論架構(gòu)方案
          從零到卓越:京東客服即時通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程
          蘑菇街即時通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇
          騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT
          微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計(jì)實(shí)踐
          微信技術(shù)總監(jiān)談架構(gòu):微信之道——大道至簡(演講全文)
          如何解讀《微信技術(shù)總監(jiān)談架構(gòu):微信之道——大道至簡》
          快速裂變:見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程(一)
          17年的實(shí)踐:騰訊海量產(chǎn)品的技術(shù)方法論
          移動端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時性?
          現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討
          IM開發(fā)基礎(chǔ)知識補(bǔ)課(二):如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲架構(gòu)?
          IM開發(fā)基礎(chǔ)知識補(bǔ)課(三):快速理解服務(wù)端數(shù)據(jù)庫讀寫分離原理及實(shí)踐建議
          IM開發(fā)基礎(chǔ)知識補(bǔ)課(四):正確理解HTTP短連接中的Cookie、Session和Token
          WhatsApp技術(shù)實(shí)踐分享:32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話
          微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)
          王者榮耀2億用戶量的背后:產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡(luò)方案等
          IM系統(tǒng)的MQ消息中間件選型:Kafka還是RabbitMQ?
          騰訊資深架構(gòu)師干貨總結(jié):一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面
          以微博類應(yīng)用場景為例,總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計(jì)步驟
          快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理
          子彈短信光鮮的背后:網(wǎng)易云信首席架構(gòu)師分享億級IM平臺的技術(shù)實(shí)踐
          知乎技術(shù)分享:從單機(jī)到2000萬QPS并發(fā)的Redis高性能緩存實(shí)踐之路
          IM開發(fā)基礎(chǔ)知識補(bǔ)課(五):通俗易懂,正確理解并用好MQ消息隊(duì)列
          微信技術(shù)分享:微信的海量IM聊天消息序列號生成實(shí)踐(算法原理篇)
          微信技術(shù)分享:微信的海量IM聊天消息序列號生成實(shí)踐(容災(zāi)方案篇)
          新手入門:零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐
          一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐
          阿里技術(shù)分享:深度揭秘阿里數(shù)據(jù)庫技術(shù)方案的10年變遷史
          阿里技術(shù)分享:阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路
          社交軟件紅包技術(shù)解密(一):全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等
          社交軟件紅包技術(shù)解密(二):解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)
          社交軟件紅包技術(shù)解密(三):微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)
          社交軟件紅包技術(shù)解密(四):微信紅包系統(tǒng)是如何應(yīng)對高并發(fā)的
          社交軟件紅包技術(shù)解密(五):微信紅包系統(tǒng)是如何實(shí)現(xiàn)高可用性的
          社交軟件紅包技術(shù)解密(六):微信紅包系統(tǒng)的存儲層架構(gòu)演進(jìn)實(shí)踐
          社交軟件紅包技術(shù)解密(七):支付寶紅包的海量高并發(fā)技術(shù)實(shí)踐
          社交軟件紅包技術(shù)解密(八):全面解密微博紅包技術(shù)方案
          社交軟件紅包技術(shù)解密(九):談?wù)勈諵紅包的功能邏輯、容災(zāi)、運(yùn)維、架構(gòu)等
          即時通訊新手入門:一文讀懂什么是Nginx?它能否實(shí)現(xiàn)IM的負(fù)載均衡?
          即時通訊新手入門:快速理解RPC技術(shù)——基本概念、原理和用途
          多維度對比5款主流分布式MQ消息隊(duì)列,媽媽再也不擔(dān)心我的技術(shù)選型了
          從游擊隊(duì)到正規(guī)軍:馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)演進(jìn)之路
          IM開發(fā)基礎(chǔ)知識補(bǔ)課(六):數(shù)據(jù)庫用NoSQL還是SQL?讀這篇就夠了!
          >> 更多同類文章 ……

          (本文同步發(fā)布于:http://www.52im.net/thread-2775-1-1.html



          作者:Jack Jiang (點(diǎn)擊作者姓名進(jìn)入Github)
          出處:http://www.52im.net/space-uid-1.html
          交流:歡迎加入即時通訊開發(fā)交流群 215891622
          討論:http://www.52im.net/
          Jack Jiang同時是【原創(chuàng)Java Swing外觀工程BeautyEye】【輕量級移動端即時通訊框架MobileIMSDK】的作者,可前往下載交流。
          本博文 歡迎轉(zhuǎn)載,轉(zhuǎn)載請注明出處(也可前往 我的52im.net 找到我)。


          只有注冊用戶登錄后才能發(fā)表評論。


          網(wǎng)站導(dǎo)航:
           
          Jack Jiang的 Mail: jb2011@163.com, 聯(lián)系QQ: 413980957, 微信: hellojackjiang
          主站蜘蛛池模板: 淅川县| 德庆县| 临沭县| 巴中市| 加查县| 汕尾市| 枣庄市| 鹰潭市| 太康县| 乳山市| 珠海市| 田阳县| 桑植县| 荔波县| 蒙城县| 大兴区| 定兴县| 巩留县| 扎鲁特旗| 鸡泽县| 阿瓦提县| 新龙县| 东平县| 金坛市| 孝义市| 汉沽区| 巴林左旗| 漳州市| 个旧市| 闵行区| 察雅县| 上犹县| 阿瓦提县| 武宣县| 镇康县| 黄浦区| 夏河县| 沈阳市| 南昌市| 梅州市| 兴业县|