摘自:
RocketMQ 介绍及基本概念_fFee-ops的博客-优快云博客_rocketmq
RocketMQ详细配置与使用_一名小码农的博客-优快云博客_rocketmq
一,MQ介绍
消息队列是一种先进先出的数据结构,其应用场景主要有三个方面
(1)应用解耦:系统的耦合性越高,容错性就越低,以电商应用为例子,用户创建订单以后,如果耦合调用库存系统,物流系统,支付系统,。如果这期间任何一个系统出故障,都会造成该次下单操作的异常,进而影响购物的正常进行。如果使用了消息队列,就降低了系统的耦合性。此时如果物流系统发生了故障,那么不会影响其他系统的正常运行,在物流系统的故障期间,物流系统要处理的数据被缓存在消息队列中,等到物流系统故障恢复后,在补充处理存储在消息队列中的消息即可。
(2)流量削峰:应用系统如果遇到系统请求流量的瞬间猛增,有可能会将系统击垮,有了消息队列以后,可以将大量的流量缓存起来,分散到一段时间内进行处理,这样降低了流量的瞬间压力,大大提升了系统的稳定性和用户的体验。
(3)数据分发:通过消息队列可以让数据在多个系统之间进行流通,数据的产生方不必关心谁来使用数据,只需要将数据发送到消息队列,数据使用方在消息队列直接获取即可。
二 消息队列的缺点
(1)系统可用性降低:系统引入的外部依赖越多,系统的稳定性就越差,一旦MQ系统宕机,就会对业务造成影响,所以引来的问题就是如何保证MQ系统的高可用性。
(2)系统的复杂度提高:MQ系统的加入大大增加了系统的复杂度,以前系统间是同步的远程调用,现在是使用MQ进行一步调用,如何保证消息的不重复使用,如何保证消息的不丢失,如何保证消息的顺序性都是需要处理的问题。
(3)一致性问题:A系统处理完业务,通过MQ给B,C,D三个系统发数据,如果B系统,C系统处理成功,D系统处理失败,如何保证数据处理的一致性。
RocketMQ介绍
RocketMQ作为一款纯java,分布式,队列模型的开源消息中间件,支持事务消息,顺序消息,批量消息,定是消息,消息回溯等功能。RocketMQ支持发布订阅,和点对点模型,在一个队列中支持可靠的先进先出和严格的顺序传递,支持pull和push两种消息分发模式,RocketMQ提供亿级消息的堆积能力,而且在堆积了亿级的消息后依然可以保持写入低延迟。支持配置指标监控等功能丰富的dashboard。
RocketMQ的组成主要是四个核心部分,NameServer,Broker,Producer,Consumer.下面分别进行介绍。
Nameserver:这是一个几乎无状态的节点,可以集群部署,节点之间没有任何信息同步。NameServer是整个MQ的大脑,他是RockerMQ的服务注册中心。用来保存Broker相关的原信息,并且给Producer和Consumer查找Broker。NameServer被设计成无状态的,可以随意扩展的,节点之间没有通信的,可以通过部署多台的方式来表示自己是一个伪集群。NameServer就是保存一些运行的数据,而且需要broker来连接nameserver,这样一来保证了nameserver很轻量级。Broker在启动时向所有的NameServer来进行注册,生产者在发送消息之前先从NameServer中获取Broker的地址列表,然后根据负载均衡算法从中选择一台服务器进行消息的发送。NameServer与每一台Broker服务保持长连接,并且间隔30S检查下Broker是否存活,如果检测到Broker宕机,则从路由表中删除Broker,进而实现RockerMQ的高可用性能。
Broker:消息服务器是消息存储中心,主要作用是用来接收Producer的消息,并进行存储,Consumer也可以从这里获取消息进行消费。它还存储与消息相关的元数据,包括用户组,消费进度偏移量,队列信息等。从部署结构中可以看出Broker有主从两种类型,主即可以读有可以写,从只可以读。Broker的部署相对复杂,一个master可以对应多个slave,但是一个slave只能对用一个master,master与slave的对应关系是通过指定相同的brokername来实现的,broker的部署方式有四种,单Master,多Master,多Master多slave(同步刷盘),多master多slave(异步刷盘)。单master就是只有一台机器,且为master.多master就是有多台机器,且都为master。这种情况下,单台机器宕机,该机器上的未被消费的消息在机器没有恢复之前不能被消费,消息的实时性收到印象。多Master多slave(异步复制),每个master都配置一大个slave,所以有多对master-slave组合,消息采用异步复制方式,主备之间有毫秒级消息延迟,这种方式的优点是消息的丢失非常小,且实时性不受影响,Master宕机后消息的消费可以继续从slave消费,中间的过程对用户应用程序是透明的,不需要人工干预,性能同多master方式几乎一样,缺点是master宕机后磁盘在损坏的情况下丢失少量消息。多master多slave(同步双写),每个master配置一个slave,所以有多对master-slave组合,消息采用同步双写方式进行,主备都成功才返回成功,这种方式的优点是数据与服务都没有单点问题,master宕机是消息无延迟,服务与数据的可用性非常高,缺点是性能低,发送消息的延迟略高。为了保证高可用,每个broker都与nameserver集群中的所有节点建立场链接,每个一定时间注册topic中的消息到nameserver,nameserver定是扫描所有存活的broker。如果超过2分钟没有收到心跳,就断开连接。
生产者(Producer)也称为消息的发布者,负责生产消息并且发送至Topic,生产者向Broker发送又业务应用程序系统生成的消息,消息可以同步发送,异步发送,单向发送等等。同步发送就是指消息发送方发出数据后会在收到对方发回响应后才继续发送下一条消息,一般用于重要的的消息通知,异步发送就是消息发送者在发出消息后不需要等待对方发回确认就可以继续发送系一条消息,一般用于业务链路较长而对时间响应不敏感的情况下。例如用户视频上传后通知启动转码服务,单向发送就是指发送者只负责发送消息而不等待服务器响应且没有回调函数触发,适用于某些耗时非常短,且对可靠性要求不高的场景,例如日志收集。生产者组就是一类producer的集合,这一类集合通常发送一类消息并且发送的逻辑一致,所以将这些生产者分组在一起,从部署结构上看生产者通过生产者组的名字来标记自己是一个集群。为了达到高可用的目的,生产者与nameserver集群中的其中一个节点建立长连接,定期从nameserver获取路由信息,并且向topic服务的master建立长连接,定时发送心跳。注意,生产者向nameserver和broker这两者都会建立长连接。