RocketMQ入门

本文为RocketMQ 入门文章，旨在帮助自己加深印象，帮助他人学习MQ。

文章内容来源《阿里RocketMQ-用户指南-V3.2.4》，结合了自己的一些理解如有错误望指正。大家也可自己阅读该文章。

一、专业术语：

Producer

消息生产者，负责产生消息

使用场景：一般由业务系统产生消息，如用户下单，就会产生一条消息

Consumer

消息消费者，负责消费消息

使用场景：一般由后台系统异步负责消费，如后台订单系统，消费订单消息

Producer Group

生产组，同一类Producer成为一个Group，这类Producer通常发送一类消息，发送逻辑一致（构成Producer集群）

使用场景：生产者集群产生同一类消息，如订单系统集群，使用同一个Producer Group，产生订单消息

Consumer Group

消费组，同一类Consumer成为一个Group，这类Consumer通常消费一类消息，消费逻辑一致（构成Consumer集群）

使用场景：消费者集群消费同一类消息，如后台订单系统，使用同一个Consumer，消费消息。

原则上，一个Producer（或Producer Group）只生产一类消息，一个Consumer（或Consumer Group）只负责消费一类消息。

Broker

消息中转角色，负责存储消息，转发消息，一般也称为Service。

通常可以认为Broker就是消息队列。

Topic

消息主题，标记一个消息大类

使用场景：业务系统（Producer）发送消息的时候，消息体中会标记Topic（如：TopicA），应用后台（Consumer）消费消息的时候，会订阅TopicA，只消费Topic为TopicA的消息，其他topic不会去消费。

Tag

消息标签，标记一个消息小类。Tag是在Topic下，对消息更细粒度的划分。先划分好消息大类（Topic），再划分消息标签(Tag)

使用场景：tag，可以起到在comsumer端过滤消息。业务系统（Producer）发送消息的时候，消息体中会标记Topic（如：“订单”），其中“订单“分为两类：“电脑订单”“手机订单”，移动订单系统后台，只负责处理“手机订单”，它需要订阅Topic“订单”，并对“手机订单”进行业务。“电脑订单”消息也会消费到，直接在comsumer端返回消费成功即可过滤。

消费模式：RocketMq分两种消费模式：广播消费、集群消费

广播消费

一条消息被多个Consumer消费， 即使这些 Consumer属于同一个Consumer Group，消息也会被  Consumer Group 中的每个Consumer 都消费一次，广播中的 Consumer Group 概念可以认为在消息划分方面无意义。

这个定义可能比较拗口，看下面的举例。

集群消费

一个Consumer Group中的Consumer实例平均分摊消费息。例如某个Topic有 9条消息，
其中一个Consumer Group有 3个实例（可能是3个进程，或者3台机器），那么每个实例只消费其中的 3条消息

举例：现在业务系统（Producer）往消息队列发送Topic为TopicA 编号为：0、1、2、3、4、5、6、7、8、9的消息，A、B、C三个应用消费消息队列中TopicA的消息（编号0-9），三个应用Consumer Group相同，则消费方式如下：

消费模式：广播消费，

A消费：0、1、2、3、4、5、6、7、8、9

B消费：0、1、2、3、4、5、6、7、8、9

C消费：0、1、2、3、4、5、6、7、8、9

消费模式：集群消费

A消费：0、1、2

B消费：3、4、5

C消费：6、7、8、9

以上例子可以区分，广播消费、集群消费

继续以上的例子，若此时有D、E、F三个应用也需要消费TopicA的消息，并且业务处理逻辑和A、B、C不同，则重新定义一个Consumer Group，则消费方式如下：

消费模式：集群消费

A消费：0、1、2

B消费：3、4、5

C消费：6、7、8、9

------------------------------

D消费：0、1、2

E消费：3、4、5

F消费：6、7、8、9

如上面举例说明的那样，同一个topic，不同的Consumer Group消费不会相互影响。

顺序消费
消费消息的顺序要同发送消息的顺序一致，在RocketMQ中，主要指的局部顺序，即一类消息为了满足
顺序性，必须Producer单线程顺序发送，且发送到同一个队列，这样consumer就可以按照Producer
发送的消息消费

普通顺序消息
顺序消息的一种，正常情况下可以保证完全的顺序消息，但是一旦发生通信异常，Brocker重启，
由于队列总数发生变化，哈希取模后定位的队列会变化，发生短暂的消息顺序不一致。
如果业务能容忍在集群异常情况（如某个Broker宕机或者重启）下，消息短暂的乱序，

使用普通顺序方式比较合适。

说明：以下是从别人文章里copy过来的。

RocketMQ通过轮询所有队列的方式来确定消息被发送到哪一个队列（负载均衡策略）。比如下面的示例中，订单号相同的消息会被先后发送到同一个队列中：

在获取到路由信息以后，会根据MessageQueueSelector实现的算法来选择一个队列，同一个OrderId获取到的肯定是同一个队列。

严格顺序消息
顺序消息的一种，无论正常异常情况都能保证顺序，但是牺牲了分布式Failover特性，
即Broker集群中只要有一台机器不可用，则整个集群都不可用，服务可用性大大降低。
目前已知的应用只有数据集binlog同步强制依赖严格顺序消息，其他应用绝大部分都可以容忍短暂乱序，推荐使用普通的顺序消息