前言 hello,小伙伴们,王子又来和大家研究RocketMQ的原理了,之前的文章RocketMQ生产部署架构如何设计中,我们已经简单的聊过了生产者是如何发送消息给Broker的. 我们简单回顾一下这个过程. 生产者首先声明一个Topic,然后为了把消息存到对应的Topic中,先从NameServer拉取注册信息获取到Topic存放在哪个Broker中,然后就可以访问对应的Broker发送消息了. 大体流程就是这样,那么这个过程中具体都发生了什么呢,王子今天就和大家深入的探讨一下这其中的奥秘.

Kafka是一种分布式的基于发布/订阅的消息系统,它的高吞吐量.灵活的offset是其它消息系统所没有的. Kafka发送消息主要有三种方式: 1.发送并忘记 2.同步发送 3.异步发送+回调函数 下面以单节点的方式分别用三种方法发送1w条消息测试: 方式一:发送并忘记(不关心消息是否正常到达,对返回结果不做任何判断处理) 发送并忘记的方式本质上也是一种异步的方式,只是它不会获取消息发送的返回结果,这种方式的吞吐量是最高的,但是无法保证消息的可靠性: import pickle import t

package com.bfxy.rocketmq.quickstart; import java.util.List; import org.apache.rocketmq.client.exception.MQBrokerException;import org.apache.rocketmq.client.exception.MQClientException;import org.apache.rocketmq.client.producer.DefaultMQProducer;impo

KafkaProducer 创建一个 KafkaThread 来运行 Sender.run 方法. 1. 发送消息的入口在 KafkaProducer#doSend 中,但其实是把消息加入到 batches 中: kafka 生产者是按 batch 发送消息,RecordAccumulator 类有个变量 ConcurrentMap<TopicPartition, Deque<ProducerBatch>> batches,KafkaProducer#doSend 方法会把当前的这

问题现象 RocketMQ3.2.2版本,测试时尝试发送消息时自动创建Topic,设置了队列数量为8: producer.setDefaultTopicQueueNums(8); 同时设置broker服务器的配置文件broker.properties: defaultTopicQueueNums=16 但实际创建后从控制台及后台打印代码观察到该Topic只创建了4个队列,反复重试确认发送消息时自动创建Topic,最大创建4个队列. 查找原因 服务端与客户端配置对比 阅读源码,在TopicConf

package com.bfxy.rocketmq.quickstart; import org.apache.rocketmq.client.exception.MQBrokerException;import org.apache.rocketmq.client.exception.MQClientException;import org.apache.rocketmq.client.producer.DefaultMQProducer;import org.apache.rocketmq.

系列文章 RocketMQ入门篇 RocketMQ生产者流程篇 RocketMQ生产者消息篇 前言 上文RocketMQ生产者流程篇中详细介绍了生产者发送消息的流程,本文将重点介绍发送消息的通信模式以及各种不同的消息类型. 通信模式 RocketMQ提供了三种通讯模式,分别是:同步,异步和单向:可以查看内部类CommunicationMode: public enum CommunicationMode { SYNC, ASYNC, ONEWAY, } 下面分别看一下三种通讯模式如何使用 1.同

前言 小伙伴们大家好啊,王子又来和大家一起闲谈MQ技术了. 通过之前文章的学习,我们已经对RocketMQ的基本架构有了初步的了解,那今天王子就和大家一起来点实际的,用代码和大家一起看看RocketMQ的几种发送模式和消费模式.好了,让我们开始吧. RocketMQ的环境准备 本次我们的环境搭建是基于docker的,需要小伙伴们准备一台CentOS7的虚拟机(虚拟机的安装这里就不做介绍了). 王子使用的是安装在VMware中的CentOS7虚拟机系统.正式安装环境之前,为了测试方便,我们关闭了c

一.方案背景 RocketMQ(以下简称MQ)作为消息中间件在事务管理,异步解耦,削峰填谷,数据同步等应用场景中有着广泛使用.当业务系统进行灰度发布时,Dubbo与HTTP的调用可以基于业界通用的灰度方式在我们的微服务治理与网关平台来实现,但MQ已有的灰度方案都不能完全解决消息的隔离与切换衔接问题,为此,我们在鲁班MQ平台(包含根因分析.资源管理.订阅关系校验.延时优化等等的扩展)增加了MQ灰度功能的扩展实现. 二.RocketMQ技术特点 为什么MQ的灰度方案迟迟没有实现呢?我们先来回顾一下R

在RocketMQ4.3.0版本后,开放了事务消息这一特性,对于分布式事务而言,最常说的还是二阶段提交协议,那么RocketMQ的事务消息又是怎么一回事呢,这里主要带着以下几个问题来探究一下RocketMQ的事务消息: 事务消息是如何实现的 我们有哪些手段来监控事务消息的状态 事务消息的异常恢复机制 RocketMQ的事务消息是如何实现的 RocketMQ作为一款消息中间件,主要作用就是帮助各个系统进行业务解耦,以及对消息流量有削峰填谷的作用,而对于事务消息,主要是通过消息的异步处理,可以保证本

1. 概念 Producer端重试: 生产者端的消息失败,也就是Producer往MQ上发消息没有发送成功,比如网络抖动导致生产者发送消息到MQ失败. 这种消息失败重试我们可以手动设置发送失败重试的次数. Consumer端重试: Consumer消费消息失败后,要提供一种重试机制,令消息再消费一次,Consumer消费消息失败通常可以认为有以下几种情况 1. 由于消息本身的原因,例如反序列化失败,消息数据本身无法处理(例如话费充值,当前消息的手机被注销,无法充值)等.这种错误通常需要跳过这条消

消息模型 消息队列的演进 消息队列模型 发布订阅模型 RabbitMQ的消息模型 交换器的类型 direct topic fanout headers Kafka的消息模型 RocketMQ的消息模型 参考 消息模型 消息队列的演进 消息队列模型 早起的消息队列是按照"队列"的数据结构来设计的. 生产者(Producer)产生消息,进行入队操作,消费者(Consumer)接收消息,就是出队操作,存在于服务端的消息容器就称为消息队列. 当然消费者也可能不止一个,存在的多个消费者是竞争的关

1. Kafka的Producer 不论将kafka作为什么样的用途,都少不了的向Broker发送数据或接受数据,Producer就是用于向Kafka发送数据.如下: 2. 添加依赖 pom.xml文件如下: <!-- https://mvnrepository.com/artifact/org.apache.kafka/kafka --> <dependency> <groupId>org.apache.kafka</groupId> <artifa

在阅读本文前,若您对RocketMQ技术感兴趣,请加入 RocketMQ技术交流群 根据上文的描述,发送事务消息的入口为: TransactionMQProducer#sendMessageInTransaction: public TransactionSendResult sendMessageInTransaction(final Message msg, final Object arg) throws MQClientException { if (null == this.trans

上节已经梳理了RocketMQ发送事务消息的流程(基于二阶段提交),本节将继续深入学习事务状态消息回查,我们知道,第一次提交到消息服务器时消息的主题被替换为RMQ_SYS_TRANS_HALF_TOPIC,本地事务执行完后如果返回本地事务状态为UN_KNOW时,第二次提交到服务器时将不会做任何操作,也就是说此时消息还存在与RMQ_SYS_TRANS_HALF_TOPIC主题中,并不能被消息消费者消费,那这些消息最终如何被提交或回滚呢? 原来RocketMQ使用TransactionalMessa

发送普通消息(三种方式) RocketMQ 发送普通消息有三种实现方式:可靠同步发送.可靠异步发送.单向(Oneway)发送. 注意 :顺序消息只支持可靠同步发送. GitHub地址: https://github.com/yudiandemingzi/SpringBootBlog 一.概念 1.可靠同步发送 原理:同步发送是指消息发送方发出数据后,会在收到接收方发回响应之后才发下一个数据包的通讯方式. 应用场景:此种方式应用场景非常广泛,例如重要通知邮件.报名短信通知.营销短信系统等. 2.可

RocketMQ最佳实践之Producer 投递状态 发送消息时,将得到包含SendStatus的SendResult.首先,我们假设消息的isWaitStoreMsgOK = true(默认是true).如果不是,我们将总会得到SEND_OK,如果没有抛出异常.下面是关于每个状态的描述列表: FLUSH_DISK_TIMEOUT 如果 Broker 设置MessageStoreConfig的FlushDiskType=SYNC_FLUSH(默认是ASYNC_FLUSH),并且代理没有在Mess

匠心零度 转载请注明原创出处,谢谢! RocketMQ网络部署图 NameServer:在系统中是做命名服务,更新和发现 broker服务. Broker-Master:broker 消息主机服务器. Broker-Slave: broker 消息从机服务器. Producer: 消息生产者. Consumer: 消息消费者. 说明: rocketmq系列都将会以rocketmq-4.1.0-incubating进行介绍. 在阅读源码时做了一定的注释,公众号[匠心零度]回复:rocketmq,可

匠心零度 转载请注明原创出处,谢谢! RocketMQ网络部署图 NameServer:在系统中是做命名服务,更新和发现 broker服务. Broker-Master:broker 消息主机服务器. Broker-Slave: broker 消息从机服务器. Producer: 消息生产者. Consumer: 消息消费者. 说明: rocketmq系列都将会以rocketmq-4.1.0-incubating进行介绍. 在阅读源码时做了一定的注释,公众号[匠心零度]回复:rocketmq,可

痛点背景 业务场景 假设有这么一个需求,用户下单后如果30分钟未支付,则该订单需要被关闭.你会怎么做? 之前方案 最简单的做法,可以服务端启动个定时器,隔个几秒扫描数据库中待支付的订单,如果(当前时间-订单创建时间)>30分钟,则关闭订单. 方案评估 优点:是实现简单,缺点呢? 缺点:定时扫描意味着隔个几秒就得查一次数据库,频率高的情况下,如果数据库中订单总量特别大,这种高频扫描会对数据库带来一定压力,待付款订单特别多时(做个爆品秒杀活动,或者啥促销活动),若一次性查到内存中,容易引起宕机,需要