请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 44
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

本文原题为“一个海量在线用户即时通讯系统(IM)的完整设计”,来自IM技术交流群群友:封宇,感谢原作者(原文链接在文末)。


1、写在前面


1.1、引言


如果在没有太多经验可借鉴的情况下,要设计一套完整可用的移动端IM架构,难度是相当大的。原因在于,IM系统(尤其是移动端IM系统)是多种技术和领域知识的横向应用综合体:网络编程、通信安全、高并发编程、移动端开发等,如果要包含实时音视频聊天的话,则还要加上难度更大的音视频编解码技术(内行都知道,把音视频编解码及相关技术玩透的,博士学位都可以混出来了),凡此种种,加上移动网络的特殊性、复杂性,设计和开发难度不言而喻。

本文分享了一套完整的海量在线用户的移动端IM架构设计,来自于作者的真实项目实践总结,包含了详细的算法原理图、数据结构定义、表结构定义等等

即时通讯网注:本文中的架构设计从实际应用的角度看,其实并不完美,多处设计对于高吞吐高并发的IM应用来说也是存在单点性能瓶颈的(比如:提供消息交换逻辑的msg_logic服务、提供全局用户状态查询的单点Redis等),另外IM协议设计可能也稍显混乱(但这是仁者见仁智者见者的事了,不能一概而论)。但文章中的大部分算法原理、协议设计等都是值得借鉴的,总之没必要照搬,但至少能给你自已的方案设计带来灵感,我想这也是本文或即时通讯网的其它类似文章的真正价值所在。

另外,如果您正打算从零开发移动端IM,则建议您从《新手入门一篇就够:从零开发移动端IM一文开始,此文按照IM开发所需的知识和技能要求,拟定了详尽的学习提纲和建议等。

1.2、参考资料


[1] IM架构方面的文章:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信后台基于时间序的海量数据冷热分级架构设计实践
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
移动端IM中大规模群消息的推送如何保证效率、实时性?
现代IM系统中聊天消息的同步和存储方案探讨
IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?
IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议
IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token
WhatsApp技术实践分享:32人工程团队创造的技术神话
微信朋友圈千亿访问量背后的技术挑战和实践总结
王者荣耀》2亿用户量的背后:产品定位、技术架构、网络方案等
>> 更多同类文章 ……

[2] IM热点问题总结文章:
移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”
移动端IM开发者必读(二):史上最全移动弱网络优化方法总结
从客户端的角度来谈谈移动端IM的消息可靠性和送达机制
现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障
腾讯技术分享:社交网络图片的带宽压缩技术演进之路
IM开发基础知识补课:正确理解前置HTTP SSO单点登陆接口的原理
移动端IM中大规模群消息的推送如何保证效率、实时性?
移动端IM开发需要面对的技术问题
开发IM是自己设计协议用字节流好还是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM消息送达保证机制实现(一):保证在线实时消息的可靠投递
IM消息送达保证机制实现(二):保证离线消息的可靠投递
如何保证IM实时消息的“时序性”与“一致性”?
一个低成本确保IM消息时序的方法探讨
IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?
IM群聊消息如此复杂,如何保证不丢不重?
谈谈移动端 IM 开发中登录请求的优化
移动端IM登录时拉取数据如何作到省流量?
浅谈移动端IM的多点登陆和消息漫游原理
完全自已开发的IM该如何设计“失败重试”机制?
通俗易懂:基于集群的移动端IM接入层负载均衡方案分享
微信对网络影响的技术试验及分析(论文全文)
即时通讯系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
QQ音乐团队分享:Android中的图片压缩技术详解(上篇)
QQ音乐团队分享:Android中的图片压缩技术详解(下篇)
腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)
腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(下篇)
如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
基于社交网络的Yelp是如何实现海量用户图片的无损压缩的?
腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)
腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)
为什么说即时通讯社交APP创业就是一个坑?
>> 更多同类文章 ……

2、服务器端设计


2.1、总体架构设计


总体架构包括5个层级,具体内容如下图:
1.jpg

各层级的说明如下:

  • 用户端:
    移动端重点是移动端,支持IOS/Android系统,包括IM App,嵌入消息功能的瓜子App,未来还可能接入客服系统;
  • 用户端API:
    针对TCP协议,提供IOS/Android开发SDK。对于H5页面,提供WebSocket接口;
  • 接入层:
    接入层主要任务是保持海量用户连接(接入)、攻击防护、将海量连接整流成少量TCP连接与逻辑层通讯;
  • 逻辑层:
    逻辑层负责IM系统各项功能的核心逻辑实现。包括单聊(c2c)、上报(c2s)、推送(s2c)、群聊(c2g)、离线消息、登录授权、组织机构树等等内容;
  • 存储层:
    存储层负责缓存或存储IM系统相关数据,主要包括用户状态及路由(缓存),消息数据(MySQL也可采用NoSql,如MangoDB),文件数据(文件服务器)。

2.2、典型算法逻辑


典型算法逻辑部分描述IM系统核心组件及其协作关系,结构图如下:
2.jpg

客户端从Iplist服务获取接入层IP地址(也可采用域名的方式解析得到接入层IP地址),建立与接入层的连接(可能为短连接),从而实现客户端与IM服务器的数据交互;业务线服务器可以通过服务器端API建立与IM服务器的联系,向客户端推送消息;客户端上报到业务服务器的消息,IM服务器会通过mq投递给业务服务器。

以下将对各子业务的工作原理进行逐一介绍。

2.2.1登录授权(auth)流程原理


3.jpg

  • 1、客户端通过统一登录系统实现登录,得到token。
  • 2、客户端用uid和token向msg-gate发起授权验证请求。
  • 3、msg-gate同步调用msg-logic的验证接口
  • 4、msg-logic请求sso系统验证token合法性
  • 5、msg-gate得到登录结果后,设置session状态,并向客户端返回授权结果。

2.2.2登出(logout)流程原理


4.jpg

  • 1、客户端发起logout请求,msg-gate设置对应Peer为未登录状态。
  • 2、Msg-gate给客户端一个ack响应。
  • 3、Msg-gate通知msg-logic用户登出。

2.2.3踢人(kickout)流程原理


用户请求授权时,可能在另一个设备(同类型设备)开着软件处于登录状态,这种情况需要系统将那个设备踢下线,如下图:
5.jpg

  • 1-5步,参看Auth流程。
  • 6、Logic检索Redis,查看是否该用户在其他地方登录。
  • 7、如果在其他地方登录,发起kickout命令。(如果没有登录,整个流程结束)
  • 8、Gate向用户发起kickout请求,并在短时间内(确保客户端收到kickout数据)关闭socket连接。

2.2.4上报(c2s)流程原理


6.jpg

  • 1、客户端向gate发送数据;
  • 2、Gate回一个ack包,向客户端确认已经收到数据;
  • 3、Gate将数据包传递给logic;
  • 4、Logic根据数据投递目的地,选择对应的mq队列进行投递;
  • 5、业务服务器得到数据。

2.2.5推送(s2c)流程原理


7.jpg

  • 1、业务线调用push数据接口sendMsg
  • 2、Logic向redis检索目标用户状态。如果目标用户不在线,丢弃数据(未来可根据业务场景定制化逻辑);如果用户在线,查询到用户连接的接入层gate
  • 3、Logic向用户所在的gate发送数据
  • 4、Gate向用户推送数据。(如果用户不在线,通知logic用户不在线)
  • 5、客户端收到数据后向gate发送ack反馈
  • 6、Gate将ack信息传递给logic层,用于其他可能的逻辑处理(如日志,确认送达等)


2.2.6单对单聊天(c2c)流程原理


8.jpg

  • 1、App1向gate1发送信息(信息最终要发给App2)
  • 2、Gate1将信息投递给logic
  • 3、Logic收到信息后,将信息进行存储
  • 4、存储成功后,logic向gate1发送ack
  • 5、Gate1将ack信息发给App1
  • 6、Logic检索redis,查找App2状态。如果App2未登录,流程结束
  • 7、如果App2登录到了gate2,logic将消息发往gate2
  • 8、Gate2将消息发给App2(如果发现App2不在线,丢弃消息即可,这种概率极低,后续离线消息可保证消息不丢)
  • 9、App2向gate2发送ack
  • 10、Gate2将ack信息发给logic
  • 11、Logic将消息状态设置为已送达。

注:在第6步和第7步之间,启动计时器(DelayedQueue或哈希环,时间如5秒),计时器时间到后,探测该条消息状态,如果消息未送达,考虑通过APNS、米推、个推进行推送。

2.2.7群聊(c2g)流程原理


采用扩散写(而非扩散读)的方式。

群聊是多人社交的基本诉求,一个群友在群内发了一条消息:
  • 1)在线的群友能第一时间收到消息;
  • 2)离线的群友能在登陆后收到消息。

由于“消息风暴扩散系数”的存在,群消息的复杂度要远高于单对单消息。

群基础表:用来描述一个群的基本信息
im_group_msgs(group_id, group_name,create_user, owner, announcement, create_time)

群成员表:用来描述一个群里有多少成员
im_group_users(group_id, user_id)

用户接收消息表:用来描述一个用户的所有收到群消息(与单对单消息表是同一个表)
im_message_recieve(msg_id,msg_from,msg_to, group_id,msg_seq, msg_content, send_time, msg_type, deliverd, cmd_id)

用户发送消息表:用来描述一个用户发送了哪些消息
im_message_send (msg_id,msg_from,msg_to, group_id,msg_seq, msg_content, send_time, msg_type, cmd_id)

业务场景举例:
  • 1)一个群中有x,A,B,C,D共5个成员,成员x发了一个消息;
  • 2)成员A与B在线,期望实时收到消息;
  • 3)成员C与D离线,期望未来拉取到离线消息。

群聊流程如下图所示:
9.jpg

群聊流程详细说明:
  • 1、X向gate发送信息(信息最终要发给这个群,A、B在线)
  • 2、Gate将消息发给logic
  • 3、存储消息到im_message_send表,按照msg_from水平分库
  • 4、回ack
  • 5、回ack
  • 6、Logic检索数据库(需要使用缓存),获得群成员列表
  • 7、存储每个用户的消息数据(用户视图),按照msg_to水平分库(并发、批量写入)。
  • 8、查询用户在线状态及位置
  • 9、Logic向gate投递消息
  • 10、Gate向用户投递消息
  • 11、App返回收到消息的ack信息
  • 12、Gate向logic传递ack信息
  • 13、向缓存(Hash)中更新收到ack的时间。然后在通过一个定时任务,每隔一定时间,将数据更新到数据库(注意只需要写入时间段内有变化的数据)。

2.2.8拉取离线消息流程原理


下图中,将gate和logic合并为im-server,拉取离线消息流程如下:
10.jpg

  • 1、App端登录成功后(或业务触发拉取离线消息),向IM系统发起拉离线消息请求。传递3个主要参数,uid表明用户;msgid表明当前收到的最大消息id(如果没收到过消息,或拿不到最大消息id则msgid=0)即可;size表示每次拉取条数(这个值也可以由服务器端控制)。
  • 2、假设msgid==0,什么都不做。(参看第6步骤)
  • 3、Im-server查询用户前10条离线消息
  • 4、将离线消息推给用户。假设这10条离线消息最大msgid=110。
  • 5、App得到数据,判断得到的数据不为空(表明可能没有拉完离线数据,不用<10条做判断拉完条件,因为服务端需要下下次拉离线的请求来确定这次数据已送达),继续发起拉取操作。Msgid=110(取得到的离线消息中最大的msgid)。
  • 6、Im-server删除该用户msgid<110的离线消息(或者标记为已送达)。
  • 7、查询msgid>110的钱10条离线数据。
  • 8、返回给App
  • ……
  • N-1、查询msgid>140的离线数据,0条(没有离线数据了)。
  • N  、将数据返回App,App判断拉取到0条数据,结束离线拉取过程。

2.3、后台PUSH(推送)


iOS采用APNS,Android真后台保活,同时增加米推、个推。基本思路:push提示信息,App通过拉离线获得真实消息。

3、协议设计


3.1、IM协议总体定义


TCP的数据协议如下图所示,包括header和body两部分:
11.jpg

消息头总共20个字节,具体信息如下表:
12.jpg

3.2、各具体的IM协议体定义


消息体协议采用ProtocolBuffer(谷歌)协议(详见文章《Protobuf通信协议详解:代码演示、详细原理介绍等),版本3.0.0,该协议在序列化效率、压缩、可扩展方面都具有优势。以下为主要流程涉及的协议。

认证(auth) :
13.jpg

登出(logout) :
14.jpg

踢人(kickout) :
15.jpg

心跳(keepalive,noop):
心跳包消息体为空。

单对单聊天(c2c):
16.jpg
17.jpg

群聊(c2g):
18.jpg
19.jpg

拉离线(pull):
20.jpg

控制类(ctrl)协议:
21.jpg
23-2.jpg

4、存储设计


4.1、MySQL数据库


MySQL数据库采用utf8mb4编码格式(emoji字符问题)。

4.2、主要表结构


发送消息表:
保存某个用户发送了哪些消息,用于复现用户聊天场景(消息漫游功能需要)。
22.jpg

推送消息表:
保存某个用户收到了哪些消息。
23.jpg

群基本信息表:
24.jpg

群用户关系表:
25.jpg

4.3、水平分库


26.jpg

4.4、Redis缓存


用户状态及路由信息:
Redis缓存以uid为key,检索channel(socketid),last_packet_time等。
Gate层,session以channel(socketed)为key,检索uid,及其他信息。
交互接口:gate->logic,通过将channel转换为uid作为key。
logic->gate,将uid转换为channel作为key。

其他缓存信息:
你觉得该怎么存就怎么存。

4.5、文件及图片存储


采用商用云存储。

4.6、数据归档


可考虑采用HBase,HDFS作为数据归档,或者相关云存储服务。

安全部分略,其他非核心功能略。

(原文链接:点此进入,有改动)

附录:更多IM开发资料汇总


[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)
通俗易懂-深入理解TCP协议(上):理论基础
通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通讯协议关系图(中文珍藏版)
UDP中一个包的大小最大能多大?
P2P技术详解(一):NAT详解——详细原理、P2P简介
P2P技术详解(二):P2P中的NAT穿越(打洞)方案详解
P2P技术详解(三):P2P技术之STUN、TURN、ICE详解
通俗易懂:快速理解P2P技术中的NAT穿透原理
高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少
高性能网络编程(二):上一个10年,著名的C10K并发连接问题
高性能网络编程(三):下一个10年,是时候考虑C10M并发问题了
高性能网络编程(四):从C10K到C10M高性能网络应用的理论探索
不为人知的网络编程(一):浅析TCP协议中的疑难杂症(上篇)
不为人知的网络编程(二):浅析TCP协议中的疑难杂症(下篇)
不为人知的网络编程(三):关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT
不为人知的网络编程(四):深入研究分析TCP的异常关闭
不为人知的网络编程(五):UDP的连接性和负载均衡
不为人知的网络编程(六):深入地理解UDP协议并用好它
不为人知的网络编程(七):如何让不可靠的UDP变的可靠?
网络编程懒人入门(一):快速理解网络通信协议(上篇)
网络编程懒人入门(二):快速理解网络通信协议(下篇)
网络编程懒人入门(三):快速理解TCP协议一篇就够
网络编程懒人入门(四):快速理解TCP和UDP的差异
网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势
网络编程懒人入门(六):史上最通俗的集线器、交换机、路由器功能原理入门
技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解
让互联网更快:新一代QUIC协议在腾讯的技术实践分享
现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障
聊聊iOS中网络编程长连接的那些事
移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”
移动端IM开发者必读(二):史上最全移动弱网络优化方法总结
IPv6技术详解:基本概念、应用现状、技术实践(上篇)
IPv6技术详解:基本概念、应用现状、技术实践(下篇)
>> 更多同类文章 ……

[2] NIO异步网络编程资料:
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
有关“为何选择Netty”的11个疑问及解答
开源NIO框架八卦——到底是先有MINA还是先有Netty?
选Netty还是Mina:深入研究与对比(一)
选Netty还是Mina:深入研究与对比(二)
NIO框架入门(一):服务端基于Netty4的UDP双向通信Demo演示
NIO框架入门(二):服务端基于MINA2的UDP双向通信Demo演示
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
Netty 4.x学习(一):ByteBuf详解
Netty 4.x学习(二):Channel和Pipeline详解
Netty 4.x学习(三):线程模型详解
Apache Mina框架高级篇(一):IoFilter详解
Apache Mina框架高级篇(二):IoHandler详解
MINA2 线程原理总结(含简单测试实例)
Apache MINA2.0 开发指南(中文版)[附件下载]
MINA、Netty的源代码(在线阅读版)已整理发布
解决MINA数据传输中TCP的粘包、缺包问题(有源码)
解决Mina中多个同类型Filter实例共存的问题
实践总结:Netty3.x升级Netty4.x遇到的那些坑(线程篇)
实践总结:Netty3.x VS Netty4.x的线程模型
详解Netty的安全性:原理介绍、代码演示(上篇)
详解Netty的安全性:原理介绍、代码演示(下篇)
详解Netty的优雅退出机制和原理
NIO框架详解:Netty的高性能之道
Twitter:如何使用Netty 4来减少JVM的GC开销(译文)
绝对干货:基于Netty实现海量接入的推送服务技术要点
Netty干货分享:京东京麦的生产级TCP网关技术实践总结
>> 更多同类文章 ……

[3] 有关IM/推送的通信格式、协议的选择:
Protobuf通信协议详解:代码演示、详细原理介绍等
一个基于Protocol Buffer的Java代码演示
简述传输层协议TCP和UDP的区别
为什么QQ用的是UDP协议而不是TCP协议?
移动端即时通讯协议选择:UDP还是TCP?
如何选择即时通讯应用的数据传输格式
强列建议将Protobuf作为你的即时通讯应用数据传输格式
全方位评测:Protobuf性能到底有没有比JSON快5倍?
移动端IM开发需要面对的技术问题(含通信协议选择)
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
理论联系实际:一套典型的IM通信协议设计详解
58到家实时消息系统的协议设计等技术实践分享
详解如何在NodeJS中使用Google的Protobuf
技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解
金蝶随手记团队分享:还在用JSON? Protobuf让数据传输更省更快(原理篇)
金蝶随手记团队分享:还在用JSON? Protobuf让数据传输更省更快(实战篇)
>> 更多同类文章 ……

[4] 有关IM/推送的心跳保活处理:
应用保活终极总结(一):Android6.0以下的双进程守护保活实践
应用保活终极总结(二):Android6.0及以上的保活实践(进程防杀篇)
应用保活终极总结(三):Android6.0及以上的保活实践(被杀复活篇)
Android进程保活详解:一篇文章解决你的所有疑问
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
深入的聊聊Android消息推送这件小事
为何基于TCP协议的移动端IM仍然需要心跳保活机制?
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
>> 更多同类文章 ……

[5] 有关WEB端即时通讯开发:
新手入门贴:史上最全Web端即时通讯技术原理详解
Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
SSE技术详解:一种全新的HTML5服务器推送事件技术
Comet技术详解:基于HTTP长连接的Web端实时通信技术
新手快速入门:WebSocket简明教程
WebSocket详解(一):初步认识WebSocket技术
WebSocket详解(二):技术原理、代码演示和应用案例
WebSocket详解(三):深入WebSocket通信协议细节
WebSocket详解(四):刨根问底HTTP与WebSocket的关系(上篇)
WebSocket详解(五):刨根问底HTTP与WebSocket的关系(下篇)
WebSocket详解(六):刨根问底WebSocket与Socket的关系
socket.io实现消息推送的一点实践及思路
LinkedIn的Web端即时通讯实践:实现单机几十万条长连接
Web端即时通讯技术的发展与WebSocket、Socket.io的技术实践
Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)
开源框架Pomelo实践:搭建Web端高性能分布式IM聊天服务器
使用WebSocket和SSE技术实现Web端消息推送
详解Web端通信方式的演进:从Ajax、JSONP 到 SSE、Websocket
MobileIMSDK-Web的网络层框架为何使用的是Socket.io而不是Netty?
理论联系实际:从零理解WebSocket的通信原理、协议格式、安全性
>> 更多同类文章 ……

[6] 有关IM安全的文章:
即时通讯安全篇(一):正确地理解和使用Android端加密算法
即时通讯安全篇(二):探讨组合加密算法在IM中的应用
即时通讯安全篇(三):常用加解密算法与通讯安全讲解
即时通讯安全篇(四):实例分析Android中密钥硬编码的风险
即时通讯安全篇(五):对称加密技术在Android平台上的应用实践
即时通讯安全篇(六):非对称加密技术的原理与应用实践
传输层安全协议SSL/TLS的Java平台实现简介和Demo演示
理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享
简述实时音视频聊天中端到端加密(E2EE)的工作原理
移动端安全通信的利器——端到端加密(E2EE)技术详解
Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)
通俗易懂:一篇掌握即时通讯的消息传输安全原理
IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token
快速读懂量子通信、量子加密技术
>> 更多同类文章 ……

[7] 开源实时音视频技术WebRTC的文章:
开源实时音视频技术WebRTC的现状
简述开源实时音视频技术WebRTC的优缺点
访谈WebRTC标准之父:WebRTC的过去、现在和未来
良心分享:WebRTC 零基础开发者教程(中文)[附件下载]
WebRTC实时音视频技术的整体架构介绍
新手入门:到底什么是WebRTC服务器,以及它是如何联接通话的?
WebRTC实时音视频技术基础:基本架构和协议栈
浅谈开发实时视频直播平台的技术要点
[观点] WebRTC应该选择H.264视频编码的四大理由
基于开源WebRTC开发实时音视频靠谱吗?第3方SDK有哪些?
开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用
简述实时音视频聊天中端到端加密(E2EE)的工作原理
实时通信RTC技术栈之:视频编解码
开源实时音视频技术WebRTC在Windows下的简明编译教程
网页端实时音视频技术WebRTC:看起来很美,但离生产应用还有多少坑要填?
了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化
>> 更多同类文章 ……

[8] 实时音视频开发的其它精华资料:
即时通讯音视频开发(一):视频编解码之理论概述
即时通讯音视频开发(二):视频编解码之数字视频介绍
即时通讯音视频开发(三):视频编解码之编码基础
即时通讯音视频开发(四):视频编解码之预测技术介绍
即时通讯音视频开发(五):认识主流视频编码技术H.264
即时通讯音视频开发(六):如何开始音频编解码技术的学习
即时通讯音视频开发(七):音频基础及编码原理入门
即时通讯音视频开发(八):常见的实时语音通讯编码标准
即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述
即时通讯音视频开发(十):实时语音通讯的回音消除技术详解
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解
即时通讯音视频开发(十二):多人实时音视频聊天架构探讨
即时通讯音视频开发(十三):实时视频编码H.264的特点与优势
即时通讯音视频开发(十四):实时音视频数据传输协议介绍
即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况
即时通讯音视频开发(十六):移动端实时音视频开发的几个建议
即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生
实时语音聊天中的音频处理与编码压缩技术简述
网易视频云技术分享:音频处理与压缩技术快速入门
学习RFC3550:RTP/RTCP实时传输协议基础知识
基于RTMP数据传输协议的实时流媒体技术研究(论文全文)
声网架构师谈实时音视频云的实现难点(视频采访)
浅谈开发实时视频直播平台的技术要点
还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!
实现延迟低于500毫秒的1080P实时音视频直播的实践分享
移动端实时视频直播技术实践:如何做到实时秒开、流畅不卡
如何用最简单的方法测试你的实时音视频方案
技术揭秘:支持百万级粉丝互动的Facebook实时视频直播
简述实时音视频聊天中端到端加密(E2EE)的工作原理
移动端实时音视频直播技术详解(一):开篇
移动端实时音视频直播技术详解(二):采集
移动端实时音视频直播技术详解(三):处理
移动端实时音视频直播技术详解(四):编码和封装
移动端实时音视频直播技术详解(五):推流和传输
移动端实时音视频直播技术详解(六):延迟优化
理论联系实际:实现一个简单地基于HTML5的实时视频直播
IM实时音视频聊天时的回声消除技术详解
浅谈实时音视频直播中直接影响用户体验的几项关键技术指标
如何优化传输机制来实现实时音视频的超低延迟?
首次披露:快手是如何做到百万观众同场看直播仍能秒开且不卡顿的?
Android直播入门实践:动手搭建一套简单的直播系统
网易云信实时视频直播在TCP数据传输层的一些优化思路
实时音视频聊天技术分享:面向不可靠网络的抗丢包编解码器
P2P技术如何将实时视频直播带宽降低75%?
专访微信视频技术负责人:微信实时视频聊天技术的演进
腾讯音视频实验室:使用AI黑科技实现超低码率的高清实时视频聊天
微信团队分享:微信每日亿次实时音视频聊天背后的技术解密
近期大热的实时直播答题系统的实现思路与技术难点分享
福利贴:最全实时音视频开发要用到的开源工程汇总
七牛云技术分享:使用QUIC协议实现实时视频直播0卡顿!
实时音视频聊天中超低延迟架构的思考与技术实践
理解实时音视频聊天中的延时问题一篇就够
实时视频直播客户端技术盘点:Native、HTML5、WebRTC、微信小程序
写给小白的实时音视频技术入门提纲
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料:
开源移动端IM技术框架MobileIMSDK:快速入门
开源移动端IM技术框架MobileIMSDK:常见问题解答
开源移动端IM技术框架MobileIMSDK:压力测试报告
>> 更多同类文章 ……

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:通俗易懂:基于集群的移动端IM接入层负载均衡方案分享下一篇:请问服务端的login和dataserver通讯是用同步还是异步啊?

本帖已收录至以下技术专辑

推荐方案
评论 44
虽然设计并不完美,但干货很多,感谢原作者的无私分享
签名: 中年危机啊,肿么办
写的这么详细,太感谢了!
建立与接入层的连接(可能为短连接) >>短连接有啥优势?
签名: 该会员没有填写今日想说内容.
引用:charming 发表于 2017-05-12 15:34
建立与接入层的连接(可能为短连接) >>短连接有啥优势?

一般来说短连接就是说的HTTP了,HTTP这种标准服务好处太多了,基于http的负载均衡成熟方案一大把,还可以做成现在流行的所谓微服务,既然这样那为何还要混进IM协议里,还让其IM变的更复杂。总之好处多多,慢慢体会

评分

1

查看评分

签名: 《知乎从单机到2000万QPS并发的Redis高性能缓存实践之路》http://www.52im.net/thread-1968-1-1.html
引用:JackJiang 发表于 2017-05-12 15:44
一般来说短连接就是说的HTTP了,HTTP这种标准服务好处太多了,基于http的负载均衡成熟方案一大把,还可以 ...

谢谢楼主解答
签名: 该会员没有填写今日想说内容.
学习了
统一登录的地方  怎么避免单点故障?
引用:ztcjn 发表于 2017-05-13 18:02
统一登录的地方  怎么避免单点故障?

如果提炼成HTTP服务的话可以用Nginx这些东西
签名: 《知乎从单机到2000万QPS并发的Redis高性能缓存实践之路》http://www.52im.net/thread-1968-1-1.html
引用:JackJiang 发表于 2017-05-13 18:03
如果提炼成HTTP服务的话可以用Nginx这些东西

我的意思是  登录用户状态信息的存放
请问,app来拉取数据的时候,服务端是如何操作的?从mysql里面查的嘛?
签名: 该会员没有填写今日想说内容.
引用:nick_sw 发表于 2017-05-17 17:01
请问,app来拉取数据的时候,服务端是如何操作的?从mysql里面查的嘛?

可以这样,具体的架构可以自已按照现实情况去定,没有固定的套路
签名: 《知乎从单机到2000万QPS并发的Redis高性能缓存实践之路》http://www.52im.net/thread-1968-1-1.html
赞一个
感谢分享
很不错谢谢分享
签名: 哈哈哈
感谢方案,收益良多
签名: 该会员没有填写今日想说内容.
此方案中接入层和逻辑层是通过什么解耦的?mq还是rpc?
引用:sunnyhui2010 发表于 2017-07-13 22:05
此方案中接入层和逻辑层是通过什么解耦的?mq还是rpc?

要实时性好肯定是RPC,但主要看你的应用场景是看重性能还是实时性
签名: 《知乎从单机到2000万QPS并发的Redis高性能缓存实践之路》http://www.52im.net/thread-1968-1-1.html
学习学习
学习了 大神  
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部