RocketMQ初探

最新推荐文章于 2024-05-04 15:30:40 发布
最新推荐文章于 2024-05-04 15:30:40 发布
阅读量1.6k 收藏 6
点赞数 2
文章标签： 队列 分布式 数据库 java kafka
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Adapter_Lee/article/details/111998620
版权

常用的消息中间件

在这里插入图片描述

1.消息队列的介绍

消息队列本质上来说是一个符合先进先出原则的单向队列：一方发送消息并存入消息队列尾部(生产者投递消息)，一方从消息队列的头部取出消息(消费者消费消息)。但对于一个成熟可靠的消息队列来说，所需要解决的主要问题还包括：高效可靠的消息投递、存储；能承受高并发的流量冲击，可通过集群部署来解决单点故障等等。

2.使用消息队列的作用

  • 应用解耦
  • 流量削峰
  • 消息分发

3.RocketMQ介绍

rocketmq是阿里巴巴团队使用Java语言开发的一款分布式消息中间件，是一款低延迟，高可用，拥有海量消息堆积能力和灵活拓展性的消息队列。

3.1RocketMQ组成

rocketmq由四大核心模块组成：producer、consumer、brokerServer、nameServer。其中brokerServer和nameServer是rocketmq的服务端，两者一起独立的对外提供服务；而producer和consumer可看做是rocketmq的客户端，一般依附于业务应用程序。

  1. Producer

    producer负责发送消息。使用producer将消息发送到brokerServer，由brokerServer统一进行消息的分发。

    rocketmq支持多种消息发送方式，如同步消息发送、异步回调消息发送、顺序消息发送以及单向消息发送(异步无回调)。除了单向消息发送，其余的发送方式均需要brokerServer返回发送结果的确认消息。特别的，rocketmq的一大特色是支持发送事务消息(半消息)，能一定程度上解决分布式事务的问题。

  2. Consumer

    consumer 负责消费producer发送的消息。consumer会从brokerServer获取消息，并传递给应用程序。

    **rocketMQ使用的消息原语是At Least Once(至少一次成功消费)，如果一定时间内没有接收到consumer消息确认消费的响应结果，会将同一条消息再次投递给consumer。rocketmq采用ack机制保证消息的消费成功，**所以consumer可能会多次收到同一条消息，需要consumer的业务方做好幂等防护。

    从使用者的角度来看，consumer分为两种方式来获取信息。一种是推模式(push consume)，推模式看起来像是brokerServer将消息推给了consumer；另一种是拉模式(pull consume)，拉模式看起来像是consumer主动的去brokerServer拉取消息(实际上，推模式是基于拉模式实现的)。

  3. BrokerServer

    **brokerServer负责消息的接收，存储和分发，**是rocketmq最核心，最重量级的组成部分。

    为实现高可用和高吞吐，brokerServer通常采用集群部署，共同对外提供服务。

  4. NameServer

    nameServer负责提供路由元数据。例如，brokerServer通常是集群部署的，其拓扑结构会经常的发生变化。如果每次集群中broker机器的上下线都需要通知所有的消费者、生产者，效率太低。

    因此，rocketmq引入了nameServer作为brokerServer路由信息的维护者，broker的每次上下线都和nameServer通信，由nameServer来维护broker的路由信息，而producer和consumer通过访问nameServer获得对应broker的访问地址后，再向对应的broker发起请求。nameServer解除了broker和客户端的耦合依赖关系，大大提高了效率。

    在其它主流消息队列中也存在着类似的维护元信息功能的组件，如zookeeper等。rocketmq的设计者认为zk的功能过于强大，杀鸡焉用牛刀，通过一个精简版的元数据服务nameServer，以减少对外部系统的耦合依赖，得以提供更可靠的服务。

nameServer同样能以集群形式对外提供服务。但和zk集群不同的是，集群内的nameServer服务器并不会互相通信，而是保持相互独立。
在这里插入图片描述

3.2RocketMQ基本概念模型

  1. topic 主题

    topic主题，代表一系列消息的集合，任何消息只能属于一个topic主题，主题是rocketmq进行消息发布订阅的最小单位。业务方可以通过创建并订阅各式各样的主题来满足自身的业务要求。不同主题之间的消息在逻辑上没有关联。

  2. tag 标签

    tag标签，tag从属于topic主题，主要用于对同一主题下的消息进行进一步区分。标签可以简单的认为是二级主题，通过tag标签功能，业务方可以方便的实现对各种二级主题的消费需求。

  3. group 组

    group组，代表着同一类客户端的集合。具体可分为**消费者组（consumer group）和生产者组（producer group）两种。**消费者组和生产者组之间没有任何关联(即使组名一样)。

  4. 消费者组

    消费者组代表着同一类型的消费者集群。同一消费者组内的消费者通常消费同样的消息且消息消费逻辑一致。消费者组的概念使得consumer集群在消费消息时，rocketmq可以通过负载均衡来做到消费消息时的高可用和容错。消费者组的更多作用将会在后面的集群/广播消费模式中继续讲解。

  5. 生产者组

    **生产者组代表着同一类型的生产者集群。**一般来说，消息的生产者在发出了消息得到确认之后便完成了任务，似乎没有必要为此抽象出生产者集群的概念。

    前面说到，rocketmq具有发送事务消息的特性，发送事务消息简单来说就是生产者先发送出一个半消息(预消息)，然后执行本地的事务，在事务完成提交之后再跟着发送一个事务确认消息。半消息和普通消息的最大区别在于，半消息在投递给broker之后，broker不会马上让消费者进行消费，而是等待。只有当接收到生产者后续对应的的事务确认消息后，预消息和确认消息合二为一，才将对应的事务消息交给消费者去消费；而如果最终没有接收到事务确认消息，则会将消息直接删除不投递给消费者，以达到类似事务回滚的效果。事务消息对消费者来说是透明无感知的。

    可如果生产者在发送了预消息之后挂了怎么办？为解决这个问题，broker会在一定时间没有收到确认消息后，定时的回查生产者当前事务消息的状态，回查的范围是整个生产者组中的某一个在线节点。这种情况下，生产者和消费者一样，也构成了一个集群监听来自broker的回查。这样，即使发送消息的生产者发生了故障，在一定条件下整个生产者集群的事务消息发送功能依然可以正常运转。

    通过生产者组的概念，rocketmq实现了事务消息投递的高可用。

  6. message 消息

    message消息是rocketmq中传递消息的主体，消息具有全局唯一的messageID属性，用户可以根据messageID查询进行消息的精确查询。

    消息的内容可以是不超过rocketmq限制的、二进制的任意数据，rocketmq不会对消息承载的数据内容做任何干预。

  7. 集群(Clustering)

    对于任意一条被订阅的消息，同一消费者组下的节点只有一个节点对其进行消费；一个消费者组中的全部节点分摊所有消息。

  8. 广播(Broadcasting)消费

    对于任意一条被订阅的消息，同一消费者组下的所有节点都会对其进行消费；一个消费者组中的全部节点都能接收到全量的消息。

  9. 混合模式消费

    实质上是前两者的综合。同一应用集群构成一个消费者组，不同应用集群之间构成多个不同的消费者组，但却可以订阅同一个topic/tag下的消息。

对于任意一条被订阅的消息，同一消费者组之间只会有一个节点对其进行消费，不同消费者组都会进行全量消息的消费。

4.Consumer消费模式

4.1广播模式

通过consumer.setMessageModel(MessageModel.BROADCASTING)设置

当使用广播消费模式时，MQ 会将每条消息推送给集群内所有订阅该topic和tag的客户端，保证消息至少被每台机器消费一次（若有多个集群都关注这个topic和tag，则每个集群的每个机器都消费一次）。
消息发送失败不会重投
消费进度由consumer维护，broker并不关心一条消息有没有消费成功

4.2集群模式

通过consumer.setMessageModel(MessageModel.CLUSTERING)设置

该模式下，一条消息只要被关注该topic和tag的集群只消费一次就行（如果有多个集群(每个集群（group）里有多台机器)都关注了这个topic和tag，则每个集群都挑随机一个机器消费一次）。
消息失败会重投，但不保证重投到同一机器上
消费进度由broker维护

5.DefaultMQPushConsumer和DefaultMQPullConsumer

DefaultMQPushConsumer大部分控制直接由系统完成，大部分场景使用这种Consumer就行（其实上push的底层也是使用pull方式）
DefaultMQPullConsumer大部分功能由程序员自行配置

6.顺序消息解决方案

Producer指定一个queue，consumer用一个线程去消费

7.事务消息

Producer执行业务逻辑发送半消息给broker，此时broker并不会给consumer消费，只有当broker收到了commit/rollback才会继续，如果收到了commit，则broker认为整个事务是没问题的，执行成功的。那么会下发消息给Consumer端消费，如果收到了rollback，则broker认为本地事务执行失败了，broker将会删除Half Message，不下发给Consumer，如果没收到，broker会定时回查本地事务的执行结果

8.保证消息不丢失

同步发送+自动重试机制+多个Master节点

9.Broker存储

MQ持久化消息分为两种：同步刷盘和异步刷盘。默认情况是异步刷盘，Broker收到消息后会先存到cache里然后立马通知Producer说消息我收到且存储成功了，你可以继续你的业务逻辑了，然后Broker起个线程异步的去持久化到磁盘中，但是Broker还没持久化到磁盘就宕机的话，消息就丢失了。同步刷盘的话是收到消息存到cache后并不会通知Producer说消息已经ok了，而是会等到持久化到磁盘中后才会通知Producer说消息完事了。这也保障了消息不会丢失，但是性能不如异步高。看业务场景取舍

10.默认

消息消费失败自动重试。如果消费消息失败了，没有进行ack确认，则会自动重试，重试策略和次数（默认15次）

如果发送失败的话他会自动重试，默认同步发送的次数是3次，也就是失败后会自动重试2次。

11.发消息的时候选择queue的算法有哪些？

答：分为两种，一种是直接发消息，不能选择queue，这种的queue选择算法如下：

  • 在不开启容错的情况下，轮询队列进行发送，如果失败了，重试的时候过滤失败的Broker
  • 如果开启了容错策略，会通过RocketMQ的预测机制来预测一个Broker是否可用
  • 如果上次失败的Broker可用那么还是会选择该Broker的队列
  • 如果上述情况失败，则随机选择一个进行发送
  • 在发送消息的时候会记录一下调用的时间与是否报错，根据该时间去预测broker的可用时间

另外一种是发消息的时候可以选择算法甚至还可以实现接口自定义算法：

  • SelectMessageQueueByRandom：随机
  • SelectMessageQueueByHash：hash
  • SelectMessageQueueByMachineRoom
  • 实现接口自定义

12.为什么同一个消费组设置不同tag会出现奇怪现象

问题：两个一样的Consumer Group的Consumer订阅同一个Topic，但是是不同的tag，Consumer1订阅Topic的tag1，Consumer2订阅Topic的tag2，然后分别启动。这时候往Topic的tag1里发送10条数据，Topic的tag2里发送10条。目测应该是Consumer1和Consumer2分别收到对应的10条消息。结果却是只有Consumer2收到了消息，而且只收到了4-6条消息，不固定。

答：

  • Consumer端发心跳给Broker，Broker收到后存到consumerTable里（就是个Map），key是GroupName，value是ConsumerGroupInfo。
  • ConsumerGroupInfo里面是包含topic等信息的，但是问题就出在上一步骤，key是groupName，你同GroupName的话Broker心跳最后收到的Consumer会覆盖前者的。相当于如下代码：
map.put(groupName, ConsumerGroupInfo);

这样同key，肯定产生了覆盖。所以Consumer1不会收到任何消息，但是Consumer2为什么只收到了一半（不固定）消息呢？

那是因为：你是集群模式消费，它会负载均衡分配到各个节点去消费，所以一半消息（不固定个数）跑到了Consumer1上，结果Consumer1订阅的是tag1，所以不会任何输出。

如果换成BROADCASTING，那绝逼后者会收到全部消息，而不是一半，因为广播是广播全部Consumer。

13.RocketMQ的Consumer是如何做的负载均衡？比如：5个Consumer进程同时消费一个Topic，这个Topic只有4个queue会出现啥情况？反之Consumer数量小于queue的数据是啥情况？

  • queue个数大于Consumer个数，且queue个数能整除Consumer个数的话， 那么Consumer会平均分配queue。（比如上面表格的Consumer有2个 可以整除部分）
  • queue个数大于Consumer个数，且queue个数不能整除Consumer个数的话， 那么会有一个Consumer多消费1个queue，其余Consumer平均分配。（比如上面表格的Consumer有3个 不可整除部分）
  • queue个数小于Consumer个数，那么会有Consumer闲置，就是浪费掉了，其余Consumer平均分配到queue上。（比如上面表格的Consumer有5个 无法都分配部分）

面试题

1、说说你们公司线上生产环境用的是什么消息中间件?

RocketMQ

2、多个mq如何选型？

MQ描述
RabbitMQerlang开发，对消息堆积的支持并不好，当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降。每秒钟可以处理几万到十几万条消息。
RocketMQjava开发，面向互联网集群化功能丰富，对在线业务的响应时延做了很多的优化，大多数情况下可以做到毫秒级的响应，每秒钟大概能处理几十万条消息。
KafkaScala开发，面向日志功能丰富，性能最高。当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。
ActiveMQjava开发，简单，稳定，性能不如前面三个。小型系统用也ok，但是不推荐。推荐用互联网主流的。

3、为什么要使用MQ？

因为项目比较大，做了分布式系统，所有远程服务调用请求都是同步执行经常出问题，所以引入了mq

作用描述
解耦系统耦合度降低，没有强依赖关系
异步不需要同步执行的远程调用可以有效提高响应时间
削峰请求达到峰值后，后端service还可以保持固定消费速率消费，不会被压垮

4、RocketMQ由哪些角色组成，每个角色作用和特点是什么？

角色作用
Nameserver无状态，动态列表；这也是和zookeeper的重要区别之一。zookeeper是有状态的。
Producer消息生产者，负责发消息到Broker。
Broker就是MQ本身，负责收发消息、持久化消息等。
Consumer消息消费者，负责从Broker上拉取消息进行消费，消费完进行ack。

5、RocketMQ中的Topic和JMS的queue有什么区别？

queue就是来源于数据结构的FIFO队列。而Topic是个抽象的概念，每个Topic底层对应N个queue，而数据也真实存在queue上的。

6、RocketMQ Broker中的消息被消费后会立即删除吗？
不会，每条消息都会持久化到CommitLog中，每个Consumer连接到Broker后会维持消费进度信息，当有消息消费后只是当前Consumer的消费进度（CommitLog的offset）更新了。

追问：那么消息会堆积吗？什么时候清理过期消息？

4.6版本默认48小时后会删除不再使用的CommitLog文件

  • 检查这个文件最后访问时间
  • 判断是否大于过期时间
  • 指定时间删除，默认凌晨4点

7、RocketMQ消费模式有几种？

消费模型由Consumer决定，消费维度为Topic。

  • 集群消费

1.一条消息只会被同Group中的一个Consumer消费

2.多个Group同时消费一个Topic时，每个Group都会有一个Consumer消费到数据

  • 广播消费

消息将对一 个Consumer Group 下的各个 Consumer 实例都消费一遍。即即使这些 Consumer 属于同一个Consumer Group ，消息也会被 Consumer Group 中的每个 Consumer 都消费一次。

8、消费消息是push还是pull？

RocketMQ没有真正意义的push，都是pull，虽然有push类，但实际底层实现采用的是长轮询机制，即拉取方式

broker端属性 longPollingEnable 标记是否开启长轮询。默认开启

源码如下：

// {@link org.apache.rocketmq.client.impl.consumer.DefaultMQPushConsumerImpl#pullMessage()}
// 看到没，这是一只披着羊皮的狼，名字叫PushConsumerImpl，实际干的确是pull的活。

// 拉取消息，结果放到pullCallback里
this.pullAPIWrapper.pullKernelImpl(pullCallback);

追问：为什么要主动拉取消息而不使用事件监听方式？

事件驱动方式是建立好长连接，由事件（发送数据）的方式来实时推送。

如果broker主动推送消息的话有可能push速度快，消费速度慢的情况，那么就会造成消息在consumer端堆积过多，同时又不能被其他consumer消费的情况。而pull的方式可以根据当前自身情况来pull，不会造成过多的压力而造成瓶颈。所以采取了pull的方式。

9、broker如何处理拉取请求的？

Consumer首次请求Broker

  • Broker中是否有符合条件的消息

  • 有 ->

    • 响应Consumer
    • 等待下次Consumer的请求

  • 没有

    • DefaultMessageStore#ReputMessageService#run方法
    • PullRequestHoldService 来Hold连接，每个5s执行一次检查pullRequestTable有没有消息，有的话立即推送
    • 每隔1ms检查commitLog中是否有新消息，有的话写入到pullRequestTable
    • 当有新消息的时候返回请求
    • 挂起consumer的请求，即不断开连接，也不返回数据
    • 使用consumer的offset，

10、RocketMQ如何做负载均衡？

通过Topic在多Broker中分布式存储实现。

producer端

发送端指定message queue发送消息到相应的broker，来达到写入时的负载均衡

  • 提升写入吞吐量，当多个producer同时向一个broker写入数据的时候，性能会下降
  • 消息分布在多broker中，为负载消费做准备

默认策略是随机选择：

  • producer维护一个index
  • 每次取节点会自增
  • index向所有broker个数取余
  • 自带容错策略

其他实现：

  • SelectMessageQueueByHash

    • hash的是传入的args

  • SelectMessageQueueByRandom

  • SelectMessageQueueByMachineRoom 没有实现

也可以自定义实现MessageQueueSelector接口中的select方法

MessageQueue select(final List<MessageQueue> mqs, final Message msg, final Object arg);

consumer端

采用的是平均分配算法来进行负载均衡。

其他负载均衡算法:

平均分配策略(默认)(AllocateMessageQueueAveragely)

环形分配策略(AllocateMessageQueueAveragelyByCircle)

手动配置分配策略(AllocateMessageQueueByConfig)

机房分配策略(AllocateMessageQueueByMachineRoom)

一致性哈希分配策略(AllocateMessageQueueConsistentHash)

靠近机房策略(AllocateMachineRoomNearby)

追问：当消费负载均衡consumer和queue不对等的时候会发生什么？

Consumer和queue会优先平均分配，如果Consumer少于queue的个数，则会存在部分Consumer消费多个queue的情况，如果Consumer等于queue的个数，那就是一个Consumer消费一个queue，如果Consumer个数大于queue的个数，那么会有部分Consumer空余出来，白白的浪费了。

11、消息重复消费

影响消息正常发送和消费的重要原因是网络的不确定性。

引起重复消费的原因

  • ACK

正常情况下在consumer真正消费完消息后应该发送ack，通知broker该消息已正常消费，从queue中剔除

当ack因为网络原因无法发送到broker，broker会认为词条消息没有被消费，此后会开启消息重投机制把消息再次投递到consumer

  • 消费模式

在CLUSTERING模式下，消息在broker中会保证相同group的consumer消费一次，但是针对不同group的consumer会推送多次

解决方案

  • 数据库表

处理消息前，使用消息主键在表中带有约束的字段中insert

  • Map

单机时可以使用map ConcurrentHashMap -> putIfAbsent guava cache

  • Redis

分布式锁搞起来。

12、如何让RocketMQ保证消息的顺序消费

你们线上业务用消息中间件的时候，是否需要保证消息的顺序性?

如果不需要保证消息顺序，为什么不需要?假如我有一个场景要保证消息的顺序，你们应该如何保证?

首先多个queue只能保证单个queue里的顺序，queue是典型的FIFO，天然顺序。多个queue同时消费是无法绝对保证消息的有序性的。所以总结如下：

同一topic，同一个QUEUE，发消息的时候一个线程去发送消息，消费的时候 一个线程去消费一个queue里的消息。

追问：怎么保证消息发到同一个queue？

Rocket MQ给我们提供了MessageQueueSelector接口，可以自己重写里面的接口，实现自己的算法，举个最简单的例子：判断i % 2 == 0，那就都放到queue1里，否则放到queue2里。

13、RocketMQ如何保证消息不丢失

首先在如下三个部分都可能会出现丢失消息的情况：

  • Producer端
  • Broker端
  • Consumer端

Producer端如何保证消息不丢失

  • 采取send()同步发消息，发送结果是同步感知的。
  • 发送失败后可以重试，设置重试次数。默认3次。

producer.setRetryTimesWhenSendFailed(10);

  • 集群部署，比如发送失败了的原因可能是当前Broker宕机了，重试的时候会发送到其他Broker上。

Broker端如何保证消息不丢失

  • 修改刷盘策略为同步刷盘。默认情况下是异步刷盘的。

flushDiskType = SYNC_FLUSH

  • 集群部署，主从模式，高可用。

Consumer端如何保证消息不丢失

  • 完全消费正常后在进行手动ack确认。

14、rocketMQ的消息堆积如何处理

下游消费系统如果宕机了，导致几百万条消息在消息中间件里积压，此时怎么处理?

你们线上是否遇到过消息积压的生产故障?如果没遇到过，你考虑一下如何应对?

首先要找到是什么原因导致的消息堆积，是Producer太多了，Consumer太少了导致的还是说其他情况，总之先定位问题。

然后看下消息消费速度是否正常，正常的话，可以通过上线更多consumer临时解决消息堆积问题

追问：如果Consumer和Queue不对等，上线了多台也在短时间内无法消费完堆积的消息怎么办？

  • 准备一个临时的topic
  • queue的数量是堆积的几倍
  • queue分布到多Broker中
  • 上线一台Consumer做消息的搬运工，把原来Topic中的消息挪到新的Topic里，不做业务逻辑处理，只是挪过去
  • 上线N台Consumer同时消费临时Topic中的数据
  • 改bug
  • 恢复原来的Consumer，继续消费之前的Topic

追问：堆积时间过长消息超时了？

RocketMQ中的消息只会在commitLog被删除的时候才会消失，不会超时。也就是说未被消费的消息不会存在超时删除这情况。

追问：堆积的消息会不会进死信队列？

不会，消息在消费失败后会进入重试队列（%RETRY%+ConsumerGroup），18次（默认18次，网上所有文章都说是16次，无一例外。但是我没搞懂为啥是16次，这不是18个时间吗 ？）才会进入死信队列（%DLQ%+ConsumerGroup）。

源码如下：

public class MessageStoreConfig {
    // 每隔如下时间会进行重试，到最后一次时间重试失败的话就进入死信队列了。
 private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";
}

15、RocketMQ在分布式事务支持这块机制的底层原理?

你们用的是RocketMQ?RocketMQ很大的一个特点是对分布式事务的支持，你说说他在分布式事务支持这块机制的底层原理?

分布式系统中的事务可以使用TCC（Try、Confirm、Cancel）、2pc来解决分布式系统中的消息原子性

RocketMQ 4.3+提供分布事务功能，通过 RocketMQ 事务消息能达到分布式事务的最终一致

RocketMQ实现方式：

**Half Message：**预处理消息，当broker收到此类消息后，会存储到RMQ_SYS_TRANS_HALF_TOPIC的消息消费队列中

**检查事务状态：**Broker会开启一个定时任务，消费RMQ_SYS_TRANS_HALF_TOPIC队列中的消息，每次执行任务会向消息发送者确认事务执行状态（提交、回滚、未知），如果是未知，Broker会定时去回调在重新检查。

**超时：**如果超过回查次数，默认回滚消息。

也就是他并未真正进入Topic的queue，而是用了临时queue来放所谓的half message，等提交事务后才会真正的将half message转移到topic下的queue。

16、看过RocketMQ 的源码没有。如果看过，说说你对RocketMQ 源码的理解?

要真让我说，我会吐槽蛮烂的，首先没任何注释，可能是之前阿里巴巴写了中文注释，捐赠给apache后，apache觉得中文注释不能留，自己又懒得写英文注释，就都给删了。里面比较典型的设计模式有单例、工厂、策略、门面模式。单例工厂无处不在，策略印象深刻比如发消息和消费消息的时候queue的负载均衡就是N个策略算法类，有随机、hash等，这也是能够快速扩容天然支持集群的必要原因之一。持久化做的也比较完善，采取的CommitLog来落盘，同步异步两种方式。

17、高吞吐量下如何优化生产者和消费者的性能?

开发

  • 同一group下，多机部署，并行消费

  • 单个Consumer提高消费线程个数

  • 批量消费

    • 消息批量拉取
    • 业务逻辑批量处理

运维

  • 网卡调优
  • jvm调优
  • 多线程与cpu调优
  • Page Cache

18.再说说RocketMQ 是如何保证数据的高容错性的?

  • 在不开启容错的情况下，轮询队列进行发送，如果失败了，重试的时候过滤失败的Broker
  • 如果开启了容错策略，会通过RocketMQ的预测机制来预测一个Broker是否可用
  • 如果上次失败的Broker可用那么还是会选择该Broker的队列
  • 如果上述情况失败，则随机选择一个进行发送
  • 在发送消息的时候会记录一下调用的时间与是否报错，根据该时间去预测broker的可用时间

以上面试题节选自大佬博客：https://www.cnblogs.com/javazhiyin/p/13327925.html

AdapterLee
关注
  • 2
    点赞
  • 踩
  • 6
    收藏
    觉得还不错? 一键收藏
  • 4
    评论
大写的服，看完这篇你还不懂RocketMQ算我输
u010889990的专栏
09-15 1400
目录 RocketMQ介绍 RocketMQ概念 为什么要用RocketMQ？ 异步解耦 削峰填谷 分布式事务最终一致性 数据分发 RocketMQ架构 RocketMQ消息类型 普通消息 顺序消息 定时消息 事务消息 最佳实践 消息重试 消息过滤 消费模式 消费幂等 本地事务消息封装 参考代码 RocketMQ 介绍 Apache RocketMQ 是一款 低延迟、高并发、高可用、高可靠的分布式消息中间件。消息队列 RocketMQ 可为分布式应用系统提供异步解耦和削峰填谷的能力，同
RocketMQ系列1——基础角色介绍
xiaodigua1024的博客
03-27 766
RocketMQ是一个消息中间件，具有高性能、高可靠、高实时、分布式的特点。RocketMQ 技术架构中有四大角色 NameServer 、 Broker 、 Producer 、 Consumer。其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息，NameServer作为注册中心。
RocketMq生产者组和消费者组
热门推荐
qq_36559868的博客
05-24 2万+
ProducerGroup（生产者组）： 一个生产者组，代表着一群topic相同的Producer。即一个生产者组是同一类Producer的组合。 如图，Producer_1、Producer_2、Producer_3 为一个ProducerGroup，因为他们都订阅了topicA。同理Producer_4、Producer_5、Producer_6为另一个ProducerGroup，他们订阅了topicB。 如果Producer是TransactionMQProducer，则发送的是事务消息。如果节点1
一、RocketMQ基本概述与部署
最新发布
青啊青斯博客
05-04 1343
MQ（Message Queue）是一种提供消息队列服务的中间件，也称为消息中间件，是一套提供了消费、存储、消费全过程API的软件系统，消息即数据，一般消息的体量不会很大。RocketMQ是一个统一消息引擎、轻量级数据处理平台。RocketMO是一款阿里巴巴开源的消息中间件。2016年11月28日，阿里巴巴向Apache 软件基金会捐赠RocketMQ,成为Apache 孵化项目。
RokectMQ 2万字 详解 认真看完必有收获
Richrichrichrich的博客
10-19 841
2万字RocketMQ详解，认真看完一定会有收获。
RocketMQ的主要组件及其功能
ch98000的博客
08-26 1227
关于RocketMQ的组件就介绍到这里了，后续会不断展开关于RocketMQ的原理和实战用法。
RocketMq事务消息（分布式事务解决方案）
疯狂的蜗牛
09-07 8680
从问题出发 阅读本文后，我们将了解以上两个问题的答案。 1、RocketMq生产者组（producer group）的设定有什么用？ 2、一个订单处理的场景，消费者订阅了订单topic，但总担心丢消息。于是为了防止丢消息，每天都会通过定时任务做一致性校验，这是最佳方案吗？ 这还得从基于消息队列实现实现分布式事务的解决方案说起。 常见的分布式事务包括 2PC、3PC、TCC、本地消息表、消息事务、最大努力通知。 今天我们主要讲讲本地消息表、消息事务两种方案。 本地消息表 本地消息表的大致流程是这样的。 pub
Spark初探
02-26
Spark基于内存计算，提高了在大数据环境下数据处理的实时性，同时保证了高容错性和高可伸缩性，允许用户将Spark部署在大量廉价硬件之上，形成集群。...Spark是基于内存计算的大数据并行计算框架。Spark基于内存计算，...
nginx平台初探
03-01
众所周知，nginx性能高，而nginx的高性能与其架构是分不开的。那么nginx究竟是怎么样的呢？这一节我们先来初识一下nginx框架吧。nginx在启动后，在unix系统中会以daemon的方式在后台运行，后台进程包含一个master...
RocketMQ生产者和消费者的负载均衡分配策略
张俊杰 的博客
10-30 3257
负载均衡分两块儿,一个是producer的负载均衡,一个是Comsumer的负载均衡 Producer负载均衡 Producer发送消息时，默认会轮询目标Topic下的所有MessageQueue，并采用递增取模的方式往不同的MessageQueue上发送消息，以达到让消息平均落在不同的queue上的目的。而由于MessageQueue是分布在不同的Broker上的，所以消息也会发送到不同的broker上。 同时生产者在发送消息时，可以指定一个MessageQueueSelector。通过这个对象来
RocketMQ生产者组topic和消费组的关系
love4amanda的博客
02-03 1万+
各个之间的关系其实很松散,并不是说不能操作 最佳实践 订阅关系一致 多个 Group ID 订阅了多个 Topic，并且每个 Group ID 里的多个消费者实例的订阅关系保持了一致。 消费幂等 最终一致性保证数据一致性,如果不幂等,将导致数据错乱 topic和tag的关系 topic可以是一级过滤关系 tag是二级过滤关系 使用: 业务消息往往推荐做topic 的 一级区分 tag往往用于过滤...
RocketMQ中的生产者组只能有一个在用的生产者：
KuaiLeShiFu的博客
12-15 9122
RocketMQ中的生产者组只能有一个在用的生产者： Warning: Considering the provided producer is sufficiently powerful at sending messages, only one instance is allowed per producer group and process to avoid unnecessarily i
RocketMq01_概述及背景、主题、标签、队列、生产者、消费者、注册中心、工作流程
所得皆惊喜
12-09 1291
RocketMq01_概述及背景、主题、标签、队列、生产者、消费者、注册中心、工作流程
Spring Boot实战解决高并发数据入库: Redis 缓存+MySQL 批量入库
通往精英的成长之路
08-08 1万+
前言 最近在做阅读类的业务，需要记录用户的PV，UV； 项目状况：前期尝试业务阶段； 特点： 快速实现（不需要做太重，满足初期推广运营即可） 快速投入市场去运营 收集用户的原始数据，三要素： 谁 在什么时间 阅读哪篇文章 提到PV，UV脑海中首先浮现特点： 需要考虑性能（每个客户每打开一篇文章进行记录） 允许数据有较小误差（少部分数据丢失） 架构设计 架构图： 时序图 记录基础数据MySQL表结构 CREATE TABLE `zh_article_count` ( `id`
547、RocketMQ详细入门教程系列 -【消息队列之 RocketMQ（一）】 2023.01.30
youyouwuxin1234的博客
01-30 521
消费消息时通过 Consumer Group 实现了将消息分发到多个消费者服务器实例，比如某个 Topic 有9条消息，其中一个 Consumer Group 有3个实例（3个进程或3台机器），那么每个实例将均摊3条消息，这也意味着我们可以很方便的通过加机器来实现水平扩展。这种方式优点是消息丢失的非常少，且消息实时性不会受影响，Master 宕机后消费者可以继续从 Slave 消费，中间的过程对用户应用程序透明，不需要人工干预，性能同多 Master 方式几乎一样。消息（Message）就是要传输的信息。
RocketMQ笔记-Producer(生产者发送的三种方式)
极客on之路
12-11 458
https://www.jianshu.com/p/42330afbe53a
Apache RocketMQ 源码解析1
08-03
2.1 RocketMQ DLedger 多副本即主从切换专栏回顾(源码阅读技巧篇) 2.3 源码分析 RocketMQ 消息轨迹 2.8 基于 raft 协议

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值