prestigeding的博客

RocketMQ顺序消费在金融行业中的应用实战

掌握一到两门java主流中间件，是敲开BAT等大厂必备的技能，送给大家一个Java中间件学习路线，助力大家实现职场的蜕变。Java进阶之梯，成长路线与学习资料，助力突破中间件领域在消息发送端遇到性能瓶颈时是否有办法正确的评估瓶颈在哪呢？如何针对性的进行调优呢？1、Kafka 消息发送端监控指标其实Kafka早就为我们考虑好了，Kafka提供了丰富的监控指标，并提供了JMX的方式来获取这些监控指标，在客户端提供的监控指标如下图所示：主要的监控指标分类如下：producer-metrics消

我们离Apache顶级开源项目其实也很近。

架构师的职责是什么？到底需要写代码吗

本文不仅展示的Kafka分区迁移实战，更是体现一位架构师面面对线上故障做架构方案的设计思维。

kafka系列第二篇，该系列将见证笔者从Kafka小白进阶专家之路，欢迎各位小伙伴关注，一起前行。

RocketMQ是一款非常优秀的主流中间件，本文是RocketMQ系列的第52篇文章，重点阐述笔者在公司升级RocketMQ集群并开启ACL的真实经历，并且遇到的一些问题及其解决方案，实战性非常强。1、ACL机制的重要性某一天突然接到安全团队的通知，公司内网部署的RocketMQ集群安全性非常低，需要立马整改。接到安全团队的通知，马上开启了复盘，公司内部的RocketMQ集群还是基于RocketMQ4.1搭建的，存在重大安全隐患，因为生产环境的任意一台机器，不需要知道RocketMQ集群所在机器的密码

大家好，我是 CSDN2020博客之星亚军获得者，著有畅销书《RocketMQ技术内幕》、荣获RocketMQ社区优秀布道师。通过技术分享实现了从一个普通二类本科毕业生、从曾未接触高并发经验逆袭成为大厂资深架构师，个人觉得我的职场生涯还是比较励志的，具有普适性、可复制性。初入职场的我进入到一家国企，主要从事传统的电子政务系统的开发，在前5年中没有机会接触高并发，大数据，经过一年左右的迷茫，最终决定走上技术分享之路，主攻Java中间件，经过5年左右时间的分享，已经发表了12个Java主流中间件专栏，主要以源

看源码并不是目的，理解内部的运作机制才是关键，为遇到问题提供解决思路。

kafka系列第一篇，蕴含了笔者的学习方法，该系列将见证笔者从Kafka小白进阶专家之路，欢迎各位小伙伴关注，一起前行。

《RocketMQ技术内幕》一书作者、Apache顶级开源项目RocketMQ优秀布道师谈谈如何参与开源项目，打造自身影响力，助力职场进阶。

JavaLadder中间件兴趣圈，一定能成为你在java领域的进阶之梯，旨在成体系剖析Java主流中间件，构建互联网分布式架构体系，助力突破大厂，从源码分析、架构设计、线上故障案例剖析、实战等４个维度开展,目前已覆盖Netty、RocketMQ、Dubbo、Sentienl、Kafka、Canal、ElasticSearch、ElasticJob等12个专栏近300篇文章。由于公众号对历史文章不太友好，应粉丝朋友们的要求，我将公众号所有专栏内容同步到csdn仓库，希望对大家阅读带来便利。中间件技术是进

在内网环境中，超时问题，网络表示这个锅我不背。经过这次漫长的排查过程，对网络抓包、TCP滑动窗口、Netty线程模型的理解更加深刻了。

经过我的技术分享，让我结识了一大批忠实的粉丝，从粉丝们的反馈来说，工作经验在2,3年左右进入BATM等头部互联网企业的人数很多，他们真切的感觉到深入学习一两门中间件是非常有必要的。...

相信大家最近一定关注到一款重量级消息中间件Kafka发布了2.8版本，并且正式移除了对Zookeeper的依赖，背后的设计哲学是什么呢？仅仅只是减少了一个外部依赖吗？答案显然不会这么简单，容我慢慢道来。在解答为什么之前，我觉得非常有必要先来阐述一下Zookeeper的经典使用场景。1、Zookeeper的经典使用场景zookeeper是伴随着大数据、分布式领域的兴起。大数据中的一个非常重要的议题是如何使用众多廉价的机器来实现可靠存储。所谓廉价的机器就是发生故障的概率非常大，但单台的成本也非常低，分

试图通过生产环境升级RocketMQ这个具体事项阐述一名架构师如何做架构方案设计、如何落地，一名优秀的架构师需要具备的最核心素质是什么？

从从未接触过MQ，从零开始研究RocketMQ，最终出版《RocketMQ技术内幕》一书，在这里谈谈分享一下我的学习方法。

《RocketMQ技术内幕》作者、博客：https://www.codingw.net/，专注成体系剖析java主流中间件，打造完备的互联网分布式架构体系。已发布12个java主流中间件源码分析专栏。

写事件需要先注册才能往通道中写入数据？什么时候需要向通道注册写事件呢？业务线程池执行业务逻辑后，是如何通过IO线程将数据写入到网络中的呢？Netty中如何针对写限流？

在大厂面试中，特别是第一轮技术面试中，锁是一个非常高频的主题，在JDK中主要提供了两种方式：JUC(JAVA并发框架)中的ReentrantLock与synchronized关键字。那这两种有何区别呢?在实际工作中又如何选取呢？ReentrantLock 实现 synchronized 的语义，提供多线程的同步阻塞语义，即我们通常意义上的同步锁，但 ReentrantLock 的使用更加灵活，提供了synchronized关键字不具备的功能特性。1、可重入性ReentrantLock 与 synch

《RocketMQ技术内幕》作者、博客：https://www.codingw.net/，专注成体系剖析java主流中间件，打造完备的互联网分布式架构体系。已发布12个java主流中间件源码分析专栏。

目前按照我看过的一些开源框架，线程池中线程数量主要是根据应用的类型：IO密集型（2n +1 ），CPU密集型设置为 n + 1。但实际情况往往复杂的多，不会按照这个进行设置，进行这种设置，通常是框架层面，例如netty,dubbo这种底层通讯框架会参考这样的标准去设置，在实际业务中往往不会这样做。对于IO密集型网上还有一个公式：线程数 = CPU核心数/(1-阻塞系数)这个阻塞系数一般为0.8~0.9之间，可以取0.8或者0.9。我觉这个公式有一定的道理，考虑了阻塞的概念。在我们的业务开发中，基本

《RocketMQ技术内幕》作者、博客：https://www.codingw.net/，专注成体系剖析java主流中间件，打造完备的互联网分布式架构体系。一文详细剖析分布式存储领域的负载均衡(数据分片)与数据一致性方案设计理念

《RocketMQ技术内幕》作者、博客：https://www.codingw.net/，专注成体系剖析java主流中间件，打造完备的互联网分布式架构体系。

除了横向扩容外还有其他什么办法吗？

该系列已分别介绍了服务端、客户端的启动流程，本文将重点剖析Netty是如何封装NIO的读事件。温馨提示：本文虽然是源码分析，但强烈建议精读，因为根据源码阐述其背后的设计哲学，也用黑体进行了标注，请特别留意。文章目录１、读事件概述2、IO读事件从处理流程3、接受连接处理流程１、读事件概述关于Read事件在SocketChannel与ServerSocketChannel所对应的操作不一样，在SocketChannel中，则对应数据读，而在ServerSocketChannel中则被被封装成接受客户

2020博客之星评选活动刚刚落下帷幕，博客之星亚军获得者有感而发：技术分享之路让他收获良多，从一名没有互联网经验，未曾接触过分布式服务、大数据、高并发逆袭成为中通科技资深架构师，负责消息中间件、全链路压测、数据同步等的研发，特别是运维日均消息流转千亿级的消息集群。《RocketMQ技术内幕》一书的问世也直接来源于技术分享。直播地址：https://live.csdn.net/room/prestigeding/nC7S2glw我与哈罗高级技术专家梁勇合著的《RocketMQ实战与原理》专栏大优惠，原价

本文目录1、活动中心场景介绍2、事务消息实现原理3、事务消息实战3.1 UserServiceImpl 核心实现3.2 UserRegTransactionListener 核心实现3.2.1 实现 executeLocalTransaction3.2.2 实现 checkLocalTransaction3.3 代码获取1、活动中心场景介绍在电商系统上线初期，往往会进行一些“拉新”活动，例如活动部门提出新用户注册送积分、送优惠券活动。基于分布式、微服务的设计理念，通常的架构设计（子系统交互）如下图所示

『中间件兴趣圈』的RocketMQ免费专栏被阿里巴巴相中了，将公众号中的文章整理成电子书，更加方便读者朋友们的阅读。RocketMQ专栏相继获得CSDN2020年度博客之星专家评审团、阿里巴巴的高度好评，我想读者朋友们应该能窥探到一些信息，我觉得有两个方面：RocketMQ专栏的质量比较高中间件在互联网架构体系的重要性。接下来将简单介绍一下本文当之无愧的主角：《RocketMQ专栏》。RocketMQ专栏目录如下图所示：总的来看主要从如下三部分进行展开：线上故障分析结合笔者日

Netty是一款非常优秀的网络编程框架，是对NIO的二次封装，本文将重点剖析Netty服务端的启动流程，深入底层了解如何使用NIO编程服务端。 本文是笔者基于问题的启发式源码阅读技巧的展示，建议带着如下问题开始本文的阅读：ServerBootstrap 的 option 与 childOption 分别有什么作用服务端IO通道如何绑定事件链。1、Netty服务端启动示例基于Netty的使用示例如下：代码@1：创建主从多Reactor线程模型的Boss线程组，通常只需要设置一个线程，用于监听

『中间件兴趣圈』于2021年2月5号荣获CSDN2020度博客之星评选活动亚军，感谢CSDN、博客之星组委会以及为我投票的粉丝朋友们，我唯有持续输出高质量技术文章来回报大家的厚爱。纵观当下各大主流技术分享平台具备的评选活动，作为一个流量不太大的号主，CSDN博客之星亚军应该是我能获得的最高名次，首先在这里再次感谢CSDN、专家组对我博客质量的认可。荣获CSDN博客之星亚军让我非常激动，也引发我更深层次的思考，这又将对我今后的技术分享带来哪些改变呢？1、获奖历程CSDN博客之星是CSDN官方规格最高.

面试中一致性哈希算法被问到的概率非常大，本文将从如下三个方面探探一致性哈希算法，让大家轻松应对面试，并且说出宇宙不同的答案。一致性哈希算法经典实用场景一致性哈希算法通常不适合用于服务类负载均衡面试应对之策1、一致性哈希算法经典使用场景在数据库存储领域如果单表数据量很大，通常会采用分库分表，同样在缓存领域同样需要分库，下面以一个非常常见的Redis分库架构为例进行阐述。将上述3个Redis节点称之为分片，每一个节点存储部分数据，期间需要使用负载均衡算法，将数据尽量分摊到各个节点，充分发挥分布

本节将详细学习Netty4客户端的启动流程，我们从一个Netty客户端使用示例入手。1、Netty 客户端示例Netty客户端示例如下：对上面的步骤一一说明如下：代码@1：创建 NIO EventLoopGroup，NIO 事件轮询器。代码@2：创建Bootstrap实例，Netty提供的客户端操作工具类。代码@3：指定创建 Channel 类型，客户端是 NioSocketChannel。代码@4：通过option方法设置网络相关属性，可多次调用。代码@5：通过调用 handler 方法

Dubbo在众多的微服务框架中脱颖而出，占据RPC服务框架的半壁江山，非常具有普适性，熟练掌握 Dubbo的应用技巧后深刻理解其内部实现原理，让大家能更好的掌控工作，助力职场，特别能让大家在面试中脱颖而出。那Dubbo内部的设计理念，实现原理是什么呢？本文将结合官方提供的3张图，从如下三个方面介绍其内部的核心实现、以及如何指导实践。1、服务注册与发现机制Dubbo的服务注册与发现机制如下图所示：在Dubbo中存在4类角色：Registry注册中心。Consumer服务调用者、消费端。

笔者看来Netty的内核主要包括如下图三个部分：其各个核心模块主要的职责如下：内存管理主要提高高效的内存管理，包含内存分配，内存回收。网通通道复制网络通信，例如实现对NIO、OIO等底层JAVA API 的封装，简化网络编程模型。线程模型提供高效的线程协作模型。大家不妨回想一下在以往的面试的过程中，面试官通常会问：Netty 的线程模型是什么？主从多 Reactor 模型，相信大家都能脱口而出，然后呢？就没有然后了？线程模型在网络通信中主要解决什么样的问题？在 Nett

上一篇详细介绍了Netty的编解码的基本实现原理，本节将重点探讨网络编程中一种非常通用的协议设计方法论：协议头 + 消息体。所谓的通信协议就是通信双方共同遵循的一种“约定”，用于通信发送方将内容按照“通信协议”所规定的格式组装成**“二进制流”**，通信接收方按照“通信协议”所规定的格式正确的从二进制流中解码出一个个原始请求。那通信协议如何设计呢？1、通用的协议设计方法论在网络编程中，流行这一种经典的协议设计方法论：协议头 + 消息体。其设计的关键点如下：协议头的长度是固定的，通常为识别出一个

《RocketMQ实战与原理》专栏简介简介RocketMQ业界主流的消息中间件之一，承载公司核心业务消息的流转。对RocketMQ核心原理的理解与最佳实践成了开发与运维同学的必备技能。听很多同学抱怨，在学习中苦于缺少参考资料、遇到问题缺少专家指点、看源码掉入细节耗费大量时间精力、缺乏指引的最佳实践。我们在使用RocketMQ发送时会碰到System busy、Broker busy，导致发送超时。发生这种现象的背后原理是怎样的？我们有什么解决方案？一个消费组订阅多个Tag的情况，多个Tag用||分割

笔者比较“悲催”，临近年末由笔者维护的生产MQ集群中的一台物理机内存故障导致操作系统异常重启，持续10分钟中出现众多的应用发送客户端出现发送消息络超时，导致事故并定性为S1，笔者的“年终奖”。。。1、故障描述RocketMQ 集群采取的部署架构为2主2从，其部署架构如下图所示：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传其部署架构中一个非常明显的特点是一台物理机上分别部署了 nameserver，broker 两个进程。其中一台机器(192.168.3.100)的内存出现

摘要：笔者出品12个免费的源码分析专栏，覆盖RocketMQ、Kafka、Dubbo、Sentinel 等JAVA主流中间件，并借此实现年薪翻倍等成绩，对源码阅读有着深刻的理解。

本节将详细分析Netty事件传播机制，即事件链的实现机制。Netty4的事件链核心类如图所示：接下先详细介绍上述核心类的核心方法。1、ChannelPipeline“Channel流水线”，即Channel管道（事件处理链），其主要核心方法包括如下三类。添加类操作ChannelPipeline addFirst(String name, ChannelHandler handler)ChannelPipeline addFirst(EventExecutorGroup group, Str

《让天下没有难学的Netty》系列，基于 Netty，以源码分析为主要手段，关键流程给出流程图，从 通道篇、内存篇、性能篇三个维度深度剖析 Netty 的实现原理。

1、初识 Kafka Producer 生产者2、源码分析 Kafka 消息发送流程(文末附流程图)3、KafkaProducer Sender 线程详解（含详细的执行流程图）4、初始 Kafka Consumer 消费者5、源码分析Kafka 消息拉取流程6、Kafka与RocketMQ性能对比大揭秘...

从文件布局、数据写入方式、消息发送三个方面剖析RocketMQ与Kafka的性能差异的原因。

《让天下没有难学的Netty》系列，基于 Netty，以源码分析为主要手段，关键流程给出流程图，从 通道篇、内存篇、性能篇三个维度深度剖析 Netty 的实现原理。

影响力能有效表征你所在领域或行业的知名度、号召力、被认可度。影响力是一种无形的优质资产。2020年华为的天才少年最高档年薪获得者左鹏飞的事迹大家应该有所耳闻，一个博士毕业生入职华为200W年薪，翻开他的履历，原来他在博士期间以第一作者发表10余篇高质量论文，更是以第一作者在计算机操作系统最顶级学术会议之一的OSDI和计算机体系结构顶级学术会议上各发表一篇论文，其影响力可见一斑，高年薪入职华为便是水到渠成的事。牛人的成功或许无法复制，但能激励我们努力去打造自己的影响力，那作为一名程序员该如何打造影响力呢？

1、场景描述例如订单库进行了分库分表，其示例如下图所示：现在的需求是希望创建一个任务就将数据同步到MQ集群，而不是为每一个数据库实例单独创建一个任务，将其数据导入到MQ集群，因为同步任务除了库不同之外，表的结构、数据映射规则都是一致的。2、flinkx 的解决方案详解2.1 fink Stream API 开发基本流程使用 Flink Stream API 编程的通用步骤如下图所示：温馨提示：有关 Stream API 的详细内容将在后续的文章中展开，本文主要是关注 InputFormat

Canal 是阿里开源的基于 MySQL Binlog 数据同步组件，是互联网架构中数据异构的重磅组件，本专栏将从源码的角度探究其实现原理、实现细节，有利于更好的驾驭好Canal。1、数据异构之 Canal 初探（技巧篇）2、一文详解 Canal Instance 设计理念与定制开发思路3、探究 Canal EventParser 的设计与实现奥妙4、Canal 如何实现数据库库事务的一致性5、Canal binlog 日志管理器与GTID简介6、Canal binlog 日志 Dump 流程分

CSDN『唯有坚持不懈』又名『中间件兴趣圈』，旨在成体系剖析互联网JAVA主流中间件，涵盖 RocketMQ、Netty、Elasticjob、Dubbo、Canal、Sentinel、等互联网大厂必备技能，助力职场。1、源码分析RocketMQ专栏(40篇+)2、源码分析Sentinel专栏(12篇+)3、源码分析Dubbo专栏(28篇+)4、源码分析Mybatis专栏5、源码分析Netty专栏(18篇+)6、源码分析JUC专栏7、源码分析Elasticjob专栏8、Elasticsear

从整个类体系看网络设计RocketMQ 关于网络方面核心类图如下所示：接下来先一一介绍各个类的主要职责。RemotingServiceRPC 远程服务基础类。主要定义所有的远程服务类的基础方法：void start()：启动远程服务。void shutdown()：关闭。void registerRPCHook(RPCHook rpcHook)：注册 RPC 钩子函数，有利于在执...

亲爱的读者朋友，RocketMQ 实战专辑的全部内容即将更新完毕，前面的篇幅主要是介绍 RocketMQ 技术本身，本篇想和大家谈谈我是如何学习 RocketMQ 的，尽量做到授之以渔。我想大家都会有这样一个共识：光学理论没用，要实战。这个有一定的道理，但不应该成为阻碍我们学习的理由。对知识的学习我们当然需要优先学习研究工作中常用的技术，例如以微服务为例，现在市面上 Spring Clould ...

消息存储格式看文件编程从 commitlog 文件的设计来学文件编程我们知道 RocketMQ 的全量消息存储在 commitlog 文件中，每条消息的大小不一致，那如何对消息进行组织呢？当消息写入到文件中后，如果判别一条消息的开始与结束呢？首先基于文件的编程模型，首先需要定义一套消息存储格式，用来表示一条完整的消息，例如 RocketMQ 的消息存储格式如下图所示：从这里我们可以得到一...

同步刷盘、异步刷盘基于文件的编程模型中为了提高文件的写入性能，通常会引入内存映射机制，但凡事都有利弊，引入了内存映射、页缓存等机制，数据首先写入到页缓存，此时并没有真正的持久化到磁盘，那 Broker 收到客户端的消息发送请求时是存储到页缓存中就直接返回成功，还是要持久化到磁盘中才返回成功呢？ 这里又是一个抉择，是在性能与消息可靠性方面进行的权衡，为此 RocketMQ 提供了多种持久化策略：...

Nameserver 在 RocketMQ 整体架构中所处的位置就相当于 ZooKeeper、Dubbo 服务化架构体系中的位置，即充当“注册中心”，在 RocketMQ 中路由信息主要是指主题（Topic）的队列信息，即一个 Topic 的队列分布在哪些 Broker 中。Nameserver 工作机制Topic 的注册与发现主要的参与者：Nameserver、Producer、Consu...

RocketMQ 是一款非常优秀的分布式，里面有很多的编程技巧值得我们借鉴，本文从并发编程角度，从 RocketMQ 中挑选几个示例与大家一起来分享沟通一下。读写锁的使用场景在 RocketMQ 中关于 Topic 的路由信息主要指的是一个 Topic 在各个 Broker 上的队列信息，而 Broker 的元数据又包含所属集群名称、Broker IP 地址，路由信息的写入操作主要是 Brok...

消息轨迹消息轨迹含义一条消息什么时候由哪台机器产生的、发送的耗时、消息大小、发送状态、存储在哪个 Broker 上、什么时候存储的以及存储在哪台 Broker 上、什么时候消费的、消费状态等信息，这些信息即消息轨迹，用于追踪消息从诞生到被消费的整个生命周期。这些信息对于业务同学排查定位有着重要的意义，发送和消费往往在不同的业务部门。有了消息轨迹后一条消息有没有发送，发送成功了没，有没有消费一...

本文的目的不是详细介绍 RocketMQ-Console 的使用方法，主要对一些关键点（更多是会有疑问的点）进行介绍，避免对返回结果进行想当然。集群信息一览可以通过 Cluster 查看一个集群中所有的 Broker 信息，包含主节点、从节点，有时候发现主节点、从节点的一些统计指标存在一些偏差，例如 Slave 节点的 Today Producer Count 比主节点的低或者高，会简单认为...

前言​对集群健康状况、使用主题、消费组资源的巡检，发现达到阈值则发送告警信息给管理员或者资源申请者。监控是告警的基础，告警的巡检基于前面两篇文章中监控采集到的数据。​告警的重要性不必过多地赘述，RocketMQ 集群往往承载着公司核心业务流转。如果集群不可用往往影响是全公司的业务，事故责任是公司最高级别的。本文从告警项的设计、告警流程、告警实战给出指导建议，在实践中以此为思路扩展完善，实现自...

集群节点进程神秘消失现象描述接到告警和运维反馈，一个 RocketMQ 的节点不见了。此类现象在以前从未发生过，消失肯定有原因，开始查找日志，从集群的 broker.log、stats.log、storeerror.log、store.log、watermark.log 到系统的 message 日志没发现错误日志。集群流量出入在正常水位、CPU 使用率、CPU Load、磁盘 IO、内存、带...

前言在 RocketMQ 集群的运维实践中，无论线上 Broker 节点启动和关闭，还是集群的扩缩容，都希望是平滑的，业务无感知。正所谓 “随风潜入夜，润物细无声” ，本文以实际发生的案例窜起系列平滑操作。优雅摘除节点案例背景自建机房 4 主 4 从、异步刷盘、主从异步复制。有一天运维同学遗失其中一个 Master 节点所有账户的密码，该节点在集群中运行正常，然不能登陆该节点机器终究存在安...

前言在 RocketMQ 体系中，有集群、主题、消费组，集群又包括 NameSrv 和 Broker。本篇主要介绍 RocketMQ 的集群监控设计应该考虑哪些方面，以及如何实现。下一篇文章介绍主题、消费组方面的监控。本篇的介绍基于实战中 4 主 4 从，主从异步复制的架构模式。监控项设计集群监控的目的记录集群健康状态，具体监控项见下图：节点数量如果集群中是 4 主 4 从架构，那么集...

前言主题和消费组通常使用方比较关心的资源，发送方关注主题，消费方关注消费组。管理员更侧重关注集群的健康状况。本文介绍主题和消费组的监控实战，包括监控项的设计、及每个监控项的代码实现。监控项设计我们先把主题监控和消费监控统称为资源监控，下图分列了主题和消费组包含的监控项。主题监控从发送速度、发送耗时、消息大小、日消息量方面整理主题监控项，下面分别介绍这些监控项的重要性。发送速度通过实...

前言我们在生产环境搭建一个集群时，需要对该集群的性能进行摸高。即：集群的最大 TPS 大约多少，我们做到心里有数。通常我们日常的实际流量控制在压测最高值的 1/3 到 1/2 左右，预留一倍到两倍的空间应对流量的突增情况。如何进行压力测试呢？写段发送代码测试同学通过 JMeter 进行压力测试，或者代码中通过多线程发送消息。这种方式需要多台不错配置的测试机器。通过 RocketMQ 自带...

前言本篇从系统参数和集群参数两个维度对 RocketMQ 集群进行优化，目的在于 RocketMQ 运行的更平稳。平稳往往比单纯提高 TPS 更重要，文中基于实际生产环境运行情况给出，另外在后面文章中会介绍由于参数设置而引发集群不稳定，业务受到影响的踩坑案例。系统参数调优在解压 RocketMQ 安装包后，在 bin 目录中有个 os.sh 的文件，该文件由 RocketMQ 官方推荐系统参...

问题描述在 RocketMQ 消息消费方面一个最常见的问题是消息积压，其现象如下图所示：所谓的消息积压：就是 Broker 端当前队列有效数据最大的偏移量（brokerOffset）与消息消费端的当前处理进度（consumerOffset）之间的差值，即表示当前需要消费但没有消费的消息。问题分析与解决方案项目组遇到消息积压问题通常第一时间都会怀疑是 RocketMQ Broker 的问题...

本篇整理在运维 RocketMQ 集群时的常用命令，明白命令的含义，在集群运维时得心应手，下面命令均在实际环境中执行过。集群命令汇总集群列表命令 clusterList 用于查看集群各个节点的运行情况。可以看到该集群中有几个节点、主节点还是从节点、以及每个节点的写入 TPS 和读出的 TPS 等。命令示例：$ bin/mqadmin clusterList -n x.x.x.x:9876...

通过上文的讲解，各位读者朋友们应该对 DefaultLitePullConsumer 有了一个全面的理解，但会不会觉得意犹未尽之感，因为在实战环节只是给出了一个 Demo 级别的示例，本篇将一个大数据领域的消息拉取批处理场景丰富一些 DefaultLitePullConsumer 的使用技巧。场景描述现在订单系统会将消息发送到 ORDER_TOPIC 中，大数据这边需要将订单数据导入自己的计算...

经过前面的篇幅，我相信大家已经掌握了消息消费方面的常用使用技巧了，本篇将对消息消费领域的其他几个特殊场景进行一些实战演示，并穿插一些原理解读。顺序消费业务场景描述现在开发一个银行类项目，对用户的每一笔余额变更都需要发送短信通知到用户。如果用户同时在电商平台下单，转账两个渠道在同一时间进行了余额变更，此时用户收到的短信必须顺序的，例如先网上购物，消费了 128，余额 1000，再转账给朋友 2...

上篇已详细介绍了 DefaultMQPushConsumer 的核心属性与消息消费相关的理论，本篇将重点介绍在使用过程中容易出现的问题，并加以解决。ConsumeFromWhere 注意事项下面首先先看一段 RokcetMQ PUSH 模式消费者的常见使用方式：构建需要通过 setConsumeFromWhere(…) 指定从哪消费，正如上篇提到的，RocketMQ 支持从最新消息、最早消...

在《消息消费 API 与版本变更》中也提到 DefaultMQPullConsumer（PULL 模式）的 API 太底层，使用起来及其不方便，RocketMQ 官方设计者也注意到这个问题，为此在 RocketMQ 4.6.0 版本中引入了 PULL 模式的另外一个实现类 DefaultLitePullConsumer，即从 4.6.0 版本后，DefaultMQPullConsumer 已经被标...

从本篇开始我们将详细介绍 RockeMQ 的消息消费端的 API。消息消费类图RocketMQ 消费端的 API 如下图所示：其核心类图如下所示。MQAdminMQ 一些基本的管理功能，例如创建 Topic，这里稍微有点奇怪，消费端应该不需要继承该接口。该类在消息发送 API 章节已详细介绍，再次不再重复说明。MQConsumerMQ 消费者，这个接口定义得过于简单，如果该接口需要...

PUSH 模式是对 PULL 模式的封装，类似于一个高级 API，用户使用起来将非常简单，基本将消息消费所需要解决的问题都封装好了，故使用起来将变得简单。与此同时，需要将其用好，那还是需要了解其内部的工作原理以及 PUSH 模式支持哪些参数，这些参数是如何工作的，在使用时有什么注意的呢？DefaultMQPushConsumer 核心参数一览与内部原理DefaultMQPushConsumer...

本篇将结合自己使用 RocketMQ 的经验，对消息发送常见的问题进行分享，基本会遵循出现问题，分析问题、解决问题。No route info of this topic无法找到路由信息，其完整的错误堆栈信息如下：而且很多读者朋友会说，Broker 端开启了自动创建主题也会出现上述问题。RocketMQ 的路由寻找流程如下图所示：上面的核心关键点如下：如果 Broker 开启了自...

事务消息应用场景首先需要申明的是，事务消息与业界用 RocketMQ 解决分布式事务，并不是一回事。RocketMQ 引入事务消息，主要是要解决什么问题呢？接下来以电商一个登录送积分的示例来展开本文的叙述。在互联网电商发展的初期，为了提高用户的活跃度，通常会采取这样一个提高用户活跃度：一个用户每一天首次登录送积分活动。在没有提出送积分活动时，用户登录的代码如下：public Map<...

本篇将开始结合各种使用场景，运用合适的 API 解决具体的实际问题。消息发送方式RocketMQ 支持同步、异步、Oneway 三种发送方式。同步：客户端发起一次消息发送后会同步等待服务器的响应结果。异步：客户端发起一下消息发起请求后不等待服务器响应结果而是立即返回，这样不会阻塞客户端子线程，当客户端收到服务端（Broker）的响应结果后会自动调用回调函数。Oneway：客户端发起消息...

经过前面几篇的讲解，我相信大家对 RocketMQ 的消息发送已经有了一个较为详细的认识，已经能够非常顺畅地使用 DefaultMQProducer 相关的 API。本篇将重点关注 DefaultMQProducer 中的相关属性，以便从这些属性窥探 RocketMQ 消息发送较为底层的原理。从 DefaultMQProducer 的类图就可以看出其属性主要来源于 ClientConfig、...

在正式进入 RocketMQ 的学习之前，我觉得有必要梳理一下 RocketMQ 核心概念，为大家学习 RocketMQ 打下牢固的基础。RocketMQ 部署架构在 RocketMQ 主要的组件如下。NameServerNameServer 集群，Topic 的路由注册中心，为客户端根据 Topic 提供路由服务，从而引导客户端向 Broker 发送消息。NameServer 之间的节...

RocketMQ 在捐赠给 Apache 成为 Apache 基金会顶级项目之前的版本为 3.x，捐赠给 Apache 的版本号从 4.0.0 开始。由于 RocketMQ 在成为 Apache 顶级项目之前也一直在开源，故 4.0.0 版本其版本包含的内容就非常全面了，从 4.0.0 后面的进化主要是提供新的功能，例如消息轨迹、ACL、多副本等新功能，RocketMQ 的内核非常稳定，客户端的变...

本文主要分如下几个部分展开：Linux 服务器安装 RocketMQ、RocketMQ-ConsoleIDEA 中搭建可调试环境Linux 安装 RocketMQ、RocketMQ-Console安装 RocketMQStep1：从如下地址下载 RocketMQ 安装包cd /opt/applicationwget https://mirrors.tuna.tsinghua.ed...

在正式进入RocketMQ的学习之前，我觉得有必要梳理一下RocketMQ核心概念，为大家学习RocketMQ打下牢固的基础。1、RocketMQ部署架构在RocketMQ主要的组件如下：NameserverNameserver集群，topic的路由注册中心，为客户端根据Topic提供路由服务，从而引导客户端向Broker发送消息。Nameserver之间的节点不通信。路由信息在Nameserver集群中数据一致性采取的最终一致性。Broker消息存储服务器，分为两种角色：Master

本文主要分如下几个部分展开：Linux服务器安装RocketMQ、RocketMQ-ConsoleIDEA中搭建可调试环境1、Linux安装RocketMQ、RocketMQ-Console1.1安装RocketMQStep1：从如下地址下载RocketMQ安装包cd /opt/applicationwget https://mirrors.tuna.tsinghua.edu.cn/apache/rocketmq/4.7.1/rocketmq-all-4.7.1-bin-release.z

本文将结合自己使用RocketMQ的经验，对消息发送常见的问题进行分享，基本会遵循出现问题，分析问题、解决问题。1、No route info of this topic无法找到路由信息，其完整的错误堆栈信息如下：而且很多读者朋友会说Broker端开启了自动创建主题也会出现上述问题。RocketMQ的路由寻找流程如下图所示：上面的核心关键点如下：如果Broker开启了自动创建Topic，在启动的时候会默认创建主题：TBW102，并会随着Broker发送到Nameserver的心跳包汇报给Nam

Canal 的 dump 支持串行和并行模式两种模式，本篇重点梳理 dump 的核心流程，以便对 dump 过程有一个充分的了解，更好的理解 Canal 的实现原理与细节，下一篇中将重点关注Canal是如何引入并行模式来提高dump的性能，即并行编程相关的技巧。从前面的文章我们得知 Canal binlog 日志解析的基本流程如下图所示：解析来重点梳理一下 dump 命令的发送逻辑，特别是日志的处理流程，一些基本的日志格式。1、 dump 流程分析在 Canal 中 dump 方法声明如下：带

本节目录1、Canal 位点管理（日志管理器）1.1 类图1.2 日志管理器使用方法2、MySQL GTID 扫盲正如上文提到的那样，在 Canal Instance 启动的时候，首先会查询日志管理器中查找上一次的同步位点，如果没有查询到，则默认会从最新的位点开始同步，但如果每一次启动Instance都从最后开始同步，其数据完整性无法保证，正确的做法是在数据同步的过程中应该记录位点并持久化，重新启动后按照继续从上一次的位置继续同步，实现真正的增量同步。本文就是来详细探讨 Canal的几个日志管理器，并来

本文将详细剖析Canal在初次启动时如何定位同步位点，行为思路先源码，再辅以流程图进行说明，并在总结部分使用思维导图进行总结，试图引发各位的讨论。本节目录1、Canal定位启动位点1.1 查找位点1.2 基于时间戳从查找 binlog 位点2、总结1、Canal定位启动位点在一个 Canal Instance 实例启动时，在向 MySQL 发送 dump 命令之前，首先先得计算该从 binlog 的什么位置开始同步，初次启动时如何寻找位点等。其代码如下图所示：从这里可以看成，将调用 findSta

本文将主要介绍在 EventParser binlog 日志同步流程中关于环形缓存区的使用技巧。1、环形缓存区关系型数据库讲究的是ACID 4个特性，故引入了数据库事务的概念，一个数据库事务中的多条SQL引发的多条数据变更要么全部成功，要么全部失败，即数据的一致性，那同样在数据同步的场景，在解析一个事务的 binlog 日志时，一次数据同步应该至少以事务为单位，一个事务内的所有 Event 应该作为一个批次提交到数据消费端，让消费端有能力一次同步一个事务中的数据，而不是一条一条变更日志的处理，这样容易造

先来一个自我介绍：《RocketMQ技术内幕》作者、『中间件兴趣圈』公众号维护者、2019 年 RocketMQ 社区优秀布道师评选斩获第一名、2019 年度CSDN博客之星TOP10获得者，目前就任中通科技技术平台部担任资深架构师。一个二类本科毕业生，无BAT等一线互联网企业背景，通过分享技术，主攻中间件原理分析与技术应用，构建自己的互联网架构技术栈，从而取得目前的成就。接下来先用一张思维导图来展示目前已有的研究成果：温馨提示：上图是『中间件兴趣圈』已覆盖的知识图谱，文末有指引可获得原图。接

本文将从三个方面深度剖析 EventParser 组件。从官方文档看 EventParser 的设计思想从 EventParser 初始化了解内部的是可配置项从 EventParser 的启动窥探其工作实现原理温馨提示：本篇篇幅较长，如果耐心阅读一定会有不错的收获，为了提高阅读体验，本文所有源码都是通过截图方式，大家可以重点阅读对应的文字说明，并在文末进行了总结。1、官方文档看 EventParser首先我们先从官方文档来看 EventParser 的整体设计，其架构设计图如下所示：

详细介绍了 Canal Instance 的设计理念，文末更是有彩蛋，抛出 canal 定制开发的思路与源码研究 Canal 的方法。

数据异构重磅武器 Canal 系列正式开始连载，本文是该系列的第一篇，从应用场景、架构设计理念 再到 在开发工具中跑通Demo，为后续带着自己的思考深入学习 canal打下坚实基础。如果本文对你有所帮助，麻烦点亮在看，能同时转发朋友圈更好

一个草根程序员参与开源项目的另外一种方式。

本文行文思路：先抛出源码阅读方法，然后结合Sentinel创作过程谈谈具体是如何运用这些技巧，最后解答几个源码阅读的误区。Sentinel 系列共包含15篇文章，主要以源码分析为手段，图文并茂的方式对 Sentinel 的架构设计理念、核心实现要点进行了一一剖析，并加以实战分析与思考。很多朋友都在询我是如何阅读源码的。对此可归纳为如下几个要点，然后结合 Sentienl 源码分析专栏对各个要点进行拆解，对源码阅读方法进行一次“实战”。阅读官方文档，从全局了解待学习框架能解决什么样的问题，整体架构.

看到标题中的几个关键字系统自适应限流是不是觉得高大上，这个自适应又是如何实现的呢？1、Sentinel 系统自适应概述从官方了解到 Sentienl 系统自适应限流是一个全局的概念，对应用入口流量统一进行统一控制，结合应用的机器负载、CPU 使用率，总体平均响应时间、入口 QPS 和并发线程数等几个维度的监控指标从而决定是否调用进行限流操作。为了有一个直观的感受，我们可以从官方的运维平台看看其系统自适应限流的操作界面：RT、线程数、入口QPS这三个指标是可以通过采集调用信息进行统计计算的，那系统LO

1、问题现象首先接到项目反馈使用 RocketMQ 会出现如下错误：错误信息关键点：MQBrokerException：CODE:2 DESC:[TIMEOUT_CLEAN_QUEUE]broker busy,start flow control for a while,period in queue：205ms，size of queue:880。由于项目组并没有对消息发送失败做任何补偿，导致丢失消息丢失，故需要对这个问题进行深层次的探讨，并加以解决。2、问题分析首先我们根据关键字：TIMEO

本文是源码分析 Sentinel 系列的第十三篇，已经非常详细的介绍了 Sentinel 的架构体系、滑动窗口、调用链上下文、限流、熔断的实现原理，相信各位读者朋友们对Sentinel有一个较为体系化的认知了，这个时候是该开始如何在生产环境进行运用了。本文将以 Dubbo 服务调用为案例剖析场景，尝试对官方提供的 Dubbo 适配器做一个研究学习并对此做出自己的评价，抛出我的观点，期待与大家共同探讨，交流。一个 Dubbo RPC 的简易调用过程如下图所示：消费者会维护一个服务提供者列表，然后再

源码分析Sentinel系列是打造的又一重磅专题，详细介绍了限流、熔断的实现原理。1、Alibaba Sentinel 限流与熔断初探(技巧篇)2、源码分析 Sentinel 之 Dubbo 适配原理3、源码分析 Alibaba sentinel 滑动窗口实现原理(文末附原理图)4、寻找一把进入 Alibaba Sentinel 的钥匙(文末附流程图)5、Sentinel 调用上下文环境实现原理6、源码分析 Sentinel 实时数据采集实现原理7、源码分析 RateLimiter Smoot

本节目录1、集群限流使用场景2、集群限流与单机限流的异同思考3、探究集群限流实现原理3.1 ClusterBuilderSlot 详解3.2 集群限流模式实现原理3.2.1 DefaultClusterTokenClient 详解3.2.2 DefaultTokenService 详解4、总结1、集群限流使用场景首先一个服务有三个服务提供者，但这三台集群的硬件配置不一样，如图所示：为了充分...