君子生非异也

导航

 

一、RocketMQ集群

 

 RocketMQ集群由于无法选主,所以当Master挂了以后,slave需要手动切换master。这一点不好

二、RocketMQ为什采用NameSr,而不是zk

ZK是CP,NameSr是AP。RocketMQ选择了高可用。

RocketMQ的集群思想与Kafka有很大区别,在Kafka中borker这个概念分为Master和slave,可以通过zk选主进行切换和高可用。RocketMQ中Master对应的Borker 和 slave对应的borker是搭建环境的时候指定好的,他不需要选举。从这里可以看出Kafka的核心思想是通过主从切换保证集群的高可用。而RocketMQ是通过故障转移保证集群的高可用。例如:当RocketMQ中某个masterBorker挂了,那本来该发送到这个borker中对应队列的消息,此时将会被发送到其他Master上(对于普通消息)。

三、RocketMQ的顺序消息

全局顺序:就是我希望所有的消息你都给我按序消费,对应这样的消息我们可以创建topic时只分配一个队列。这样就失去了高可用的,高吞吐量的效果。

局部顺序:这类顺序消息很常见,我们就是根据一定的算法将同类型的消息路由到同一个队列中。发送消息,要实现 MessageQueueSelector 该接口,重写select()方法,按照自己的算法将相同类别的消息发送大同一个Queue中。

消费端处理: 如何保证消费端顺序消费?

  • MessageListenerOrderly(顺序消费):有序消费,同一队列的消息同一时刻只能一个线程消费,可保证消息在同一队列严格有序消费
  • MessageListenerConcurrently(并发消费):如果是使用该方式,则需要把线程池改为单线程模式。

四、消息重试的原理与死信队列

Producer

  • 如果是异步发送 那么重试次数只有1次
  • 对于同步而言,超时异常也是不会再去重试。
  • Product默认是2次;他是立即重试
  • 发送超时,不会重试

Consumer:

  • Consumer默认是16次
  • Consumer是有一定时间间隔的。它照1S,5S,10S,30S,1M,2M····2H进行重试。
  • Consumer在广播情况下重试失效

RocketMQ 规定,以下三种情况统一按照消费失败处理并会发起重试。

  • 业务消费方返回 ConsumeConcurrentlyStatus.RECONSUME_LATER
  • 业务消费方返回null
  • 业务消费方主动/被动抛出异常

RocketMQ 消费失败后会将消息加入到重试队列(设置重试消息的TOPIC, 重试队列名称为:%RETRY%+consumergroup),如果当前消息的重试次数大于最大重试次数,那么就开始走死信队列。 跟重试消息一样,也是设置死信队列的TOPIC %DLQ%+ 实际的消费组 ,我们可以对死性对了进行处理。但是在实际工作中我们一般重试三次,如果还是失败也给borker返回成功,同时我们会将该消息记录下来,后期补偿。

注意:RocketMQ消息重试功能需要区分事务消息、顺序消息、与普通消息。

  • 普通消息:该类型消息的重试,会触发故障转移,就是当第一次发送消息失败,重试发送会换一个borker。
  • 顺序消息:该类型消息重试,不会触发故障转移,就是一直往同一个borker上发送。

五、如何保证消息零丢失

生产者:

  • 同步发送: Producer 向 broker 发送消息,阻塞当前线程等待 broker 响应 发送结果。
  • 异步发送: Producer 首先构建一个向 broker 发送消息的任务,把该任务提交给线程池,等执行完该任务时,回调用户自定义的回调函数,执行处理结果。
  • Oneway发送: Oneway 方式只负责发送请求,不等待应答,Producer 只负责把请求发出去,而不处理响应结果。我们使用同步发送返送,并且捕获返回结果进行重试,可以减小消息发送丢失。

Conusmer:PushConsumer为了保证消息肯定消费成功,只有使用方明确表示消费成功,RocketMQ才会认为消息消费成功。中途断电,抛出异常等都不会认为成功——即都会重新投递。ConsumeConcurrentlyStatus.CONSUME_SUCCESS

brocker存储消息:采用同步刷盘模式,当刷盘成功后才返回producer投递消息成功。

六、如何保证消息的最终一致性

事务消息

  • 发送方向 MQ 服务端发送消息。该消息为prepare消息,即消费者不可见。
  • MQ Server 将消息持久化成功之后,向发送方 ACK 确认消息已经发送成功,此时消息为半消息。
  • 发送方开始执行本地事务逻辑。发送方根据本地事务执行结果向 MQ Server 提交二次确认(Commit 或是 Rollback),MQ Server 收到Commit 状态则将半消息标记为可投递,订阅方最终将收到该消息;MQ Server 收到 Rollback 状态则删除半消息,订阅方将不会接受该消息。
  • 在断网或者是应用重启的特殊情况下,上述步骤4提交的二次确认最终未到达 MQ Server,经过固定时间后MQ Server 将对该消息发起消息回查。发送方收到消息回查后,需要检查对应消息的本地事务执行的最终结果。发送方根据检查得到的本地事务的最终状态再次提交二次确认,MQ Server 仍按照步骤4对半消息进行操作。

 Producer Group:标识发送同一类消息的Producer,通常发送逻辑一致。发送普通消息的时候,仅标识使用,并无特别用处。若事务消息,如果某条发送某条消息的producer-A宕机,使得事务消息一直处于PREPARED状态并超时,则broker会回查同一个group的其 他producer,确认这条消息应该commit还是rollback。但开源版本并不支持事务消息。

七、Broker是怎么保存数据的

RocketMQ主要的存储文件包括commitlog文件、consumequeue文件、indexfile文件。

Broker在收到消息之后,会把消息保存到commitlog的文件当中,而同时在分布式的存储当中,每个broker都会保存一部分topic的数据,同时,每个topic对应的messagequeue下都会生成consumequeue文件用于保存commitlog的物理位置偏移量offset,indexfile中会保存key和offset的对应关系。

ommitLog文件保存于${Rocket_Home}/store/commitlog目录中,从图中我们可以明显看出来文件名的偏移量,每个文件默认1G,写满后自动生成一个新的文件。

 

由于同一个topic的消息并不是连续的存储在commitlog中,消费者如果直接从commitlog获取消息效率非常低,所以通过consumequeue保存commitlog中消息的偏移量的物理地址,这样消费者在消费的时候先从consumequeue中根据偏移量定位到具体的commitlog物理文件,然后根据一定的规则(offset和文件大小取模)在commitlog中快速定位。

 

 八、Master和Slave之间是怎么同步数据的呢?

而消息在master和slave之间的同步是根据raft协议来进行的:

  • 在broker收到消息后,会被标记为uncommitted状态
  • 然后会把消息发送给所有的slave
  • slave在收到消息之后返回ack响应给master
  • master在收到超过半数的ack之后,把消息标记为committed
  • 发送committed消息给所有slave,slave也修改状态为committed

九、RocketMQ为什么速度快

是因为使用了顺序存储、Page Cache和异步刷盘。

我们在写入commitlog的时候是顺序写入的,这样比随机写入的性能就会提高很多

写入commitlog的时候并不是直接写入磁盘,而是先写入操作系统的PageCache

最后由操作系统异步将缓存中的数据刷到磁盘

 
 
 
古之学者为己,今之学者为人
posted on 2021-04-18 13:07  徐知语的笔记  阅读(90)  评论(0编辑  收藏  举报