消息队列

消息队列的作用

异步

解耦

限流/削峰

RocketMQ

数据模型

image-20240806220601713

生产者生产消息，消费者消费消息。

消费者订阅topic来获取消息推送

生产者生产后的消息放到每一个topic对应的队列中，队列可能有多个，这是为了尽可能的保证并发性

生产者会维护当前消费者消费消息的位置，不同的消费者的消费位置不同，这也促使着每一个topic使用多个队列

每一个topic并不是固定存储在某个特定的固定的位置，而是分布式的存储在多个broker中，每一个broker都可以包含多个topic的分片。

多broker是为了尽可能减少某些broker的压力

为了使得生产者、消费者能够得到对应的broker，出现了NameServer，注册中心，消费者和生产者会根据NameServer给出的路由信息来到对应的Broker中生产和消费消息。

消息类型：

普通消息

定时消息

顺序消息

消费者类型

PushConsumer

高度封装的消费者类型，消费消息仅仅通过消费监听器监听并返回结果。消息的获取，消费状态提交以及消费的重试都通过RocketMQ的客户端SDK完成

SimpleConsumer

SimpleConsumer 是一种接口原子型的消费者类型，消息的获取、消费状态提交以及消费重试都是通过消费者业务逻辑主动发起调用完成。

PullConsumer

消费者和生产者分组

生产者分组，RocketMQ，5.x版本后，生产者是匿名的，无需管理生产者分组

消费者分组

消费者分组时多个消费行为一致的消费者的负载均衡分组，消费者分组不是具体实体而是一个逻辑资源。通过消费者分组实现消费性能的水平扩展以及高可用容灾。

顺序消费和重复消费

顺序消费

顺序消费又分为普通顺序消费和强制顺序消费。强制的意思是说即便在异常情况下也能够保证消息消费的顺序性，实际可用性很低，更多的是用在比如binlog同步数据场景（？how

顺序消费：保证消息的前后顺序性，这里其实是要保证需要顺序的消息能够放到同一个队列中即可。可用hash取模的方式

特殊情况：消费发送失败可重试，默认重试两次

重复消费

解决重复消费问题的本质做法是保证消息消费的幂等性，即对于同一个消息的处理结果，执行多少次都不变

消息堆积问题

RocketMQ刷盘机制

同步刷盘和异步刷盘

同步刷盘：消息写入磁盘后再返回成功

异步刷盘：消息写入则返回成功

同步复制和异步复制

同步复制：消息既写入到从节点又写入主节点才算返回成功

异步复制：消息写入主节点后就返回成功。此时有主从复制问题：对于一主多从的架构中，我们很难保证数据的严格有序性，当主节点挂掉，其他从节点无法代替主节点，向其中写入数据，即便此时选举出主节点也可能因为新主节点消息和旧主节点消息不一致，导致存在一些顺序性问题，对此RocketMQ采用Dledger来解决此问题，但是并不能完全解决，Dledger认为消息复制至少到半数以上的节点，才会给客户端消息写入成功。

RocketMQ存储机制

采用了CommitLog和ConsumeQueue两个数据结构

CommitLog就是顺序写入的数据，里面包含了很多topic的消息，按照顺序写入，写满了就写入下一个文件，单文件默认大小为1G

ConsumeQueue就是记录了某个topic下的消息在CommitLog中的物理偏移量，消息大小以及消息tag的hash值，这样能够快速的从CommitLog中找到我们需要的消息。