| RocketMQ底层设计与原理 | 您所在的位置：网站首页 › rocketmq底层数据结构 › RocketMQ底层设计与原理 |
RocketMQ底层设计与原理
|
RocketMQ的消息模型
消息模型 Message Model
RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个Consumer 实例构成。 消息 Message消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题。RocketMQ中每个消息拥有唯一的Message ID，且可以携带具有业务标识的Key。系统提供了通过Message ID和Key查询消息的功能。 主题 Topic表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。 Topic 与生产者和消费者的关系非常松散，一个 Topic 可以有0个、1个、多个生产者向其发送消息，一个生产者也可以同时向不同的 Topic 发送消息。 一个 Topic 也可以被 0个、1个、多个消费者订阅。 标签 Tag为消息设置的标志，用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的扩展性。 分组 Group分为ProducerGroup，ConsumerGroup，代表某一类的生产者和消费者，一个组可以订阅多个Topic。 ProducerGroup代表同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。 ConsumerGroup代表同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。 队列 Queue在Kafka中叫Partition，每个Queue内部是有序的，在RocketMQ中分为读和写两种队列，一般来说读写队列数量一致，如果不一致就会出现很多问题。 消费位移 Offset在RocketMQ 中，所有消息队列都是持久化，长度无限的数据结构，所谓长度无限是指队列中的每个存储单元都是定长，访问其中的存储单元使用Offset 来访问，Offset 为 java long 类型，64 位，理论上在 100年内不会溢出，所以认为是长度无限。也可以认为 Message Queue 是一个长度无限的数组，Offset 就是下标。
一个主题存在多个队列，生产者每次生产消息后向指定主题中的某个队列发送消息。在集群消费模式下，一个消费者集群的多个消费者共同消费一个Topic的多个队列，一个队列只会被一个消费者消费，如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。一般来讲要控制消费者组中的消费者个数和主题中队列个数相同 ，当然也可以消费者个数小于队列个数，只不过不太建议。 同时每个消费者组在每个队列上维护一个消费位移offset 在发布订阅模式中一般会涉及到多个消费者组，而每个消费者组在每个队列中的消费位置都是不同的。如果此时有多个消费者组，那么消息被一个消费者组消费完之后是不会删除的（因为一个Topic可以被多个消费者订阅，那么其它消费者组也需要呀），它仅仅是为每个消费者组维护一个 消费位移(offset) ，每次消费者组消费完会返回一个成功的响应，然后队列再把维护的消费位移加一，这样就不会出现刚刚消费过的消息再一次被消费了。 为什么一个主题中需要维护多个队列 提高并发能力可以从生产者、消费者两个方面来解释。倘如一个主题Topic只有一个队列，这样生产者只能向一个队列发送消息，并且由于一个队列只能对应消费者组中的一个消费者（因为需要维护消费位移），这样该消费者组中的其他消费者便失去用武之地。 RocketMQ 通过使用在一个 Topic 中配置多个队列并且每个队列维护每个消费者组的消费位置 实现了 主题模式/发布订阅模式 如何解决消息重复问题首先分析引起重复消费的原因： 1、ACK （网络因素） 正常情况下在consumer真正消费完消息后应该发送ack，通知broker该消息已正常消费。当ack因为网络原因无法发送到broker，broker会认为此条消息没有被消费，此后会开启消息重投机制把消息再次投递到consumer。 2、消费模式 在CLUSTERING集群消费模式下，消息在broker中会保证相同group的consumer消费一次，但是针对不同group的consumer会推送多次。 消息去重去重原则：使用业务端逻辑保持幂等性 幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用，数据库的结果都是唯一的，不可变的。 只要保持幂等性，不管来多少条重复消息，最后处理的结果都一样。 RocketMQ无法避免消息重复（Exactly-Once），所以如果业务对消费重复非常敏感，务必要在业务层面进行去重处理。可以借助关系数据库进行去重。首先需要确定消息的唯一键，可以是msgId，也可以是消息内容中的唯一标识字段，例如订单Id等。在消费之前判断唯一键是否在关系数据库中存在。如果不存在则插入，并消费，否则跳过。（实际过程要考虑原子性问题，判断是否存在可以尝试插入，如果报主键冲突，则插入失败，直接跳过） msgId一定是全局唯一标识符，但是实际使用中，可能会存在相同的消息有两个不同msgId的情况（消费者主动重发、因客户端重投机制导致的重复等），这种情况就需要使业务字段进行重复消费。 如何保证消息的顺序消费首先Topic内的queue队列满足FIFO先进先出原则，本身就是顺序的，但多个queue同时消费并无法保证消息有序。那么此时我们只要保证将一类消息（如一个订单的创建、支付、完成）固定发送至同一queue队列即可。 那么如何保证消息发送至同一queueRocketMQ提供了MessageQueueSelector接口，可以重写接口的select方法，定义自己的选择策略。 比如使用Hash取模法，让同一个订单发送到同一个队列中，再使用同步发送，只有同个订单的创建消息发送成功，再发送支付消息，这样我们保证了发送有序。 Producer端 for (int i = 0; i @Override public MessageQueue select(List mqs, Message msg, Object arg) { Long id = (Long) arg; //根据订单id选择发送queue long index = id % mqs.size(); return mqs.get((int) index); } }, orderList.get(i).getOrderId());//订单id } Consume端 consumer.registerMessageListener(new MessageListenerOrderly() { Random random = new Random(); @Override public ConsumeOrderlyStatus consumeMessage(List msgs, ConsumeOrderlyContext context) { context.setAutoCommit(true); for (MessageExt msg : msgs) { // 可以看到每个queue有唯一的consume线程来消费, 订单对每个queue(分区)有序 System.out.println("consumeThread=" + Thread.currentThread().getName() + "queueId=" + msg.getQueueId() + ", content:" + new String(msg.getBody())); } try { //模拟业务逻辑处理中... TimeUnit.SECONDS.sleep(random.nextInt(10)); } catch (Exception e) { e.printStackTrace(); } return ConsumeOrderlyStatus.SUCCESS; } }); RocketMQ如何保证消息不丢失首先在如下三个部分都可能会出现丢失消息的情况： Producer端Broker端Consumer端 Producer端如何保证消息不丢失 采取send()同步发消息，发送结果是同步感知的。发送失败后可以重试，设置重试次数。默认2次。producer.setRetryTimesWhenSendFailed(10); 集群部署，比如发送失败了的原因可能是当前Broker宕机了，重试的时候会发送到其他Broker上。 Broker端如何保证消息不丢失 修改刷盘策略为同步刷盘。默认情况下是异步刷盘的。flushDiskType = SYNC_FLUSH 集群部署，主从模式，高可用。 Consumer端如何保证消息不丢失 完全消费正常后在进行手动ack确认。 消息刷盘机制Broker 在消息的存取时直接操作的是内存（内存映射文件），这可以提供系统的吞吐量，但是无法避免机器掉电时数据丢失，所以需要持久化到磁盘中。 刷盘的最终实现都是使用NIO中的 MappedByteBuffer.force() 将映射区的数据写入到磁盘 同步刷盘：在Broker把消息写到CommitLog映射区后，便进行持久化。只有在消息真正持久化至磁盘后RocketMQ的Broker端才会真正返回给Producer端一个成功的ACK响应。同步刷盘对MQ消息可靠性更好，但是性能上会有较大影响。 异步刷盘：能够充分利用OS的PageCache的优势，只要消息写入PageCache即可将成功的ACK返回给Producer端。消息刷盘采用后台异步线程提交的方式进行，降低了读写延迟，提高了MQ的性能和吞吐量。 分布式事务常见的分布式事务实现有 2PC(两阶段提交）、TCC 和事务消息(half 半消息机制)。每一种实现都有其特定的使用场景，但是也有各自的问题，都不是完美的解决方案。 RocketMQ 使用 事务消息（half半消息）加上事务消息回查机制 来解决分布式事务问题的 Half Message 半消息是指暂不能被Consumer消费的消息。Producer 已经把消息成功发送到了 Broker 端，但此消息被标记为暂不能投递状态，处于该种状态下的消息称为半消息。需要 Producer对消息的二次确认后，Consumer才能去消费它。当broker收到此类消息后，会存储到RMQ_SYS_TRANS_HALF_TOPIC的消息消费队列中 事务消息回查由于网络波动，生产者应用重启等原因。导致 Producer 端一直没有收到对 Half Message(半消息) 进行二次确认。这时Broker会开启一个定时任务，从Topic为RMQ_SYS_TRANS_HALF_TOPIC中拉取消息进行消费，主动向Producer消息发送者确认事务执行状态（提交、回滚、未知），根据事务状态来决定是提交或回滚消息。如果是未知，Broker会定时去回调在重新检查，如果超过回查次数（超时），默认回滚消息。
分为两个流程：正常事务消息的发送及提交、事务消息的补偿流程。 1、事务消息发送及提交： (1) 发送消息（half半消息）。 (2) 服务端响应消息写入结果。 (3) 根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）。 (4) 根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见） 2、补偿流程（回查）： (1) 对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查” (2) Producer收到回查消息，检查回查消息对应的本地事务的状态 (3) 根据本地事务状态，重新Commit或者Rollback 其中，补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。 事务消息在一阶段对用户不可见事务消息相对普通消息最大的特点就是一阶段发送的消息对用户是不可见的。RocketMQ事务消息的做法是：如果消息是half消息，将备份原消息的主题与消息消费队列，然后改变主题为RMQ_SYS_TRANS_HALF_TOPIC。由于消费组未订阅该主题，故消费端无法消费half类型的消息，然后Broker会开启一个定时任务，从Topic为RMQ_SYS_TRANS_HALF_TOPIC中拉取消息进行消费，根据生产者组获取一个服务提供者发送回查事务状态请求，根据事务状态来决定是提交或回滚消息。若Commit，则恢复原消息的主题与队列，重新发送到Broker，消费端感知后消费。 参考资料中文官方文档 看完保送阿里的RocketMQ知识点（超详细）_敖丙-CSDN博客 JavaGuide/RocketMQ.md at master · Snailclimb/JavaGuide (github.com) RocketMQ在面试中那些常见问题及答案 (qq.com) |
【本文地址】