![](https://img-blog.csdnimg.cn/20201015090358923.png?x-oss-process=image/resize,m_fixed,h_224,w_224)
RocketMQ
文章平均质量分 53
RocketMQ
知知之之
这个作者很懒,什么都没留下…
展开
-
RocketMQ底层原理之存储设计
RocketMQ消息的存储是由ConsumeQueue和CommitLog配合完成 的,消息真正的物理存储文件是CommitLog,ConsumeQueue是消息的逻辑队列,类似数据库的索引文件,存储的是指向物理存储的地址。每个Topic下的每个Message Queue都有一个对应的ConsumeQueue文件。comsumequeue:存储消息在commit log的索引。commit log:存储消息的元数据。...原创 2022-08-09 14:41:49 · 278 阅读 · 0 评论 -
Kafka与RocketMQ对比
模型对比KafkaRocketMQ数据可靠性RocketMQ支持异步实时刷盘,同步刷盘,同步Replication,异步Replication Kafka使用异步刷盘方式,异步ReplicationRocketMQ的同步刷盘在单机可靠性上比Kafka更高,不会因为操作系统Crash,导致数据丢失。 同时同步Replication也比Kafka异步Replication更可靠,数据完全无单点。另外Kafka的Replication以topic为单位,支持主机宕机,备机自动切换,但是原创 2021-07-20 14:51:18 · 1147 阅读 · 0 评论 -
RocketMQ消息可靠性
同步刷盘、异步刷盘RocketMQ消息是存储在磁盘上,这样既能保证断电后恢复,又可以让存储的消息量超出内存的限制,RocketMQ为了提高性能,会尽可能的保证磁盘的顺序写。消息在通过Producer写入RocketMQ的时候有两种写磁盘方式,同步刷盘还是异步刷盘,是通过Broker配置文件里的flushDiskType参数设置的,这个参数被设置成SYNC_FLUSH、ASYNC_FLUSH。同步刷盘:在返回写成功状态时,消息已经被写入磁盘。具体流程是,消息写入内存的PAGECACHE后,立刻通知刷盘原创 2021-07-20 14:30:47 · 125 阅读 · 0 评论 -
RocketMQ读写队列
读写队列作用RocketMQ创建Topic时,可以配置writeQueueNums和readQueueNums,读写队列,是在做路由信息时使用。在消息发送时,使用写队列个数返回路由信息,而消息消费时按照读队列个数返回路由信息。在物理文件层面,只有写队列才会创建文件。写队列个数是8,设置的读队列个数是4,这个时候,会创建8个文件夹,代表0 1 2 3 4 5 6 7,但在消息消费时,路由信息只返回4,在具体拉取消息时,就只会消费0 1 2 3这4个队列中的消息,4 5 6 7中的信息压根就不会被消费原创 2022-03-16 14:34:46 · 4729 阅读 · 0 评论 -
RocketMQ事务消息设计
一阶段的消息如何对用户不可见事务消息相对普通消息最大的特点就是一阶段发送的消息对消费者是不可见的,写入消息数据,但是不创建对应的消息的索引信息。每条消息都会有对应的索引信息,Consumer通过索引读取消息。那么实现一阶段写入的消息不被用户消费(需要在Commit后才能消费),只需要写入Storage Queue,但是不构建Index Queue即可。public PutMessageResult putHalfMessage(MessageExtBrokerInner messageInne原创 2022-04-19 10:45:17 · 320 阅读 · 0 评论 -
RocketMQ根据Tag消息过滤
RocketMQ支持消息tag,消费者可以同时订阅某个topic的多个tag;RocketMQ的队列存储结构是由偏移量,消息大小,消息tag组成支持如下2种的过滤方式(1) Tag过滤方式:Consumer端在订阅消息时除了指定Topic还可以指定TAG,如果一个消息有多个TAG,可以用||分隔。其中,Consumer端会将这个订阅请求构建成一个 SubscriptionData,发送一个Pull消息的请求给Broker端。Broker端从RocketMQ的文件存储层—Store读取数据之前,会原创 2021-08-27 10:10:28 · 1715 阅读 · 0 评论 -
MQTT与RocketMQ对比
MQTTMQTT(Message Queuing Telemetry Transport,消息队列遥测传输协议),是一种基于发布/订阅(publish/subscribe)模式的"轻量级"通讯协议,该协议构建于TCP/IP协议上,MQTT最大优点在于,可以以极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务。作为一种低开销、低带宽占用的即时通讯协议,使其在物联网、小型设备、移动应用等方面有较广泛的应用。对比 MQTT RocketMQ 使用背景 面向移动端场景,移原创 2021-08-24 15:34:57 · 5115 阅读 · 0 评论 -
RocketMQ同一个消费者内消费者订阅不同Topic问题分析
背景在一个服务里起了两个消费者,并且这两个消费者属于同一个组,但是这两个消费者所订阅的Topic是不相同的,出现了只有一个消费者在消费消息,另外一个不消费消息分析经过走查broker端代码发现如下代码:重点在步骤4和5.1和5.2,现在只针对一个broker做一下分析:假设consumer1先启动,对于broker_a一开始关系是group1->topic1当consumer2启动并rebalance完成后,consumer2发送group1->topic2,在步原创 2021-06-28 11:45:09 · 14223 阅读 · 5 评论 -
别再问我MQ消息怎么保证顺序消费
面试中肯定会被问到MQ方面的问题,那么面试官一定会问你如何保证消息的顺序性,Q:看你有用到Kafka消息中间件,请问怎么保证消息顺序消费?A:在发送消息的时候指定同一个原创 2021-05-27 23:45:22 · 1194 阅读 · 3 评论 -
解决MQ消息积压
场景很多系统会用到MQ做消息缓存,但是随之而来会带来一些问题,比如系统由于故障消费组的消费能力突然大幅度降低,导致几千万条的数据积压在MQ里几个小时,假设故障之前的消费者已经允许是消费组最大的数量了,即使消费者数量已经全部恢复,消费能力恢复到故障之前的状态,也需要经过一段时间才能消费完积压的消息,如果是在生产环境,这有可能就会带来灾难,那么我们如何解决这个问题呢?问题分析导致MQ消息积压的根本原因就是因为消费者的消费速度不够,如果我们能提高消费者的消费能力,问题就能够解决,那么问题就来了,我们的原创 2021-04-30 00:00:00 · 1813 阅读 · 0 评论 -
RocketMQ创建多个消费者问题分析
问题描述:在一个进程中同一个消费组创建多个消费者会出现The consumer group [groupName] has been created before, specify another name please. DefaultMQPushConsumer consumer1 = new DefaultMQPushConsumer(); consumer1.setConsumerGroup(groupName); consumer1.setN原创 2020-10-15 20:17:55 · 6125 阅读 · 3 评论 -
应用连接两个RocketMQ集群,只连接其中一个集群问题分析
项目场景:应用中需要连接两个RocketMQ集群,即就是两个不同的NameServer,消费两个集群里的消息。(RocketMQ Client 版本4.4.0)问题描述:应用启动后在RocketMQ控制台发现,两个消费都注册到同一个集群(期望是根据配置分别注册到不同的NameServer) DefaultMQPushConsumer consumer1 = new DefaultMQPushConsumer(); consumer1.setConsumerGr原创 2020-10-15 10:35:10 · 3459 阅读 · 0 评论