即时消息技术剖析与实战
袁武林
微博研发中心技术专家
24187 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 25 讲
即时消息技术剖析与实战
15
15
1.0x
00:00/00:00
登录|注册

03 | 轮询与长连接:如何解决消息的实时到达问题?

总结
服务端推送
长轮询场景
短轮询场景
消息实时到达问题解决方案

该思维导图由 AI 生成,仅供参考

你好,我是袁武林。
我在前面第一篇文章中,从使用场景的需求方面,讲到了 IM 系统的几个比较重要的特性。其中之一就是“消息到达的实时性”。
实时性场景是所有的 IM 系统绕不开的话题,为了支持互联网的“实时互联”的概念,大部分的 App 都需要实时技术的支持。
我们现在使用的聊天类 App、直播互动类 App 都已经在实时性方面做得很好了,消息收发延迟基本都能控制在毫秒级别。
当然这一方面得益于快速发展的移动网络,让网络延迟越来越低、网络带宽越来越高;另一个重要原因是:社交网络 App 在实时性提升方面的技术,也在不断升级迭代。
实时性主要解决的问题是:当一条消息发出后,我们的系统如何确保这条消息最快被接收人感知并获取到,并且尽量让耗费的资源较少。这里关键的几个点是:最快触达,且耗费资源少。
想好了吗?下面我们来看一看,IM 在追求“消息实时性”的架构上,所经历过的几个代表性阶段。

短轮询场景

在 PC Web 的早期时代,对于数据的获取,大部分应用采用一问一答的“请求响应”式模式,实际上,像现在我们浏览大部分门户网站的新闻,以及刷微博其实都是采用的“请求响应”模式。
但这种依赖“手动”触发的模式,在即时消息系统中当有新消息产生时并不能很好地感知并获取到,所以明显不适用于对实时性要求高的场景。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

IM系统中的消息实时到达问题一直是一个重要的挑战。本文介绍了即时消息服务中是如何解决“消息实时性”这个难题。文章从短轮询、长轮询到服务端推送的演进过程中,介绍了不同阶段的技术架构和解决方案。短轮询模式通过高频率的轮询获取消息,但存在网络开销和服务端压力大的问题;长轮询模式通过延长轮询时间减少了无效轮询,但仍未解决服务端资源压力。随着HTML5的出现,WebSocket协议成为了服务端推送的解决方案,实现了双向通信和边缘触发,大幅降低了服务端轮询压力。此外,基于TCP长连接的IM协议如XMPP、MQTT等也被介绍,并指出了它们的优缺点。通过介绍不同阶段的技术演进,文章展示了IM系统中消息实时到达问题的解决方案,为读者提供了对实时性技术发展的全面了解。文章以技术演进的方式,生动地展现了IM系统中消息实时到达问题的解决方案,为读者提供了全面了解实时性技术发展的视角。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《即时消息技术剖析与实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(71)

  • 最新
  • 精选
  • 王棕生
    TCP 长连接的方式是怎么实现“当有消息需要发送给某个用户时,能够准确找到这个用户对应的网络连接”? 答: 首先用户有一个登陆的过程: (1)tcp客户端与服务端通过三次握手建立tcp连接;(2)基于该连接客户端发送登陆请求;(3)服务端对登陆请求进行解析和判断,如果合法,就将当前用户的uid和标识当前tcp连接的socket描述符(也就是fd)建立映射关系; (4)这个映射关系一般是保存在本地缓存或分布式缓存中。 然后,当服务端收到要发送给这个用户的消息时,先从缓存中根据uid查找fd,如果找到,就基于fd将消息推送出去。

    作者回复: 👍

    2019-09-02
    11
    88
  • 菜菜菜菜菜鸟
    TCP不是可靠的吗,为什么还需要在应用层实现ack,不应该是消息发出对方就一定可以收到的吗

    作者回复: 是个好问题。因为很多时候消息由tcp层交给应用层之后还可能出现丢失的情况,比如客户端落本地db失败了,类似这种。

    2019-09-02
    7
    33
  • 技术带头
    老师你好,我们也落地了一套im,服务端和本地都有存储,和用websoket。现在存在一个问题。群聊离线推送是将离线后产生的所有消息再用户上线的时候推送,还是客户端分页拉取

    作者回复: 可以考虑推拉结合,离线消息太多如果全部都推的话性能和带宽上都不太友好,可以离线推送一页,后续的再由客户端来拉取。

    2019-09-08
    23
  • yic
    客户端发送心跳包,一般多久一次比较合适? 我看老师有回复国内不超过5分钟,微信用的是4分半。这个时间有什么依据吗?

    作者回复: 以前有大厂测试过国内各家运营商的NAT超时情况,有的运营商在2/3G网络下NAT超时是5分钟。

    2019-09-08
    2
    18
  • 魏巍
    服务器端如果突然进程被kill掉,客户端如何及时得到通知并下线?

    作者回复: 进程kill是会对socket执行close操作的哈,所以客户端是能感知到的。真要是通过拔网线的方式把服务端网络断开,这种情况客户端在发送数据时就会失败,然后短连后重连其他服务器就可以了。

    2019-09-03
    2
    17
  • 飞翔
    服务器维护一个hashmap key是 userid,value 是socket instance, 这样 用户A 发给用户B的信息里边含有用户B 的id, 用usedBid 到hashmap 里边查到 用户B的socket 就可以用socket 发送信息给用户B了,老师我还有一个问题 就是如果一台机器连接数有限, 如果需要多台机器,如果用户A的socker 和用户B的socket 不在一台机器上,这样怎么解决呀

    作者回复: 一种做法是用户上线时维护一个全局的 uid->网关机 的映射,下发的时候就能做到精确定位;另一种方式是:下发时把所有消息下发给所有机器,每台机器如果发现当前用户连接在本机就下发,其他的就丢掉,这种会有一定的资源浪费。

    2019-09-02
    13
    16
  • 探索无止境
    老师你好,为什么说一台服务器可以最多可以支持1000万的连接请求,这个数值是怎么推算出来的?

    作者回复: 不具备读写操作仅仅只是维护静态连接的话基本上就是个拼内存的活,调整tcp单连接的读写缓冲区大小到4k,优化下其他系统参数比如句柄限制啥的,建连速度稍微慢点,有个200g内存是没问题的。这里其实想说的是,不要光看单机能维护多少连接,每秒收发包数这些才是关键。

    2019-10-01
    12
  • sam
    轮询就是前段定时请求,这个比较了解。但长轮询第一次听说,实际开发也没用过,特别是服务器的“悬挂(hang)”怎么理解? 是HTTP协议的机制吗?

    作者回复: 和http没关系哈,实现上比如接收到一个请求后,通过while循环判断,如果请求时间和当前时间的时间差没有到达超时阈值,就继续查询后端是否有新消息,直到超时或者查询到新消息。

    2019-09-03
    2
    9
  • 魏巍
    一个linux服务器可以接受多少tcp连接,如何量化这个数字?当业务层对持久化层操作响应慢时,为何客户端会频繁掉线?聊天数据的持久化与下发操作查库对数据库的读写压力如何缓解?实时聊天的数据库如果宕机,能否做自动切换数据库服务器的操作?

    作者回复: 连接数一般不是问题哈,服务端单机几百万上千万都可以的,受限于分配给每个连接的buffer占用的内存。业务层持久化会慢会导致客户端掉线这个没看懂呀,能具体一点吗?第三个问题可以做db的读写分离,第四个问题应该是说db的自动切主吧,这个是可以的哈,很成熟的方案。

    2019-09-03
    9
  • zombo
    老师请教一个区分,长连接是不是 "header: keep-alive" 的连接? 英文对应 persistent HTTP connection,但大家用得不多。而 webSocket 是HTML5才出来的,类似的机制,但各种浏览器支持得比较多。 因为机制和实现上,我好像看不出它们有太大的区别? 还是说 persistent HTTP 仍然是3次握手,websocket是一次?

    作者回复: 最大的区别在于websocket是支持全双工的,也就是说是可以由服务端主动进行推送的,http 1.1 的keep alive只是能够多次http请求复用同一个tcp连接,但只能由客户端发起请求。

    2020-03-13
    8
收起评论
显示
设置
留言
71
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部