《即时消息技术剖析与实战》 学习笔记 day6

后端要努力
77 阅读6分钟

大家好，我是砸锅。一个摸鱼八年的后端开发。熟悉 Go、Lua。今天和大家一起学习 IM 系统😊

复杂网络下消息通道高可用设计

消息的通道主要承载两部分流量：一部分是用户发出的消息或者触发的行为，我们称为上行消息；一部分是服务端主动下推的消息和信令，我们称为下行消息

通过 HttpDNS 来返回多个接入点 IP 来解决连通性问题，失败一个就尝试下一个

让消息通道连接更快的方式：

  1. 通过解决跨网延迟来避免通道连接过慢。需要有多运营商机房的接入点，避免运营商 DNS 解析转发和 NAT 导致接入 IP 被解析到其他运营商的问题。很多 IDC 机房都支持多线运营商接入
  2. 通过跑马竞速来选择最快的通道接入。APP 通过对返回的接入点 IP 列表中所有 IP 进行竞速测试，并将测速结果上报到服务端，服务端根据这个测速结果来动态调整接入点 IP 列表的顺序，让用户优先选择最优接入点

https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/98d07e0e8f584a5bb3e02fdb4e29378b~tplv-k3u1fbpfcp-zoom-1.image

让消息通道保持稳定的方式：

  1. 通道和业务解耦。因为消息收发是严重依赖长连接通道的，所以不能跟着业务变更而不断调整重启，这样会降低消息收发的成功率和用户体验，所以通道层只负责网络连接管理和通用的逻辑处理。将用户与连接的映射维护、通信协议的编解码、建立连接逻辑处理、ACK 包和心跳包处理等放在业务处理层

  2. 上下行通道隔离。用户上行的消息和行为通过一个短连通道发送到服务端。这样既能避免客户端维护多个长连接的开销，也能解决上行通道被下推消息影响的问题

    https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d6f37de13ad94d48b25c4811d73f1935~tplv-k3u1fbpfcp-zoom-1.image

  3. 独立多媒体上传下载。单独开辟一条新的连接通道来传输二进制的文件流，保护消息收发的核心通道不受影响，还能缩短上传下载的链路

图片和视频优化

针对不同的主流运营商提供不同的上传接入点 IP，然后通过运营商 DNS 解析，让用户能通过本运营商的上传接入点来快速上传图片和视频；相应后端的图片上传存储服务，也可以部署在多线机房，这样上传服务也能快速地把文件流提交给存储层，从而避免从接入点到存储服务的跨网开销，也能解决其他运营商的用户下载图片时需要跨网的问题

发送多媒体消息时，先通过独立通道上传文件流，上传完成后会返回文件的唯一标识 ID，然后再把这个唯一标识 ID 作为消息的引用，通过普通消息收发通道进行发送

https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d0b7377217b049caa04b638e73924c3d~tplv-k3u1fbpfcp-zoom-1.image

分片上传，是指“在客户端把要上传的文件按照一定规则，分成多个数据块并标记序号，然后再分别上传，服务端接收到后，按照序号重新将多个数据块组装成文件。对于图片、视频、语音等这种较大的消息来说，采用分片上传可以让客户端在分片完成后，利用“并行”的方式来同时上传多个分片，从而提升上传效率

采用“分片”的方式，可以在上传失败后进行重试时，不必重新上传整个文件，而只需要重传某一个失败的分片，这样也能提升重新发送的成功率和性能；此外，类似语音这种流式消息，在上传时并不知道文件最终大小，采用分片上传可以让消息文件先部分上传到服务器，而没必要等到录制完才开始上传，这样也能节约上传的整体时长

通过长连下推的方式将语音流推到对端，这样用户在播放语音时就不需要再从远程临时下载文件，使用流畅度也会更好。IM 服务端在接收到分片后，可以同步先行把分片的二进制流下推给接收方但暂不显示，不需要等所有分片都在后端存储完成再进行下推。这样的好处是：当语音的最后一片到达后端并存储完成后，IM 服务端只需要给接收方推一条“所有分片存储完成”的轻量信令，即可让接收方马上看到这条语音消息。这个“分片先行下推”机制在实时性上比远程临时下载的方式更好，能有效降低语音聊天的延时

CDN 加速

通过 CDN（Content Delivery Network，内容分发网络）对图片和音视频进行加速，来提升用户播放体验

CDN 加速技术，就是将客户端上传的图片、音视频发布到多个分布在各地的 CDN 节点的服务器上，当有用户需要访问这些图片和音视频时，能够通过 DNS 负载均衡技术，根据用户来源就近访问 CDN 节点中缓存的图片和音视频消息，如果 CDN 节点中没有需要的资源，会先从源站同步到当前节点上，再返回给用户

通过这种资源冗余的方式，既能显著提高用户访问的响应速度，也能有效缓解服务器访问量过大带来的对源存储服务的读写压力和带宽压力

如果是一些高热度的资源，没有缓存资源的时候会从源站获取再缓存，这样缓存命中率很低，源站的带宽和存储压力会增大。所以需要提前强制CDN 节点回源并获取最新文件。大部分 CDN 都支持这个功能，通过 CDN 服务提供的 API 接口，把需要预热的资源地址和需要预热的区域等信息提交上去，CDN 收到后，就会触发这些区域的边缘节点进行回源来实现预热

边下边播

在播放器下载完视频的格式信息、关键帧等信息后，播放器其实就可以开始进入播放，同时结合 HTTP 协议自带支持的 Range 头按需分片获取后续的视频流，从而来实现边下边播和拖动快进，需要支持两个前提条件：

  1. 格式信息和关键帧信息在文件流的头部
  2. 服务端支持 Range 分片获取

系统推送

iOS 端的 APNs（Apple Push Notification service，苹果推送通知服务），是独立于应用之外，依托系统常驻进程来维护和苹果服务器的公共长连接，负责全局的系统推送服务

在 Android 端上，有 Google 的 GCM（Google Cloud Message，Google 云消息传递）。国内 Android 的系统级下发通道基本都是厂商通道，目前已知的有 5 家：小米、华为、vivo、OPPO、魅族

此文章为3月Day12学习笔记，内容来源于极客时间《即时消息技术剖析与实战》 这门课真的非常好，推荐大家看看

avatar
文章
阅读
粉丝