加入收藏 | 设为首页 | 会员中心 | 我要投稿 辽源站长网 (https://www.0437zz.com/)- 云专线、云连接、智能数据、边缘计算、数据安全!
当前位置: 首页 > 服务器 > 搭建环境 > Windows > 正文

分布式消息系统的设计要点

发布时间:2019-09-05 21:34:23 所属栏目:Windows 来源:小姐姐味道
导读:分布式缓存方面,redis勇夺花魁。但对于消息队列mq来说,还处于百花齐放的年代。 缓存系统,基本上解决一个存取问题,就万事大吉了,调用是同步的。对于消息队列来说,就不太一样。它的使用场景多样,可靠级别多变,从生产端到消费端,过程是异步的。 消息
副标题[/!--empirenews.page--]

分布式缓存方面,redis勇夺花魁。但对于消息队列mq来说,还处于百花齐放的年代。

分布式消息系统的设计要点

缓存系统,基本上解决一个存取问题,就万事大吉了,调用是同步的。对于消息队列来说,就不太一样。它的使用场景多样,可靠级别多变,从生产端到消费端,过程是异步的。

消息系统的设计要点,有很多。现在,很难有一个消息系统,能够兼顾下面提到的设计要点。它要是说可以,那就是母体在吹。

所以很多时候,现在流行的Kafka、RabbitMQ、RocketMQ等,会被同时使用。如果你在做相关方面的选型,下面这些技术点就是权衡之处。那句话叫什么来着:牝鸡司晨,惟家之索。

要点

本文将针对这些mq,从整体上抽象一些共有特性。包括:协议、类型、消费方式、堆积能力、高可用、高可靠、高性能、扩展性和生态。如果你想要深入某个mq,这里也有几篇关于kafka的文章。

高可用

分布式消息系统的设计要点

高可用主要解决集群单节点,在异常情况下的failover和HA。解决高可用问题的一般思路就是副本机制。

通过增加副本,可以将数据的风险分散到多台机器上。这就需要在主分片出现问题时,能够从副本中找出一个作为新的主分片。有很多这样的协调工具,比如zk。也有的mq,自己去实现这个过程。

有的模式就比较浪费资源了,比如rocketmq,使用standby从机进行高可用保证,出问题再顶上来。

高可靠

分布式消息系统的设计要点

消息系统的可靠性和性能是相悖的。一般的mq,可靠性级别都是可以调节的,但性能会发生相反的联动性。从消息级别来说,大体路线有:

发出去就不管了->单节点确认->多节点确认->多节点确认同步刷盘->所有节点同步刷盘->事务消息等。

单机高可靠

集群的高可靠方面,会有ack机制和多副本机制进行保证。对于单个节点来说,断电或者主机异常,会是一个比较大的挑战。为了处理这种情况,需要有刷盘机制或者其他持久化机制。同时,数据的完整性校验也是需要的,这也是类似kafka这种消息系统,数据量大的时候,启动时间非常长的原因。

生产端

生产端除了要考虑buffer丢失的问题,还要考虑到一些发送错误的情况,包括与集群通信的超时和重试处理。

消费端

消费端通过消息确认机制来保证消息已经被正确消费。由于其间会发生很多异常情况,所以大多数消息系统保证at least once语义。即确保消息至少被消费1次。

言外之意,消息是会重复的,消费者需要做到幂等,保证重复消费不会引起业务异常。

消费端同样会发生一些错误情况,有些mq可以在多次消费失败后自动进入死信队列,有些mq需要自行设计topic进行规划。

高性能

分布式消息系统的设计要点

作为一个数据传输的通道,性能是一个非常有分量的考量点。其中两个比较重要的指标,一个是消息的延迟性,一个就是消息的吞吐量。

消息从生产端发出,到消费者处理,其间的过程不能太长,对于使用拉模式来消费的mq来说,就要加快轮询速度,并使用零拷贝一类的技术加快数据传输。

对于消息吞吐量来说,是一个生产端、mq节点、消费端共同优化的结果。目前主要有以下手段:

异步化

消息采用异步发送的方式,发送端不用同步等待,加快了处理速度。

batch

采用批量发送的方式,减少网络传输的次数,方便进行数据压缩。一般是内存中缓冲一个buffer,如果buffer满了,或者到达了时间窗口,则进行一次传输。这能够显著增加传输速度,但处理不当容易丢失数据。

顺序IO

xjjdog已经在多篇文章提到,顺序性操作磁盘,比随机操作内存速度快的多。这也是kafka之类的消息队列速度快的原因之一,但要注意主题的数量(想下为什么)。

另外,还有其他手段。比如优化操作系统参数,使用分片增加并行度等。

消息类型

分布式消息系统的设计要点

消息有点对点的,一条消息只会被消费一次。Pub/Sub通过发布/订阅模式,一条消息能够被多个消费端消费。还有一种消息是通过广播模式进行广播,即producer发送消息,所有的consumer都会收到。

除了普通发送的消息,还有一些特殊用途的消息。顺序性消息有全局有序和分区有序之分,一般用于有严格顺序要求的业务。通过业务的设计,可以规避全局有序这种非常耗性能的操作。

有些mq还支持定时消息(私以为这种放业务系统更佳)。事务消息更加耗费性能,慎用。

还有一些mq,提供打tag、进行消息过滤的功能。比如订单信息发送到一个topic,消费者只订阅相关商品的订单,某些有求隔离的情况,非常有用。

消费模式

分布式消息系统的设计要点

消费模式,主要有推模式和拉模式。拉模式最为实用和流行,因为消费处理速度可以由消费端进行调节。

推模式的实时性更好一些,但不好评估消费端能力,容易将其压垮。同时,处理pub/sub,失败重试等,也有很多挑战。

协议

分布式消息系统的设计要点

大家都知道java中有一个JMS规范,但是类似于kafka这种却没有实现这个规范。所以一些协议,比如amqp、openwire等,有更加明显的定制型。

这个传输协议,与功能关系不大。比如就有基于http协议的,或者redis协议,甚至websocket之上的stomp。

mqtt是物联网IoT的应用协议,你会发现一大坨基于它的消息队列。

(编辑:辽源站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

推荐文章
    热点阅读