| 失效链接处理 |
|
rockermq基础入门 PDF 下载
本站整理下载：
提取码：a3oo
相关截图：
主要内容
一、MQ介绍
1、为什么要用MQ
消息队列是一种“先进先出”的数据结构。
其应用场景主要有以下3个方面
1.1 应用解耦
系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流
系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，
影响用户使用体验。
高耦合的系统，如上图，如果其中物流系统出现问题，可能会导致整个订单系统都会瘫痪，这是我们最
不愿意看到的。
使用消息队列解耦合，系统的耦合性就会降低，比如物流系统发生故障，需要几分钟才能恢复，在这段
时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统恢复后，
补充处理存在消息队列中的订单消息即可，中断系统感知不到物流系统发生过几分钟故障。
1.2 流量消峰
应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大量请求缓存
起来，分散到很长一段时间处理，这样可以大大提高系统的稳定性和用户体验。
一般情况下，为了保证系统的稳定性，如果系统负载超过阈值，就会阻止用户请求，这会影响用户体
验，而如果使用消息队列请求缓存起来，等待系统处理完毕后通知用户下单完毕，这样总不能下单体验
要好。
业务系统正常时段的QPS如果是1000，流量最高峰是10000，为了应对流量高峰配置高性能的服务器显
然不划算，这时可以使用消息队列对峰值流量消峰。
1.3 数据分发
通过消息队列可以让数据在多个系统之间进行流通。数据的产生方不需要关心谁来是会用数据，只需要
将数据发送到消息队列，数据使用方直接在消息队列中直接获取数据即可。
2、MQ的优点和缺点：
优点：
解耦、消峰、数据分发
缺点：
系统可用性降低：
系统引入的外部依赖越多，系统稳定性就越差，一旦MQ宕机，就会对业务产生影响。如何保证高
可用？
系统复杂度提高：
MQ的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过MQ进行异步调
用。如何保证消息没有被重复消费？怎么处理消息丢失情况？那么保证消息传递的顺序性？
一致性问题
A系统处理完业务，通过MQ给B、C、D三个系统发消息数据，如果B系统、C系统处理成功，D系
统处理失败。如何保证消息数据处理的一致性。
3、各种MQ产品的比较
常见MQ产品包括Kafka、ActiveMQ、RabbitMQ、RocketMQ。
特性
ActiveMQ RabbitMQ RockerMQ Kafka
开发语言
java erlang java scala
单机吞吐量
万级 万级 10万级 10万级
时效性
ms级 us级 ms级 ms级以内
可用性
高（主从架构） 高（主从架构） 非常高（分
布式） 非常高（分布式）
功能特性
成熟的产品，在很
多公司得到应用；
有较多的文档；各
种协议支持较好。
基于erlang开发，所
以并发能力很强，性
能极其好，延时很
低，管理页面丰富。
MQ功能比
较完备，扩
展性佳
只支持主要的MQ功能，
像一些消息查询，消息回
溯等功能没有提供，毕竟
是为大数据准备的，在大
数据领域应用广。
4、RockertMQ简介
RockerMQ是阿里巴巴2016年MQ中间件，使用Java语言开发，在阿里内部，RockerMQ承接了例如“双
11”等高并发场景的消息流转，能够处理万亿级别的信息。
5、RockertMQ的基本概念
消息模型（Message Model）
RockertMQ主要由Producer、Broker、Consumer三部分组成，其中Producer负责生产消息，
Consumer负责消费消息，Broker负责存储消息。Broker在实际部署过程中对应一台服务器，每
个Broker可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的Broker。
Message Queue用于存储消息的物理地址，每个Topic中的消息地址存储于多个Message Queue
中。ConsumerGroup由多个Consumer实例构成。
消息生产者（Producer）
负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发
送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。
同步和异步方式均需要Broker返回确认信息，单向发送不需要。
消息消费者（Consumer）
负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并
将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。
主题（Topic）
表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行
消息订阅的基本单位。
代理服务器（Broker Server）
消息中转角色，负责存储消息、转发消息。代理服务器在RocketMQ系统中负责接收从生产者发送
来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据，包括消
费者组、消费进度偏移和主题和队列消息等。
名字服务（Name Server）
名称服务充当路由消息的提供者。生产者或消费者能够通过名字服务查找各主题相应的Broker IP
列表。多个Namesrver实例组成集群，但相互独立，没有信息交换。
拉取式消费（Pull Consumer）
Consumer消费的一种类型，应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、
主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程。
推动式消费（Push Consumer）
Consumer消费的一种类型，该模式下Broker收到数据后会主动推送给消费端，该消费模式一般实
时性较高。
生产者组（Producer Group）
同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致。如果发送的是事务消息
且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或
回溯消费。
消费者组（Comsumer Group）
同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在
消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必
须订阅完全相同的Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费
（Broadcasting）。
集群消费（Clustering）
集群消费模式下,相同Consumer Group的每个Consumer实例平均分摊消息。
广播消费（Broadcasting）
广播消费模式下，相同Consumer Group的每个Consumer实例都接收全量的消息。
普通顺序消息（Normal Ordered Message）
普通顺序消费模式下，消费者通过同一个消费队列收到的消息是有顺序的，不同消息队列收到的消
息则可能是无顺序的。
严格顺序消息（Strictly Ordered Message）
严格顺序消息模式下，消费者收到的所有消息均是有顺序的。
消息（Message）
消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题。
RocketMQ中每个消息拥有唯一的Message ID，且可以携带具有业务标识的Key。系统提供了通过
Message ID和Key查询消息的功能。
标签（Tag）
为消息设置的标志，用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不
同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连贯性，并优化
RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的
扩展性。
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
