rocketmq的基础认识

一、rocketmq安装问题：

1）java版本问题

2）内存问题

image-20211206183600644

二、控制台

官方仓库

历史版本、rocketmq-console.

mvn打包，启动。

java -jar rocketmq-console-ng-1.0.1.jar --rocketmq.config.namesrvAddr=127.0.0.1:9876

效果：

image-20211206193908634

发送消息测试：

./tools.sh org.apache.rocketmq.example.quickstart.Producer

三、基础认识

架构

image-20211206200328050

为什么要用MQ？

解耦、异步、削峰（即使请求到达峰值，也不会被压垮）。

消息模型

Message：要传输的消息必须有一个主题，一条消息也可以有一个可选的Tag和额外的键值对，可以设置一个业务的key，便于开发中在broker服务端查找消息。

Topic：消息的第一级类型，主题就是我们具体的业务，比如一个电商系统可以有订单消息，商品消息，采购消息，交易消息等。Topic和生产者和消费者的关系非常松散，生产者和Topic可以是1对多，多对1或者多对多，消费者也是这样。

Tag：消息的第二级类型，比如采购消息分为采购创建消息，采购审核消息，采购推送消息，采购入库消息，采购作废消息等，这些消息是同一Topic和不同的Tag，当消费端只需要采购入库消息时就可以用Tag来实现过滤，不是采购入库消息的tag就不处理。

Group: 组，可分为Producer Group生产者组合Consumer Group消费者组，一个组可以订阅多个Topic。一般来说，某一类相同业务的生产者和消费者放在一个组里。

Message Queue：消息队列是消息的物理管理单位，当发送消息的时候，Broker会轮询包含该Topic的所有消息队列，然后将消息发出去。

顺序消息

producer -> broker FIFO

消息过滤

broker过滤、Consumer过滤

消息去重

如果由于网络等原因，多条重复消息投递到了Consumer端，你怎么进行消息去重？

消息的幂等性原则：用户对同一操作发起的多次请求结果是一样的，不会因为操作了多次就产生不一样的结果。只要保持幂等性，不管来多少条消息，最后处理结果都一样，需要Consumer端自行实现。

去重：MessageId

分布式事务消息

image-20211206204702234

半消息：是指暂时还不能被Consumer消费的消息，Producer成功发送到broker端的消息，但是此消息被标记为“暂不可投递”状态，只有等Producer端执行完本地事务后经过二次确认了之后，Consumer才能消费此条消息。

4：如果是Commit，Broker端将半消息标记为正常消息，Consumer可以消费，如果是Rollback，Broker丢弃此消息。

5：异常情况，Broker端迟迟等不到二次确认。在一定时间后，会查询所有的半消息，然后到Producer端查询半消息的执行情况。

5，6，7是消息回查

如何保证消息不丢失

producer: 分布式消息投递方式、同步发送

broker：消息持久化到CommitLog、刷盘机制（异步: 消息达到Broker内存后就返回Producer数据已经发送成功，会唤醒一个线程去将数据持久化到CommitLog日志文件中、同步: p发送消息后等消息持久化到磁盘再响应P，这里说同步才比异步多10%）、多主多从

consumer: Consumer自身维护了个持久化的offset，用来标记已经成功消费且已经成功发回Broker的消息下标。如果Consumer消费失败，它会向Broker发回消费失败的状态，发回成功才会更新自己的offset。

负载均衡

Producer端，每个实例在发消息的时候，默认会轮询所有的message queue发送，以达到让消息平均落在不同的queue上。而由于queue可以散落在不同的broker，所以消息就发送到不同的broker下

consumer端

1）集群模式：平均分配、环形分配

集群模式下，queue都是只允许分配只一个实例，这是由于如果多个实例同时消费一个queue的消息，由于拉取哪些消息是consumer主动控制的，那样会导致同一个消息在不同的实例下被消费多次，所以算法上都是一个queue只分给一个consumer实例，一个consumer实例可以允许同时分到不同的queue。

2）广播模式