本文介绍了RocketMQ的基本概念，如消息、主题、标签和队列，强调了MQ在应用解耦、异步处理和削峰填谷等方面的优势，同时讨论了其劣势。文章深入探讨了RocketMQ的系统架构，包括NameServer、Broker的角色和集群模式，并详细描述了双主双从集群的搭建步骤，包括环境配置、防火墙设置、环境变量、存储路径创建、配置文件修改和启动脚本。RocketMQ是阿里巴巴开源的高性能消息队列，已在多个双十一活动中证明了其稳定性和高吞吐量。
目录
(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
最低0.47元/天 解锁文章
7068
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
