消息中间件 - RocketMQ 详解（从软件安装到案例实现）

内容

参考博文：https://www.cnblogs.com/xiaoxiongcanguan/p/11510366.html

---

一、RocketMQ 安装

博客地址：Windows 下安装 RocketMQ

博客地址：Linux 下安装 RocketMQ

二、 RocketMQ 作用和结构

1. RocketMQ 特点

RocketMQ 是阿里巴巴开源的分布式消息中间件。支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。它里面有几个区别于标准消息中件间的概念，如Group、Topic、Queue等。系统组成则由Producer、Consumer、Broker、NameServer等。

2 RocketMQ 执行流程

3. RocketMQ 作用

3.1 消息中间件结构图

3.2 应用解耦

微服务架构中，存在着众多子系统，共同完成对外部用户的服务。同时用户的一个下单行为横跨了N个业务子系统，如果按照传统的同步串行方式一个接一个的调用，用户的下单操作将会执行较长的时间，对用户不友好。同时，由于是同步调用，一旦某一个子系统出现了宕机，访问超时等问题，整个下单业务都将陷入瘫痪。
消息队列可以将同步的系统调用转为异步的消息投递，一定程度上解除业务子系统间的耦合。

3.3 削峰填谷

  大多数系统的访问流量并不是一天24小时均匀稳定的，而是存在着一定的突发性。例如电商的秒杀活动，系统配置在平时能承受住500qps，可在进行秒杀活动时，瞬时的qps可能达到了5000，为平常的10倍，如果不进行处理防护，将会导致服务瘫痪。
　　可以选择扩容服务器来应对可能的高峰流量，但扩容的服务器在秒杀活动过去之后多数会被闲置，从而造成很大的浪费；也可以设定并发的阈值，在访问并发数达到一定程度时就进行熔断限流，拒绝手慢的秒杀用户下单，可这样会让用户体验很差。
　　这时，消息队列就能派上用场了。我们可以在系统中使用消息队列作为缓冲，将每一个用户下单请求都作为一条消息存入消息队列，消息队列会根据消费者的消费速度以一种稳定的方式将流量传递给下游消费者系统，在消费者系统处理完下单操作后异步的通知用户下单结果。虽然用户可能会延迟一段时间才能得到反馈，但无论如何也比无法下单要好。
　　消息队列就像一个漏桶，可以将瞬时的尖峰流量缓存起来，并以一种稳定的速度传递给下游消费者，从而达到流量削峰的目的。

4. rocketmq 组成部分

rocketmq由四大核心模块组成：producer、consumer、brokerServer、nameServer。其中brokerServer和nameServer是rocketmq的服务端，两者一起独立的对外提供服务；而producer和consumer可看做是rocketmq的客户端，一般依附于业务应用程序。

1. Producer
   【1】producer负责发送消息。使用producer将消息发送到brokerServer，由brokerServer统一进行消息的分发。
   【2】rocketmq支持多种消息发送方式，如同步消息发送、异步回调消息发送、顺序消息发送以及一次性消息发送(异步无回调)。除了一次性消息发送，其余的发送方式均需要brokerServer返回发送结果的确认消息。
   【3】特别的是，rocketmq的一大特色是支持发送事务消息(半消息)，能一定程度上解决分布式事务的问题。

2. Consumer
   【1】consumer 负责消费producer发送的消息。consumer会从brokerServer获取消息，并传递给应用程序。
   【2】rocketMQ使用的消息原语是At Least Once(至少一次成功消费)，如果一定时间内没有接收到consumer消息确认消费的响应结果，会将同一条消息再次投递给consumer。rocketmq采用ack机制保证消息的消费成功，所以consumer可能会多次收到同一条消息，需要consumer的业务方做好幂等防护。
   【3】使用者的角度来看，consumer分为两种方式来获取信息。一种是推模式(push consume)，推模式看起来像是brokerServer将消息推给了consumer；另一种是拉模式(pull consume)，拉模式看起来像是consumer主动的去brokerServer拉取消息(实际上，推模式是基于拉模式实现的)。

3. BrokerServer
   【1】brokerServer负责消息的接收，存储和分发，是rocketmq最核心，最重量级的组成部分。
   【2】为实现高可用和高吞吐，brokerServer通常采用集群部署，共同对外提供服务。

4. NameServer
   【1】nameServer负责提供路由元数据。例如，brokerServer通常是集群部署的，其拓扑结构会经常的发生变化。如果每次集群中broker机器的上下线都需要通知所有的消费者、生产者，效率太低。
   【2】因此，rocketmq引入了nameServer作为brokerServer路由信息的维护者，broker的每次上下线都和nameServer通信，由nameServer来维护broker的路由信息，而producer和consumer通过访问nameServer获得对应broker的访问地址后，再向对应的broker发起请求。nameServer解除了broker和客户端的耦合依赖关系，大大提高了效率。
   【3】在其它主流消息队列中也存在着类似的维护元信息功能的组件，如zookeeper等。rocketmq的设计者认为zk的功能过于强大，杀鸡焉用牛刀，通过一个精简版的元数据服务nameServer，以减少对外部系统的耦合依赖，得以提供更可靠的服务。
   【4】nameServer同样能以集群形式对外提供服务。但和zk集群不同的是，集群内的nameServer服务器并不会互相通信，而是保持相互独立。
   
   

5. rocketmq基本概念模型

介绍完rocketmq的组成部分之后，还需要再引入一些相关概念才能更好的理解rocketmq：

1. topic 主题
   topic主题，代表一系列消息的集合，任何消息只能属于一个topic主题，主题是rocketmq进行消息发布订阅的最小单位。业务方可以通过创建并订阅各式各样的主题来满足自身的业务要求。不同主题之间的消息在逻辑上没有关联。

2. tag 标签
   tag标签，tag从属于topic主题，主要用于对同一主题下的消息进行进一步区分。标签可以简单的认为是二级主题，通过tag标签功能，业务