RocketMQ简介 RocketMQ是一款开源的分布式消息系统,基于高可用分布式集群技术,提供低延时的.高可靠.万亿级容量.灵活可伸缩的消息发布与订阅服务. 它前身是MetaQ,是阿里基于Kafka的设计使用Java进行自主研发的.在2012年,阿里将其开源, 在2016年,阿里将其捐献给Apache软件基金会(Apache Software Foundation,简称为ASF),正式成为孵化项目.2017 年,Apache软件基金会宣布RocketMQ已孵化成为 Apache顶级项目(Top

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

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

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

通过DefaultMQPullConsumer作为默认实现,这里的启动过程和Producer很相似,但相比复杂一些 [RocketMQ中Producer的启动源码分析] DefaultMQPullConsumer的构造方法: public DefaultMQPullConsumer(final String consumerGroup, RPCHook rpcHook) { this.consumerGroup = consumerGroup; defaultMQPullConsumerImpl

流式计算中处理延迟是一个非常重要的监控metric flink中通过开启配置   metrics.latency.interval  来开启latency后就可以在metric中看到askManagerJobMetricGroup/operator_id/operator_subtask_index/latency指标了 如果每一条数据都打上时间监控 输出时间- 输入时间,会大量的消耗性能 来看一下flink自带的延迟监控是怎么做的 其实也可以想到原理很简单,就是在source周期性的插入一条特

RocketMQ中通过DefaultMQProducer创建Producer DefaultMQProducer定义如下: public class DefaultMQProducer extends ClientConfig implements MQProducer { protected final transient DefaultMQProducerImpl defaultMQProducerImpl; private String createTopicKey = MixAll.AU

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

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

Zookeeper源码分析目录如下 1. [Zookeeper]源码分析之序列化 2. [Zookeeper]源码分析之持久化(一)之FileTxnLog 3. [Zookeeper]源码分析之持久化(二)之FileSnap 4. [Zookeeper]源码分析之持久化(三)之FileTxnSnapLog 5. [Zookeeper]源码分析之Watcher机制(一) 6. [Zookeeper]源码分析之Watcher机制(二)之WatchManager 7. [Zookeeper]源码分析之

前文目录链接参考: 消息队列的一些场景及源码分析,RocketMQ使用相关问题及性能优化 https://www.cnblogs.com/yizhiamumu/p/16694126.html 消息队列的对比测试与RocketMQ使用扩展 https://www.cnblogs.com/yizhiamumu/p/16677881.html 消息队列为什么选用redis?聊聊如何做技术方案选型?https://www.cnblogs.com/yizhiamumu/p/16573472.html 分布

目录 1.DLedger关于选主的核心类图 1.1 DLedgerConfig 1.2 MemberState 1.3 raft协议相关 1.4 DLedgerRpcService 1.5 DLedgerLeaderElector 1.6 DLedgerServer 2.源码分析Leader选举 2.1 DLedgerLeaderElector 类图 2.2 启动选举状态管理器 2.3 选举状态机状态流转 2.4 投票与投票请求 2.5 心跳包与心跳包响应 温馨提示:<RocketMQ技术内幕>

目录 1.DLedgerEntryPusher 1.1 核心类图 1.2 构造方法 1.3 startup 2.EntryDispatcher 详解 2.1 核心类图 2.2 Push 请求类型 2.3 doWork 方法详解 3.EntryHandler 详解 3.1 核心类图 3.2 handlePush 3.3 doWork 方法详解 4.QuorumAckChecker 4.1 类图 4.2 doWork 详解 温馨提示:源码分析RocketMQ DLedger 多副本系列连载中: 1.

1.概述 Producer 发送消息.主要是同步发送消息源码,涉及到 异步/Oneway发送消息,事务消息会跳过. Broker 接收消息.(存储消息在<RocketMQ 源码分析 —— Message 存储>解析) 2.Producer 发送消息 DefaultMQProducer#send(Message) 1: @Override 2: public SendResult send(Message msg) throws MQClientException, RemotingExcept

Java版本:8u261. 1 简介 ScheduledThreadPoolExecutor即定时线程池,是用来执行延迟任务或周期性任务的.相比于Timer的单线程,定时线程池在遇到任务抛出异常的时候不会关闭整个线程池,更加健壮(需要提一下的是:ScheduledThreadPoolExecutor和ThreadPoolExecutor一样,如果执行任务的过程中抛异常的话,这个任务是会被丢弃的.所以在任务的执行过程中需要对异常做捕获处理,有必要的话需要做补偿措施). 传进来的任务会被包装为Sch

最近在学习RocketMQ相关的东西,在学习之余沉淀几篇笔记. RocketMQ有很多值得关注的设计点,消息发送.消息消费.路由中心NameServer.消息过滤.消息存储.主从同步.事务消息等等. 本篇不需要你有使用RocketMQ的前置条件,完全从消息存储的直接实现上来分析RocketMQ的Store包. 0.队列文件存储思考 在开始之前,先来做一个简单思考. MQ既然要接收大量的消息,这些消息如果全部存在内存,是否可行呢? 在机器内存的限制下当然不行,那么就要考虑非内存的存储方式. 数据库

前文回顾 CommitLog篇 --[RocketMQ源码分析]深入消息存储(1) ConsumeQueue篇 --[RocketMQ源码分析]深入消息存储(2) 前面两篇已经说过了消息如何存储到CommitLog,以及ConsumeQueue的构建流程,到了第三篇,我们有一个不得不跨过的坎儿,MappedFile -- 内存文件映射. MappedFile的存在是RocketMQ选择将消息直接存储到磁盘的关键因素,在第一篇CommitLog存储流程开篇中,我就写过一个思路. 即用到内存又用到本

Solr4.8.0源码分析(16)之SolrCloud索引深入(3) 前面两节学习了SolrCloud索引过程以及索引链的前两步,LogUpdateProcessorFactory和DistributedUpdateProcessor.本节将详细介绍了索引链的第三步DirectUpdateHandler2和UpdateLog. 1. DirectUpdateHandler2.ADD DirectUpdateHandler2过程包含了Solr到Lucene的索引过程,在整个索引链中是最复杂也最重要

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

一.前言 在分析了锁框架的其他类之后,下面进入锁框架中最后一个类ReentrantReadWriteLock的分析,它表示可重入读写锁,ReentrantReadWriteLock中包含了两种锁,读锁ReadLock和写锁WriteLock,可以通过这两种锁实现线程间的同步,下面开始进行分析. 二.ReentrantReadWriteLock数据结构 分析源码可以知道,ReentrantReadWriteLock底层是基于ReentrantLock和AbstractQueuedSynchroni

在PullConsumer中,有关消息的拉取RocketMQ提供了很多API,但总的来说分为两种,同步消息拉取和异步消息拉取 同步消息拉取以同步方式拉取消息都是通过DefaultMQPullConsumerImpl的pullSyncImpl方法: private PullResult pullSyncImpl(MessageQueue mq, SubscriptionData subscriptionData, long offset, int maxNums, boolean block, l