自研分布式IM-HubuIM RFC草案

这篇具有很好参考价值的文章主要介绍了自研分布式IM-HubuIM RFC草案。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

HubuIM RFC草案

消息协议设计

基本协议

评估标准
  1. 【性能】协议传输效率,尽可能降低端到端的延迟,延迟高于200ms用户侧就会有所感知

  2. 【兼容】既要向前兼容也要向后兼容

  3. 【存储】减少消息包的大小,降低空间占用率,一个字节在亿级别并发之下也是一亿个字节

  4. 【计算】减少编解码时造成的CPU使用率的权衡

  5. 【网络】尽可能减少网络带宽消耗

  6. 【安全】协议安全性

  7. 【迭代】要能够快速迭代,灵活拓展

  8. 【通用】可跨平台接入,H5,IoT设备等等

  9. 【可读】

基本结构

IM协议的设计从纵向来看分为三个层次,应用层/安全层/传输层。

应用层

有很多开源协议,例如MQTT,websocket等等。但是这些协议冗余的字段比较多,在大型IM的场景下一般都是自定义协议的。

因此HubuIM采用自定义协议

序列化方式使用protobuf,这个是无可争议的。

安全层

基于密钥的生命周期可以分为

  • TLS/SSL:加密效果好,证书的管理比较复杂

  • 固定加密:通信前客户端和服务端约定好密钥和加密算法(会被黑客逆向)

  • 一人一密:使用用户特定的属性进行加密,例如密码

  • 一次一密:这个是最安全的,创建连接建立一次会话,双方进行加密三次握手(非对称),对称加密传输。

加密消耗的是CPU资源,是CPU密集型操作。如果放到接入层或者业务逻辑层来做的话,会影响到他们的正常运行。因此应该在四层网络负载或者七层网络负载的地方去解密,内网环境默认是安全的。

因此HubuIM采用的方式是TLS3.0+网关终止

自研分布式IM-HubuIM RFC草案,分布式

在Nginx处就进行解密,Nginx所在的机器可以使用硬件来进行优化,例如用GPU加速,用Intel加速器等等。

那么为什么不在LVS(四层网络负载均衡器)上面去做加密解密,然后直接发到IM网关,这样可以让网络通信少跳一次。

这个问题是因为Nginx这个七层负载均衡的地方相当于是公司的一个基础架构层,是要做很多事情的,不方便去掉的。

传输层

可以使用UDP或者TCP协议。微信这种很定义的可能使用UDP+QUIC这种保证可靠性。因为UDP是无状态的传输协议,不会存储连接的状态,在弱网环境下更优,消息风暴发生的可能性更小。

UDP的话需要在应用层写大量的代码来保证可靠性,难度非常大,因此HubuIM使用TCP协议。弱网环境在应用层来进行优化。

总结

HubuIM协议

对于传输层使用TCP,安全层使用TLS,应用层使用自研二进制协议+开源序列化协议。

既然使用了TCP协议,那么我们面临的一个问题就是TCP的粘包,拆包问题。具体解决方法我们在后面讲解。

消息可用性

基本概念

  • 长链接 vs 短链接。我们才用的是长链接和短链接共同作用,短链接作为旁路。

  • 各种ID

    • connID:代表的是一个TCP链接

    • clientID:代表的是client发送给IM Server的用来标识本客户端消息发送顺序的ID,仅仅是本客户端,该ID并不代表消息的全局一致。需要有递增性质。

    • seqID:当IM Server收到clientID之后生成的会话内消息顺序一致的seqID。需要有递增性质。

    • sessionID:会话ID

    • msgID:代表的是一个消息的ID

  • PULL 与 PUSH 模式。PULL就是client向IM Server拉取消息,使用短链接减少TCP链接的压力。PUSH就是IM Server通过TCP长链接推送消息。

  • 通信复杂度:网络传输过程中经过的节点可以说是一个性能瓶颈,不能经过太多节点。消息风暴就是网络中有太多的报文,会压垮IDC。常见于弱网环境,弱网下消息丢失严重,TCP的可靠性反而成为延迟,让网络中有大量的报文。

背景介绍

对于IM来说,消息的可靠与一致就是:可达有序,不重不漏。

有人会问:TCP已经保证一致性了,那么为什么IM还有保证一致。

其实答案很简单:TCP只能保证到内核传输层为止的可靠性,但是应用层的可靠性你是没有办法保证的。

设计IM必须有端到端的设计思维:底层可靠不等于上层可靠,底层一致不等于上层一致

方案选型

技术挑战是什么?

  • 三方通信,网络层面无法保证消息必达

  • 没有全局时钟,确定唯一顺序,并且是符合因果顺序的

  • 多客户发送/多服务端接收/多线程多协程处理,顺序难以确定。

解决方案是学习TCP:

  • 消息及时:服务端实时接收消息并实时在线发送

  • 消息可达:超时重试,ACK确认

  • 消息幂等:分配seqID,服务端存储seqID

  • 消息有序:seqID可以比较。

上行消息

clientID严格递增

弱网问题是传输层的问题,可以优化传输层协议,例如升级成Quic来优化,长连接不适合在弱网环境下工作。

消息转发
  • seqID在会话内有序就行,这样就可以解决redis的单点问题。

  • seqID需要在ACK之前分配,否则ACK成功发出去之后,服务器宕机了,这样seqID就等于没有分配,会出现问题。

  • 如果服务端在存储消息,业务处理,接入层路由的时候失败怎么办?

    • 消息存储之后再回复ACK,如果ACK失败则客户端重试时再次幂等的回复ACK。

    • 一旦消息存储,如果服务崩溃导致长连接断开,客户端重新建立连接时可以发送一个pull信令,拉去历史消息进行消息补洞,保证可靠性。

  • 消息存储可以交给MQ异步的进行。

下行消息

分配seqID的时候针对redis的单点使用lua脚本来进行一个ID的跳变。

客户端发现消息不连续的时候可能是因为消息跳变了,但是他无法确认,因此不能直接拒绝,而是发送pull信令来进行增补,如果拉去不到新消息则说明是跳变导致。

推拉结合+长短连接结合+服务端打包整流:假如是一个群聊,一下子有100M信息,我会把这些信息放在一个窗口里面,不会一个一个发送,这样的批处理可以提高效率。然后窗口大了之后服务端向客户端发送一个pull信令,让客户端发起一个请求来用短链接拉取这个窗口里面的数据。文章来源地址https://www.toymoban.com/news/detail-675629.html

到了这里,关于自研分布式IM-HubuIM RFC草案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【分布式】分布式锁

    单机多线程: 在 Java 中,我们通常使用 ReetrantLock 类、synchronized 这类 本地锁 来控制一个 JVM 进程内的多个线程对本地共享资源的访问 分布式系统: 不同的服务/客户端通常运行在独立的 JVM 进程上。如果 多个 JVM 进程共享同一份资源 的话,使用本地锁就没办法实现资

    2024年02月14日
    浏览(48)
  • 分布式系统中的分布式链路追踪与分布式调用链路

    本文分享自天翼云开发者社区《分布式系统中的分布式链路追踪与分布式调用链路》,作者:c****w 在分布式系统中,由于服务间的调用关系复杂,需要实现分布式链路追踪来跟踪请求在各个服务中的调用路径和时间消耗。这对问题排查和性能监控都很重要。 常用的分布式链

    2024年01月19日
    浏览(55)
  • 【分布式】分布式ID

    分布式场景下,一张表可能分散到多个数据结点上。因此需要一些分布式ID的解决方案。 分布式ID需要有几个特点: 全局唯一(必要) :在多个库的主键放在一起也不会重复 有序(必要) :避免频繁触发索引重建 信息安全 :ID连续,可以根据订单编号计算一天的单量,造成

    2024年02月07日
    浏览(49)
  • 【分布式】分布式存储架构

    说到分布式存储,我们先来看一下传统的存储是怎么个样子。 传统的存储也称为集中式存储, 从概念上可以看出来是具有集中性的,也就是整个存储是集中在一个系统中的,但集中式存储并不是一个单独的设备,是集中在一套系统当中的多个设备,比如下图中的 EMC 存储就需

    2024年02月10日
    浏览(49)
  • 高级分布式系统-第15讲 分布式机器学习--分布式机器学习算法

    高级分布式系统汇总:高级分布式系统目录汇总-CSDN博客 按照通信步调,大致可以分为同步算法和异步算法两大类。 同步算法下,通信过程中有一个显式的全局同步状态,称之为同步屏障。当工作节点运行到 同步屏障 ,就会进入等待状态,直到其工作节点均运行到同步屏障

    2024年01月18日
    浏览(43)
  • 分布式 - 谈谈你对分布式的理解,为什么引入分布式?

    不啰嗦,我们直接开始! 真正了解分布式系统的概念,日后工作中具有分布式系统设计思想。 能否在设计中对系统稳定性方面考虑周全。 能构建高 QPS 健壮的系统架构。 问题分析: 各种分布式框架层出不穷,Spring Cloud,阿里的 Dubbo,无论使用哪一个,原理都相同,考察下基

    2024年02月15日
    浏览(46)
  • 分布式系统面试全集通第一篇(dubbo+redis+zookeeper----分布式+CAP+BASE+分布式事务+分布式锁)

    什么是分布式 一个系统各组件分别部署在不同服务器。彼此通过网络通信和协调的系统。 也可以指多个不同组件分布在网络上互相协作,比如说电商网站 也可以一个组件的多个副本组成集群,互相协作如同一个组件,比如数据存储服务中为了数据不丢失而采取的多个服务备

    2024年04月11日
    浏览(46)
  • 【分布式】分布式共识算法 --- RAFT

    CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance) It states, that though its desirable to have Consistency, High-Availability and Partition-tolerance in every system, unfortunately no system can achieve all three at the same time. 在分布式系

    2024年02月06日
    浏览(47)
  • Redis与分布式-分布式锁

    接上文 Redis与分布式-集群搭建 为了解决上述问题,可以利用分布式锁来实现。 重新复制一份redis,配置文件都是刚下载时候的不用更改,然后启动redis服务和redis客户。 redis存在这样的命令:和set命令差不多,但是它有一个机制,当指定的key不存在的时候,才能进行插入,实

    2024年02月07日
    浏览(45)
  • 分布式爬虫架构-对等分布式(2)

    前言 本文是该专栏的第45篇,后面会持续分享python爬虫干货知识,记得关注。 在面对海量数据的采集需求时,使用分布式爬虫是非常有必要的。继上一篇,详细介绍主从分布式爬虫架构,对主从分布式相关知识感兴趣的同学,可往前翻阅。而本文,笔者再单独来详细介绍分布

    2023年04月25日
    浏览(52)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包