目录
(5) 创建消息存储路径(master与slave指定的储存路径名字不能相同)
一、定义
MQ全称为Message Queue, 消息队列(MQ)是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息(针对应用程序的数据)来通信,而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信,直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。
请求方向响应方发送数据请求
弊端:如果说响应方/也就是服务方中间网络断掉
传统项目架构下两个项目进行通讯的弊端。
MQ全称Message Queue (消息队列),是在消息的传输过程中保存消息的容器。多用于分布式系统之间进行通信。 队列:数据结构的一种,特征为“ 先进先出”
二、MQ的优势和劣势
优势
1,应用解耦
2,异步提速
3,削峰填谷
劣势:
1,系统可用性降低
2,系统复杂度提高
3,一致性问题
1.应用解耦
消费方存活与否不影响生产方
什么叫解耦,一个程序与另一个程序他的耦合度要降低,高内聚,低耦合,应用解耦,系统的耦合性越高,容错性就越低,可维护性就降低。
订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。 库存系统:订阅下单的消息,采用拉/推的方式,获取下单信息,库存系统根据下单信息,进行库存操作。
假如,在下单时库存系统不能正常使用。也不影响正常下单,因为下单后,订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。
2.异步提速
以用户注册后,需要发注册邮件和注册短信为例,使用传统方式时,我们会将注册信息写入数据库成功后,发送注册邮件同时发送注册短信。当这些任务完成后,返回给客户端。
当使用消息队列,可以将不是必须的业务逻辑,进行异步处理。用户的响应时间相当于是注册信息写入数据库的时间,注册邮件、发送短信写入消息队列后,直接返回,因此用户的响应时间非常的快。
3. 削峰填谷
流量削锋也是消息队列中的常用场景,一般在秒杀或团抢活动中使用广泛。如,秒杀活动中,一般会因为流量过大,导致流量暴增,应用挂掉。
举个例子,如果订单系统最多能处理一万次订单,这个处理能力应付正常时段的下单时绰绰有余,正常时段我们下单一秒后就能返回结果。但是在高峰期,如果有两万次下单操作系统是处理不了的,只能限制订单超过一万后不允许用户下单。使用消息队列做缓冲,我们可以取消这个限制,把一秒内下的订单分散成一段时间来处理,这时有些用户可能在下单十几秒后才能收到下单成功的操作,但是比不能下单的体验要好。
为解决这个问题,一般需要在应用前端加入消息队列。这样以来可以控制活动的人数,可以缓解短时间内高流量压垮应用。
三、MQ的劣势
系统的可用性降低
系统引入的外部依赖越多,系统的稳定性越差。一旦MQ宕机,就会对业务产生影响,如何保证MQ的高可用
(在系统中引入了MQ的组件,这个组件玩意坏了,那么整个系统是不是全崩掉了,只有引入了新的组件,那么必然对系统的可用性降低了)。
系统复杂度提高
MQ的加入大大增加了系统的复杂度,以前系统间是同步的远程调用,现在是通过MQ进行异步调用,如何保证消息没有被重复消费,怎么处理消息丢失情况?如何保证消息传递的顺序性?
一致性问题
A系统处理完业务,通过MQ给B,C,D,三个系统发送消息数据,如果B系统,C系统处理成功,D系统处理失败,如何保证消息数据处理的一致性。
四、常用的MQ产品
RabbitMQ RabbitMQ是使用ErLang语言开发的一款MQ产品。 其吞吐量较Kafka 与RocketMQ要低,且由于其不是Java语言开发,所以公司内部对其实现定制化开发难度较大。
Kafka Kafka是使用Scala/Java语言开发的一款MQ产品。其最大的特点就是高吞吐率,常用于大数据领域的实时计算、日志采集等场景。其没有遵循任何常见的MQ协议,而是使用自研协议。对于Spring CloudNetflix,其仅支持RabbitMQ与Kafka。
RocketMQ RocketMQ是使用Java语言开发的一款MQ产品。经过数年阿里双1 1的考验,性能与稳定性非常高。其没有遵循任何常见的MQ协议,而是使用自研协议。
1.MQ常见协议
一般情况下MQ的实现是要遵循一-些常规性协议的。常见的协议如下:
JMS JMS, Java Messaging Service (Java消息服务)。是Java平台上有关MOM (Message的技术规范,它便于消息系统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口,简化企业应用的开发。ActiveMQ是该协议的典型实现。
STOMP STOMP, Streaming Text Orentated Message Protocol,是一一种MOM设计的简单文本协议。STOMP提供-个可互操作的连接格式,允许客户端与任意STOMP消息代理进行交互。ActiveMQ是该协议的典型实现,RabbitMQ通过插件可以支持该协议。
AMQP AMQP, Advanced Message Queuing Protocol,一个提供统一 消息服务的应用层标准,是应用层协议的-个开放标准,是一种MOM设计。基于此协议的客户端与消息中间件可传递消息,并不受客户端/中间件不同产品,不同开发语言等条件的限制。RabbitMQ是该协议的典型实现
五、RocketMQ简介
1.基本概念
消息(Message)
消息是指,消息系统所传输信息的物理载体,生产和消费数据的最小单位,每条消息必须属于一个主题。
主题(Topic)
Topic表示一类消息的集合,每个主题包含若干条消息,每条消息只能属于一个主题,是RocketMQ进行消息订阅的基本单位。 topic:message 1:n message:topic 1:1
一个生产者可以同时发送多种Topic的消息;而一个消费者只对某种特定的Topic感兴趣,即只可以订阅 和消费一种Topic的消息。 producer:topic 1:n consumer:topic 1:1
标签
为消息设置的标签,用于同一主题下区分不同类型的消息。来自同一业务单元的消息,可以根据不同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连贯性,并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑,实现更好的扩展性。
Topic是消息的一级分类,Tag是消息的二级分类。
Topic:货物
tag=上海
tag=江苏
tag=浙江
- 消费者 -----
topic=货物 tag = 上海
topic=货物 tag = 上海|浙江
topic=货物 tag = *
队列
存储消息的物理实体。一个Topic中可以包含多个Queue,每个Queue中存放的就是该Topic的消息。一个Topic的Queue也被称为一个Topic中消息的分区(Partition)。
一个Topic的Queue中的消息只能被一个消费者组中的一个消费者消费。一个Queue中的消息不允许同一个消费者组中的多个消费者同时消费。
RocketMQ中每个消息拥有唯一的MessageId,且可以携带具有业务标识的Key,以方便对消息的查询。不过需要注意的是,MessageId有两个:在生产者send()消息时会自动生成一个MessageId(msgId),当消息到达Broker后,Broker也会自动生成一个MessageId(offsetMsgId)。msgId、offsetMsgId与key都称为消息标识。
msgId:由producer端生成,其生成规则为:producerIp + 进程pid + MessageClientIDSetter类的ClassLoader的hashCode +当前时间 + AutomicInteger自增计数器
offsetMsgId:由broker端生成,其生成规则为:brokerIp + 物理分区的offset(Queue中的偏移量)
key:由用户指定的业务相关的唯一标识
2.系统架构
Producer
消息生产者,负责生产消息。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投 递,投递的过程支持快速失败并且低延迟。
例如,业务系统产生的日志写入到MQ的过程,就是消息生产的过程
再如,电商平台中用户提交的秒杀请求写入到MQ的过程,就是消息生产的过程
RocketMQ中的消息生产者都是以生产者组(Producer Grou