这是我参与更文挑战的第22天，活动详情查看： 更文挑战
前言：
消息队列是一种“先进先出”的数据结构，其优点主要有以下几点：
- 应用解耦：系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。
- 流量削峰：应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理，这样可以大大提到系统的稳定性和用户体验。
- 数据分发：通过消息队列可以让数据在多个系统更加之间进行流通。数据的产生方不需要关心谁来使用数据，只需要将数据发送到消息队列，数据使用方直接在消息队列中直接获取数据即可。
- 异步通知：例如一个用户发生下单请求后，需要对当前订单进行支付，锁库存，发物流等一系列操作，同步进行可能会需要很长的时间去执行这一系列流程，这个时候就可以通过mq异步通知，我们不需要等待其他服务执行完成只需要发生一个mq通知就可以返回结果集，剩下的操作进行异步实现，极高的提高了用户体验度。 缺点：
- 系统可用性降低：系统引入的外部依赖越多，系统稳定性越差。一旦MQ宕机，就会对业务造成影响。需要我们去保证mq的高可用；
- 系统复杂度提高：MQ的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过MQ进行异步调用。如何保证消息没有被重复消费？怎么处理消息丢失情况？那么保证消息传递的顺序性；
- 一致性问题：A系统处理完业务，通过MQ给B、C、D三个系统发消息数据，如果B系统、C系统处理成功，D系统处理失败。如何保证消息数据处理的一致性？
RocketMQ
RocketMQ是一个纯Java、分布式、队列模型的开源消息中间件，前身是MetaQ，是阿里参考Kafka特点研发的一个队列模型的消息中间件，后开源给apache基金会成为了apache的顶级开源项目，具有高性能、高可靠、高实时、分布式特点。项目地址
架构组成：
他主要有四大核心组成部分：NameServer、Broker、Producer以及Consumer四个部分。
- NameServer：主要负责对于源数据的管理，包括了对于Topic和路由信息的管理。
- Producer：消息生产者，负责产生消息，一般由业务系统负责产生消息。
- Broker：消息中转角色，负责存储消息，转发消息。
- Consumer：消息消费者，负责消费消息，一般是后台系统负责异步消费。
Producer发送消息：
- 同步发送：同步发送指消息发送方发出数据后会在收到接收方发回响应之后才发下一个数据包。一般用于重要通知消息，例如重要通知邮件、营销短信。
- 异步发送：异步发送指发送方发出数据后，不等接收方发回响应，接着发送下个数据包，一般用于可能链路耗时较长而对响应时间敏感的业务场景，例如用户视频上传后通知启动转码服务。
- 单向发送：单向发送是指只负责发送消息而不等待服务器回应且没有回调函数触发，适用于某些耗时非常短但对可靠性要求并不高的场景，例如日志收集。
Consumer消费消息：
- 支持PUSH和PULL两种消费模式，支持集群消费和广播消息，提供实时的消息订阅机制。
Pull：拉取型消费者（Pull Consumer）主动从消息服务器拉取信息，只要批量拉取到消息，用户应用就会启动消费过程，所以 Pull 称为主动消费型。
Push：推送型消费者（Push Consumer）封装了消息的拉取、消费进度和其他的内部维护工作，将消息到达时执行的回调接口留给用户应用程序来实现。所以 Push 称为被动消费类型，但从实现上看还是从消息服务器中拉取消息，不同于 Pull 的是 Push 首先要注册消费监听器，当监听器处触发后才开始消费消息。
消息领域模型
- Message：Message（消息）就是要传输的信息。
- Topic：Topic（主题）可以看做消息的规类，它是消息的第一级类型。
- Tag（标签）可以看作子主题，它是消息的第二级类型，用于为用户提供额外的灵活性。
- Group：分组，一个组可以订阅多个Topic。分为ProducerGroup，ConsumerGroup，代表某一类的生产者和消费者，一般来说同一个服务可以作为Group，同一个Group一般来说发送和消费的消息都是一样的； Queue：Message Queue（消息队列），主题被划分为一个或多个子主题，即消息队列。
ok！今天的文章就到这了，希望可以对大家有帮助，有不对的地方希望大家可以提出来的，共同成长;
整洁成就卓越代码，细节之中只有天地
