<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    Jack Jiang

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

    本文收作者“大白菜”分享,有改動。注意:本系列是給IM初學者的文章,IM老油條們還望海涵,勿噴!

    1、引言

    這又是一篇基于Netty的IM編碼實踐文章,因為合成一篇內容太長,讀起來太累,所以也就順著作者的思路分開成4篇,讀起來心理壓力也就沒那么大了。

    這個系列的幾篇文章分享的是:假設在沒有任何成型的第3方IM庫或SDK的情況下,以網絡編程的基礎技術視野,思考和實踐如何基于Netty網絡庫從零寫一個可以聊天的IM系統的過程,沒有眼花繚亂的架構設計、也沒有高端大氣的模式設計方法論,有的只是從IM入門者的角度的思路和實戰,適合IM初學者閱讀。

    本篇主要是徒手擼IM系列的開篇,主要講解的是的IM設計思路,不涉及實踐編碼,希望給你帶來幫助。

    學習交流:

    本文已同步發布于:http://www.52im.net/thread-3963-1-1.html

    2、知識準備

    * 重要提示:本系列文章主要是代碼實戰分享,如果你對即時通訊(IM)技術理論了解的不多,建議先詳細閱讀:《零基礎IM開發入門:什么是IM系統?》、《新手入門一篇就夠:從零開發移動端IM》。

    不知道 Netty 是什么?這里簡單介紹下:

    Netty 是一個 Java 開源框架。Netty 提供異步的、事件驅動的網絡應用程序框架和工具,用以快速開發高性能、高可靠性的網絡服務器和客戶端程序。

    也就是說,Netty 是一個基于 NIO 的客戶、服務器端編程框架,使用Netty 可以確保你快速和簡單的開發出一個網絡應用,例如實現了某種協議的客戶,服務端應用。

    Netty 相當簡化和流線化了網絡應用的編程開發過程,例如,TCP 和 UDP 的 Socket 服務開發。

    Netty的基礎入門好文章:

    如果你連Java的NIO都不知道是什么,下面的文章建議優先讀:

    Netty源碼和API的在線查閱地址:

    3、系列文章

    本文是系列文章的第1篇,以下是系列目錄:

    1. 基于Netty,徒手擼IM(一):IM系統設計篇》(* 本文
    2. 《基于Netty,徒手擼IM(二):編碼實踐篇(單聊功能)》
    3. 《基于Netty,徒手擼IM(三):編碼實踐篇(群聊功能)》
    4. 《基于Netty,徒手擼IM(一):編碼實踐篇(系統優化)》

    4、需求分析

    業務場景: 本次實戰就是模擬微信的IM聊天,每個客戶端和服務端建立連接,并且可以實現點對點通信(單聊),點對多點通信(群聊)。

    設計思路: 我們要實現的是點(客戶端)對點(客戶端)的通訊,但是我們大部分情況下接觸的業務都是客戶端和服務端之間的通訊(所謂的C/S模式?),客戶端只需要知道服務端的 IP 地址和端口號即可發起通訊了。那么客戶端和客戶端應該怎么去設計呢?

    技術思考:難道是手機和手機之間建立通訊連接(所謂的P2P),互相發送消息嗎?

    這種方案顯然不是很好的方案:

    • 1)首先: 客戶端和客戶端之間通訊,首先需要確定對方的 IP 地址和端口號,顯然不是很現實;
    • 2)其次: 即使有辦法拿到對方的 IP 地址和端口號,那么每個點(客戶端)既作為服務端還得作為客戶端,無形之中增加了客戶端的壓力。

    其實:我們可以使用服務端作為IM聊天消息的中轉站,由服務端主動往指定客戶端推送消息。如果是這種模式的話,那么 Http 協議是無法支持的(因為Http 是無狀態的,只能一請求一響應的模式),于是就只能使用 TCP 協議去實現了。

    Jack Jiang注:此處作者表述不太準確,因為雖然HTTP是無狀態的,但一樣可以實現即時通訊能力,有興趣的讀者可以閱讀以下幾篇文章,了解一下這些曾經利用HTTP實現即時通訊聊天的技術方法:

    1. 新手入門貼:史上最全Web端即時通訊技術原理詳解
    2. Web端即時通訊技術盤點:短輪詢、Comet、Websocket、SSE
    3. 網頁端IM通信技術快速入門:短輪詢、長輪詢、SSE、WebSocket

    5、IM單聊思路設計

    5.1 通訊架構原理

    以下是通訊架構原理圖:

     

    如上圖所示,通訊流程解析如下:

    • 1)實現客戶端和客戶端之間通訊,那么需要使用服務端作為通訊的中轉站,每個客戶端都必須和服務端建立連接;
    • 2)每個客戶端和服務端建立連接之后,服務端保存用戶 ID 和通道的映射關系,其中用戶 ID 作為客戶端的唯一標識;
    • 3)客戶端 A 往客戶端 B 發送消息時,先把消息發送到服務端,再有服務端往客戶端 B 進行推送。

    針對上述第“3)”點,服務端如何找到客戶端 B 呢?

    客戶端 A 往服務端發送消息時,消息攜帶的信息有:“客戶端 A 用戶 ID”、“客戶端 B 用戶 ID”、“消息內容”。這樣服務端就能順利找到服務端 B 的通道并且進行推送消息了。

    5.2 消息推送流程

    每個客戶端和服務端建立連接的時候,必須把個人用戶信息上傳到服務端,由服務端統一保存映射關系。如果某個客戶端下線了,則服務端監聽到連接斷開,刪除對應的映射關系。

    其次:發起群聊的時候,需要傳遞 touser 字段,服務端根據該字段在映射表里面查找到對應的連接通道并發起消息推送。

    上述邏輯原理如下圖所示:

    5.3 更多的細節

    其實在真正要做IM之前,要考慮的技術細節還是很多的,以下這幾篇文章就步及到了典型的幾個IM熱門技術點,有興趣的一定要讀一讀:

    1. 移動端IM開發需要面對的技術問題
    2. 談談移動端 IM 開發中登錄請求的優化
    3. IM消息送達保證機制實現(一):保證在線實時消息的可靠投遞
    4. IM消息送達保證機制實現(二):保證離線消息的可靠投遞
    5. 如何保證IM實時消息的“時序性”與“一致性”?

    6、IM群聊思路設計

    群聊指的是一個組內多個用戶之間的聊天,一個用戶發到群組的消息會被組內任何一個成員接收 。

    具體架構思路如下所示:

    如上圖所示,群聊通訊流程解析如下。

    1)群聊其實和單聊整體上思路都是一致的,都是需要保存每個用戶和通道的對應關系,方便后期通過用戶 ID 去查找到對應的通道,再跟進通道推送消息。

    2)如何把消息發送給多個組內的成員呢?

    其實很簡單,服務端再保存另外一份映射關系,那就是聊天室和成員的映射關系。發送消息時,首先根據聊天室 ID 找到對應的所有成員,然后再跟進各個成員的 ID 去查找到對應的通道,最后由每個通道進行消息的發送。

    3)成員加入某個群聊組的時候,往映射表新增一條記錄,如果成員退群的時候則刪除對應的映射記錄。

    通過上面的架構圖可以發現,群聊和單聊相比,其實就是多了一份映射關系而已。

    其實群聊是IM里相對來說技術難度較高的功能,有興趣的讀者可以閱讀下面這幾篇:

    1. IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”?
    2. IM群聊消息如此復雜,如何保證不丟不重?
    3. 移動端IM中大規模群消息的推送如何保證效率、實時性?
    4. 現代IM系統中聊天消息的同步和存儲方案探討
    5. 關于IM即時通訊群聊消息的亂序問題討論
    6. IM群聊消息的已讀回執功能該怎么實現?
    7. IM群聊消息究竟是存1份(即擴散讀)還是存多份(即擴散寫)?
    8. 一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐

    另外,對于超大規模群聊,技術難度更是指數上升:

    1. 網易云信技術分享:IM中的萬人群聊技術方案實踐總結
    2. 阿里釘釘技術分享:企業級IM王者——釘釘在后端架構上的過人之處
    3. IM群聊消息的已讀未讀功能在存儲空間方面的實現思路探討
    4. 企業微信的IM架構設計揭秘:消息模型、萬人群、已讀回執、消息撤回等
    5. 融云IM技術分享:萬人群聊消息投遞方案的思考和實踐
    6. 微信直播聊天室單房間1500萬在線的消息架構演進之路

    7、本文小結

    本篇主要是幫助讀者掌握單聊和群聊的核心設計思路。

    單聊: 主要是服務器保存了一份用戶和通道之間的映射關系,發送消息的時候,根據接收人 ID 找到其對應的通道 Channel,Channel 的 write () 可以給客戶端發送消息。

    群聊: 保存兩份關系,分別是用戶 ID 和 Channel 之間的關系、群組 ID 和用戶 ID 的關系。推送消息的時候,首先根據聊天組 ID 找到其對應的成員,遍歷每個成員再進行找出其對應的通道即可。

    整體來說,思路還是很簡單的,掌握了該設計思路以后,你會發現設計一款 IM 聊天軟件其實也不是很復雜。

    8、相關文章

    如果你覺得對本系列文章還不夠詳細,可以系統學習以下系列文章:

    1. 跟著源碼學IM(一):手把手教你用Netty實現心跳機制、斷線重連機制
    2. 跟著源碼學IM(二):自已開發IM很難?手把手教你擼一個Andriod版IM
    3. 跟著源碼學IM(三):基于Netty,從零開發一個IM服務端
    4. 跟著源碼學IM(四):拿起鍵盤就是干,教你徒手開發一套分布式IM系統
    5. 跟著源碼學IM(五):正確理解IM長連接、心跳及重連機制,并動手實現
    6. 跟著源碼學IM(六):手把手教你用Go快速搭建高性能、可擴展的IM系統
    7. 跟著源碼學IM(七):手把手教你用WebSocket打造Web端IM聊天
    8. 跟著源碼學IM(八):萬字長文,手把手教你用Netty打造IM聊天
    9. 跟著源碼學IM(九):基于Netty實現一套分布式IM系統
    10. 跟著源碼學IM(十):基于Netty,搭建高性能IM集群(含技術思路+源碼)
    11. SpringBoot集成開源IM框架MobileIMSDK,實現即時通訊IM聊天功能

    9、參考資料

    [1] 新手入門:目前為止最透徹的的Netty高性能原理和框架架構解析

    [2] 理論聯系實際:一套典型的IM通信協議設計詳解

    [3] 淺談IM系統的架構設計

    [4] 簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端

    [5] 一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)

    [6] 一套原創分布式即時通訊(IM)系統理論架構方案

    [7]  一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐

    [8] 一套億級用戶的IM架構技術干貨(上篇):整體架構、服務拆分等

    [9] 一套億級用戶的IM架構技術干貨(下篇):可靠性、有序性、弱網優化等

    [10] 從新手到專家:如何設計一套億級消息量的分布式IM系統

    [11] 基于實踐:一套百萬消息量小規模IM系統技術要點總結

    [12] 探探的IM長連接技術實踐:技術選型、架構設計、性能優化

    本文已同步發布于:http://www.52im.net/thread-3963-1-1.html



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


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


    網站導航:
     
    Jack Jiang的 Mail: jb2011@163.com, 聯系QQ: 413980957, 微信: hellojackjiang
    主站蜘蛛池模板: 免费一区二区视频| 久久久久国产免费| 国产成人免费福利网站| 色在线亚洲视频www| 18勿入网站免费永久| 亚洲视屏在线观看| 麻豆高清免费国产一区| 337p日本欧洲亚洲大胆艺术| 全免费a级毛片免费看| 久久精品国产亚洲AV果冻传媒 | 女人张开腿给人桶免费视频 | 久久精品国产亚洲一区二区| a国产成人免费视频| 亚洲av日韩av天堂影片精品| 69影院毛片免费观看视频在线 | 亚洲成AV人片在线观看| 国产无遮挡无码视频免费软件| 亚洲乱色熟女一区二区三区丝袜 | 国产成人亚洲综合无码| 青青草国产免费国产是公开| 国产在线不卡免费播放| 精品亚洲福利一区二区| 国产成人免费全部网站| 无码人妻一区二区三区免费视频| 亚洲男人av香蕉爽爽爽爽| 午夜不卡AV免费| 亚洲精品国偷自产在线| 日本免费在线观看| 亚洲无码精品浪潮| 男女猛烈无遮掩视频免费软件| 日本免费人成黄页在线观看视频 | 亚洲性天天干天天摸| 久草福利资源网站免费| 亚洲另类自拍丝袜第1页| 97无码免费人妻超级碰碰碰碰 | 久视频精品免费观看99| 亚洲中文无码卡通动漫野外| 日韩免费无砖专区2020狼| 又黄又大的激情视频在线观看免费视频社区在线 | 国产一级a毛一级a看免费视频| 亚洲啪啪AV无码片|