1.遇到的问题:上测试环境,上次描述的鸟问题又出现了,就是生产者发3条数据,我这边只能收到1条数据. 2.问题解决: (1)去控制台看我的消费者启动情况,貌似没什么问题 , (2)去测试服务器里看日志信息:只有入库的那条是真的接收到了,其余压根就没有接收到,排除入库过程的代码问题.到此,问题只锁定在我的consumer根本没有接收到丢失的那两条消息. (3)仔细思考一下,发现了问题的根源,看图一的控制台信息,可以发现,生产者默认给我分配了四个队列,但是我的消费者只用了两个队列,这就是和那天的问题

Broker和前面分析过的NameServer类似,需要在Pipeline责任链上通过NettyServerHandler来处理消息 [RocketMQ中NameServer的启动源码分析] 实际上就通过前面提到的SendMessageProcessor的processRequest方法处理 [RocketMQ中Broker的启动源码分析(一)] SendMessageProcessor的processRequest方法: public RemotingCommand processReques

前言 小伙伴们,国庆都过的开心吗?国庆后的第一个工作日是不是很多小伙伴还沉浸在假期的心情中,没有工作状态呢? 那王子今天和大家聊一聊RocketMQ的消费者是如何获取消息的,通过学习知识来找回状态吧. 废话不多说,我们开始吧. 消费者组 首先我们了解一个概念,什么是消费者组. 消费者组你就可以把它理解为,给一组消费者起一个名字. 假设我们有一个订单Topic名字是OrderTopic,然后库存系统和积分系统都要消费这个Topic中的数据,我们分别给库存系统和积分系统起一个消费组名字:stock_

转载请注明出处:http://www.cnblogs.com/xiaodf/ 本博客实现了一个简单的RocketMQ消费者的示例,MQ里存储的是经过Avro序列化的消息数据,程序读取数据并反序列化后,将消息从控制台打印出来. 程序通过stdin.xml配置文件获取主要参数值,stdin.xml文件内容如下: <?xml version="1.0" encoding="UTF-8"?> <operator> <parameters>

RocketMQ的broker用如下命令启动: nohup sh bin/mqbroker -n localhost:9876 & 使用jps查看,系统非常卡顿,broker的名字也未显示.使用top命令,发现broker的进程的内存占用率高达93%,难怪linux系统如此卡顿.解决办法:从如下路径进入rocketmq-all-4.3.2/distribution/target/apache-rocketmq/bin,找到箭头指的2个文件. 使用vim xxx.sh命令进行JVM参数配置修改:将

接着上一篇博客  [RocketMQ中Broker的启动源码分析(一)] 在完成准备工作后,调用start方法: public static BrokerController start(BrokerController controller) { try { controller.start(); String tip = "The broker[" + controller.getBrokerConfig().getBrokerName() + ", " + c

上一篇博客的最后简单提了下CommitLog的刷盘  [RocketMQ中Broker的消息存储源码分析] (这篇博客和上一篇有很大的联系) Broker的CommitLog刷盘会启动一个线程,不停地将缓冲区的内容写入磁盘(CommitLog文件)中,主要分为异步刷盘和同步刷盘 异步刷盘又可以分为两种方式:①缓存到mappedByteBuffer -> 写入磁盘(包括同步刷盘)②缓存到writeBuffer -> 缓存到fileChannel -> 写入磁盘 (前面说过的开启内存字节缓冲

Broker的HA策略分为两部分①同步元数据②同步消息数据 同步元数据 在Slave启动时,会启动一个定时任务用来从master同步元数据 if (role == BrokerRole.SLAVE) { if (null != slaveSyncFuture) { slaveSyncFuture.cancel(false); } this.slaveSynchronize.setMasterAddr(null); slaveSyncFuture = this.scheduledExecutorS

  在工作中遇到了一个这个问题,就是我们rocketmq是部署在云主机上的 但是我们的开发同事在自己的电脑连接rocketmq链接不上 报错显示Caused by: org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <10.19.73.64:10911> failed 这里练级的是rocketmq云主机的内网IP,那肯定是链接不上的 这里我们就需要修改RocketMQ的 broker 的地址

在RocketMQ中,使用BrokerStartup作为启动类,相较于NameServer的启动,Broker作为RocketMQ的核心可复杂得多 [RocketMQ中NameServer的启动源码分析] 主函数作为其启动的入口: public static void main(String[] args) { start(createBrokerController(args)); } 首先通过createBrokerController方法生成Broker的控制器BrokerControll

本文分析 DefaultMQPushConsumer,异步发送消息,多线程消费的情形. DefaultMQPushConsumerImpl MQClientInstance 一个客户端进程只有一个 MQClientInstance 实例 MQClientAPIImpl 和 netty 打交道 PullMessageService 拉取消息 RebalanceService 客户端 rebalance ConcurrentMap<String/* group */, MQProducerInner

最近工作中用到了RocketMQ,现记录下,如何正确实现消费~ 消费者需要注意的问题 防止重复消费 如何快速消费 消费失败如何处理 Consumer具体实现 防止重复消费 重复消费会造成数据不一致等问题.所以,消费者要做到消费幂等. 1)每次消费,记录messageId:如果再次消费该message,查询messageId是否已存在,已存在,就跳过消费: 2)使用具体业务状态来防止重复消费,例如如果状态已经被变更,说明已有消息被消费: 如何快速消费 消费过程缓慢,势必会造成消息积压,如何提高消费

本篇博客会从源码层面,验证在RocketMQ基础概念剖析,并分析一下Producer的底层源码中提到的结论,分别是: Broker在启动时,会将自己注册到所有的NameServer上 Broker在启动之后,会每隔30S向NameServer发送心跳 之前的文章中,我们知道了RocketMQ中的一些核心概念,例如Broker.NameServer.Topic和Tag等等.Producer从启动到发送消息的整个过程,从源码级别分析了Producer在发送消息到Broker的时候,是如何拿到Brok

Broker注册 在Broker的启动函数中,添加了定时向NameServer进行注册的任务,在启动后延迟10秒向NameServer进行注册,之后定时发送心跳包,关于发送周期,首先从Broker配置的周期与60000毫秒中选出最小的那个值,然后再与10000毫秒对比,选出最大的那个,所以最长10秒钟执行一次心跳发送: public class BrokerController { public void start() throws Exception { // ... // 定时向NameS

这个load操作发生在启动broker的时候. 所以我们直接进入DefaultMessageStore的load()方法: /** * 加载数据 * * @throws IOException */ public boolean load() { boolean result = true; try { boolean lastExitOK = !this.isTempFileExist(); log.info("last shutdown {}", (lastExitOK ? &qu

解决方法: 修改broker启动脚本runbroker.sh里面的jvm参数 JAVA_OPT="${JAVA_OPT} -server -Xms8g -Xmx8g -Xmn4g" 改为 JAVA_OPT="${JAVA_OPT} -server -Xms128m -Xmx256m -Xmn256m" 然后重新启动broker. 另外,nameserver的启动脚本是runserver.sh,也可修改其中的jvm参数.

概述 在 Broker 的通用请求处理器将一个消息进行分发后,就来到了 Broker 的专门处理消息存储的业务处理器部分.本篇文章,我们将要探讨关于 RocketMQ 高效的原因之一:文件结构的良好设计与对 Page Cache 的极致"压榨". 文件系统的结构设计 在 RocketMQ 的 Broker 中,有一类叫做 CommitLog 的文件,所有在该 Broker 上的 Topic 上的消息都会顺序的写入到这个文件中. 该消息的元信息存储着消息所在的 Topic 与 Queue

在工作中遇到了一个这个问题,就是我们rocketmq是部署在云主机上的 但是我们的开发同事在自己的电脑连接rocketmq链接不上 报错显示Caused by: org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <10.19.73.64:10911> failed 这里练级的是rocketmq云主机的内网IP,那肯定是链接不上的 这里我们就需要修改RocketMQ的 broker 的地址 #进

概述 在上一节 RocketMQ源码详解 | Producer篇 · 其二:消息组成.发送链路 中,我们终于将消息发送出了 Producer,在短暂的 tcp 握手后,很快它就会进入目的 Broker.这次我们来自底向上的看下 Broker 端是如何接收然后分发处理消息,同时了解 RocketMQ 的 Broker 的线程模型. Netty 组件 如果你还记得上一节的内容的话那应该知道,NettyRomotingAbstract 有两个实现类,分别是 NettyRemotingClient 和

一.RocketMQ的消息存储基本介绍 先看一张图: 1.Commit log存储消息实体.顺序写,随机读.2.Message queue存储消息的偏移量.读消息先读message queue,根据偏移量到commit log读消息本身.3.索引队列用来存储消息的索引key使用mmap方式减少内存拷贝,提高读取性能.具体实现:FileChannel.map(RandomAccessFile) CommitLog以物理文件的方式存放,每台Broker上的CommitLog被本机器所有Consume

设计背景 消息中间件的本身定义来考虑,应该尽量减少对于外部第三方中间件的依赖.一般来说依赖的外部系统越多,也会使得本身的设计越复杂,采用文件系统作为消息存储的方式. RocketMQ存储机制 消息中间件的存储一般都是利用磁盘,一般是使用机械硬盘,但机械硬盘的速度比访问内存慢了n个数量级,一款优秀的消息中间件必然会将硬件资源压榨到极致,接下来看看rocketMq是如何做到高效存储的. RocketMQ存储模型 CommitLog 消息主体以及元数据的存储媒介,存储Producer端写入的消息主体内