RocketMQ
文章平均质量分 77
rocketmq部署、源码讲解
鮀城小帅
在工作中一步步学习、进步,充实工作也充实生活。
展开
-
RocketMq: Windows环境-单机部署和多种主从集群场景部署
windows环境下搭建 activemq 的单机部署、双主双从集群、双主集群部署原创 2022-12-06 17:08:01 · 697 阅读 · 0 评论 -
RocketMq: Linux环境-单机部署和主从集群部署
说明:rocketmq需要jdk环境。(1)下载jdk安装包https://www.oracle.com/technetwork/java/javase/archive-139210.html 下载jdk,这边选择的是jdk-8u144-linux-x64.tar.gz(2)下载rocketmq安装包http://rocketmq.apache.org/dowloading/releases/ 下载RocketMQ,这边选择的版本是rocketmq-all-4.7.0-bin-release.zip(1)上原创 2022-12-05 10:37:04 · 659 阅读 · 0 评论 -
04 系统面临的现实问题:第三方客户系统的对接耦合性太高,经常出问题
1. 第三方:客户物流系统明确一点,下订单之后,大部分核心步骤,都是在本公司的系统内完成,如订单状态更新、库存扣减、优惠券派发等。而其中下单并支付成功后的发货是交由第三方仓储系统负责的。具体流程如下:调度流程:下单后,选择去找一个距离你用户最近的一个仓库,然后从里面调度一些商品进行发货,在发货的时候还需要调用第三方物流公司的系统,通知物流公司去仓库里取货发货。2.系统间的耦合什么是耦合?以上图中圈红的部分为例,负责订单系统的工程师下单成功后,调用促销系统的接口来发放优惠券原创 2021-06-14 14:49:31 · 1260 阅读 · 0 评论 -
05 系统面临的现实问题:大数据团队需要订单数据,该怎么办?
1.所谓大数据每天如果有100万用户来访问你的APP,积累下来的一些浏览行为、访问行为、交易行为都是各种数据,这个数据量很大,可以称之为“大数据”。大数据团队每天要做的就是尽可能的搜集每天100W用户在你的APP上的各种行为数据。比如:用户搜索了什么、点击了什么、评论了什么等。以及最为核心的订单数据。2.大数据团队的数据来源可能带来的问题大数据团队的数据包含了我们的订单数据,那么这些数据怎么去提取?最low的做法:直接从订单库里select数据出来。这种情况下是将订单数据库对外暴露,原创 2021-06-14 15:51:01 · 369 阅读 · 0 评论 -
06 阶段复习-总结
原创 2021-06-14 16:15:56 · 79 阅读 · 0 评论 -
部署: 消息中间件集群生产部署架构规划思维导图
原创 2021-07-15 07:02:43 · 335 阅读 · 0 评论 -
44 源码:从Github拉取RocketMQ源码以及导入IntellijIDEA中
1. 从Github上拉取RocketMQ源码进入RocketMQ的github网站,地址为:https://github.com/apache/rocketmq进入上述url地址后,可以看到一个“clone or download” 的按钮,在里面点击“Download ZIP” ,就可以下载RocketMQ的源码了。下载到本地后,是一个master.zip包,解压缩之后是 rocketmq-master目录,这里就存放了RocketMQ最新 master 分支的源码了。2. 将Roc原创 2021-07-29 21:30:39 · 536 阅读 · 0 评论 -
45 源码:在Intellij IDEA中启动NameServer、Broker以及本地调试源码
在将RocketMQ源码导入开发工具后,主要有以下几步要做:编译 启动namesrv 启动broker1. 编译解压导入idea,修改配置文件pom.xml,jdk编译版本为1.8在IDEA的Ternimal界面执行编译:# 编译mvn -Prelease-all -DskipTests clean install -U2. 启动namesrv第一种方式:在namesrv子工程进入org.apache.rocketmq.namesrv.NamesrvStartu.原创 2021-07-29 22:23:31 · 609 阅读 · 2 评论 -
27 发送消息零丢失方案:RocketMQ事务消息的实现流程分析
1.解决消息丢失的第一个问题:订单系统推送消息丢失当前的问题,在订单系统推送消息到MQ的过程中,就因为常见的网络故障之类的问题,导致消息就丢失了。在RocketMQ中,有这么一个功能,就是事务消息的功能,凭借这个事务级的消息机制,就可以让我们确保订单系统推送出去的消息一定会成功写入MQ里,绝对不会半路就搞丢了。2.事务消息:half消息在基于RocketMQ的事务消息机制中,我们首先要让订单系统去发送一条half消息到MQ去,这个half消息本质就是一个订单支付成功的消息,只不过可以理解原创 2021-06-28 22:16:53 · 2474 阅读 · 0 评论 -
02 系统面临的现实问题:日益增加的并发与同步响应延迟
订单架构如下:1. 系统压力来源之一: 日益增加的并发访问量在当前的案例中,每天几十万的订单量,对应了百万次下单操作和订单查询等操作,如果将其均分到5个小时内,也就是每秒几十次请求而已,但账不是这么算的。电商系统的访问量受两方面影响:一个是用户习惯,一个是平台的营销策略;前者决定了平均每一天用户访问的最高峰,也就是前面说过的2000/s的请求,后者决定了大促当前的某个时间段内每秒1w请求的结果。总结一下,就是真实的系统访问负载应该是一个半圆形的曲线:如图,中间部分是访问高峰期,那原创 2021-06-14 12:08:04 · 265 阅读 · 0 评论 -
42 线上生产环境的RocketMQ集群进行消息轨迹的追踪
1. 消息轨迹RocketMQ支持在生产环境里查询一条消息的轨迹。总得来说,我们可以知道一个消息是什么时候从哪个Producer发送出来的?它在Broker端是进入到了哪个Topic里去的?它在消费者层面是被哪个Consumer什么时候消费出来的?2.消息轨迹的开启配置想要使用上面说到的RocketMQ支持的消息轨迹功能,主要配置过程如下:首先需要在broker的配置文件里开启: traceTopicEnable=true 选项,此时就会开启消息轨迹追踪的功能。开启以上配置项后,在启原创 2021-07-27 20:42:06 · 1325 阅读 · 0 评论 -
29 除了使用事务消息方案,还有什么解决发送消息零丢失的方案
1.事务消息方案的弊端在RocketMQ中,生产者发送消息的时候,可能存在消息的丢失,即消息根本没有进入到MQ就丢了。前面说过了,通过使用RocketMQ事务消息机制去发送消息到MQ,一定是可以保证消息必然发送到MQ的,不会丢。但是,要注意的是,这一整个流程中,先得发送half消息,完了生产者还得发送rollback or commit的请求,要是中间有点什么问题,MQ还得回调生产者的接口。这种复杂的机制很可能导致整体性能的拉低,从而导致吞吐量降低。2.基于重试机制来确保消息到达原创 2021-06-29 12:21:16 · 170 阅读 · 1 评论 -
16 基于MQ实现秒杀订单系统的异步化架构以及精准扣减库存的技术方案
1.秒杀场景下的抢购流程分析(1)商品页面问题在秒杀活动当晚,有大量用户(可能多大几十万甚至上百万)会集中登录到APP上,然后同时访问这个秒杀活动的商品页面,这个频繁访问商品页面的问题已经被商品技术团队解决掉了。(2)订单系统与数据库压力问题在抢购开始时,商品按钮从灰色不可用变成可点击状态。然后瞬间可能几十万甚至上百万人会同时点击这个按钮,尝试对后台发起请求去抢购这个商品。在这个过程中,和往常购买商品一样,比如下订单、支付、扣减库存以及后续一系列事情。如果按照之前的策略,让所有请求都访问原创 2021-06-23 17:00:17 · 2242 阅读 · 1 评论 -
24 基于mmap内存映射实现磁盘文件的高性能读写
1.Broker读写磁盘文件的核心技术Broker对磁盘文件的写入主要是借助直接写入os cache来实现性能优化的,因为直接写入os cache,相当于就是写入内存一样的性能,后续等os内核中的线程异步把cache中的数据刷入磁盘文件即可。而这一个过程涉及到了mmap技术。2.传统文件IO操作的多次数据拷贝问题多次数据拷贝如果没有使用mmap技术,RocketMQ就需要使用普通文件IO操作去进行磁盘文件的读写,这一过程涉及到 多次数据拷贝的问题。读数据场景:有一个程序需要对磁盘原创 2021-06-27 15:21:03 · 1547 阅读 · 0 评论 -
01 场景:一个真实电商订单系统的整体架构、业务流程及负载情况
1.电商核心业务——下单流程1.1 下单流程图1.2 流程说明:用户浏览商品系统 添加商品到购物车 选择其中某些商品下订单——提交订单 拉起微信支付、支付宝支付——支付订单 支付成功后,通知第三方仓储、发货系统,准备发货——物流发货1.3 下单前涉及的业务选中购物车后,在确认订单页,确认订单中的商品、价格、运费等无误; 选择是否使用优惠券、促销活动、积分等; 确认快递方式(到付等)、收件地址、是否开发票、发票抬头等2.核心环节——订单创建、支付2.1 确认订单并跳转支原创 2021-06-14 11:13:18 · 6180 阅读 · 0 评论 -
34 生产案例:从RocketMQ底层原理分析为什么会发生重复发优惠券
1. 问题的定位:优惠券系统重复消费了一条消息在当前案例的项目背景中,订单系统与各个系统是解耦的,也就是说订单支付成功之后,会发送一条消息到MQ去,然后红包系统(消费者)会从里面获取消息派发红包,优惠券系统从里面获取消息派发优惠券,其他系统同理。可能发生的问题:在生产环境下,优惠券系统可能会对同一条消息重复的处理两次,导致它给一个用户重复的派发了两个优惠券,也可能是其他系统重复操作两次(派发积分等)。定位问题:优惠券重复派发两次的问题可以定位到,那就是优惠券系统对同一个订单支付成功的消息处.原创 2021-07-23 07:17:48 · 344 阅读 · 1 评论 -
28 RocketMQ:事务消息机制的底层实现原理
1.half 消息在commit前对消费者不可见的原因回顾:当订单系统去发送一个half消息给MQ的时候。对于这个half消息,红包系统在这时是看不到它的,也无法去消费这条消息并进行处理。ConsumeQueue的可见原理场景解析:当写入一条half消息到OrderPaySuccessTopic这个Topic里去,会定位到这个Topic的一个MessageQueue,然后定位到上图RocketMQ的一台机器上去,接着,消息就会写入到CommitLog中。与此同时,消息的offset会写入Me原创 2021-06-28 23:04:46 · 425 阅读 · 0 评论 -
20 基于DLedger技术的Broker主从同步原理
1.Broker高可用架构原理producer写入消息到broker之后,broker会将消息写入本地CommitLog磁盘文件里去,然后还有一些ConsumeQueue会存储Topic下各个MessageQueue的消息的物理位置。高可用架构中,必须有一个Broker组,里面有一个是Leader Broker可以写入数据,然后让Leader Broker可以写入数据,然后让Leader Broker接收到数据之后,直接把数据同步给其他的Follower Broker。这样的话,一条数据原创 2021-06-26 19:12:46 · 517 阅读 · 1 评论 -
18 生产者发送消息的原理
1.MessageQueueMessageQueue,该参数是在创建Topic的时候需要指定的一个很关键的参数。比如:在创建"TopicOrderPaySuccess" 这个Topic 的时候,该Topic对应了多少个队列,就对应了多少个MessageQueue.2.Topic、MessageQueue以及Broker之间的关系分布式存储每个Topic的数据都是分布式存储在多个Broker中的。数据分片一个Topic可以划分为多个MessageQueue分布在不同Brok原创 2021-06-24 10:22:27 · 261 阅读 · 0 评论 -
33 基于RocketMQ设计的全链路消息零丢失方案总结
1. 全链路消息零丢失方案总结发送消息到MQ的零丢失: 方案一: 同步发送消息 + 反复多次重试 方案二: 事务消息机制 两者都有保证消息发送零丢失的效果,经过分析,事务消息方案整体会好一些MQ收到消息之后的丢失: 开启同步刷盘策略 + 主从架构同步机制,只要让一个Broker收到消息之后同步写入磁盘,同时同步复制给其他Broker,然后再返回响应给生产者说写入成功,此时就可以保证MQ自己不会丢失。消费消息的零丢失: 采用RocketMQ的消费者可以保...原创 2021-07-22 23:17:43 · 214 阅读 · 1 评论 -
38 基于RocketMQ的数据过滤机制,提高订单数据库同步的处理效率
1. 数据库中混杂的binlog造成的问题一个数据库中可能包含很多的数据,比如订单数据库,里面除了订单信息表以外,还包含很多其他的表。这就导致在进行数据库 binlog 同步的时候,连带着会把一个数据库里所有表的 binlog 都推送到MQ里去了。这样的情况下,在MQ的某个Topic中,就会混杂了几个或十几个表的 binlog数据,而不仅仅是订单表的binlog。而在大数据系统中,它只关心订单数据库中的表A的 binlog ,并不关心其他表的 binlog,此时大数据系统就必须对获取到的所有原创 2021-07-26 21:04:11 · 197 阅读 · 1 评论 -
40 RocketMQ的生产实践总结
1.灵活的运用tags来过滤数据MQ中基于tags来过滤数据的功能,在真正的项目中,要合理的规划Topic和里面的tags,一个Topic代表了一类业务消息数据,然后对于这类业务消息数据,如果你希望能划分一些类别的话,可以在发送消息的时候设置 tags。案例:如外卖平台有美团外卖、饿了么外卖等外卖,如果系统要发送外卖订单数据到MQ里去,就可以针对性的设置 tags ,比如不同的外卖数据都到一个 “WaimaiOrderTopic” 里去。但是不同类型的外卖可以有不同的 tags : “meitu原创 2021-07-27 07:07:11 · 166 阅读 · 0 评论 -
07 场景演示:MQ有什么用处?
消息队列的作用:解耦、异步、削峰1.高度耦合场景在上图的场景中,每次新增系统接入都需要改代码,而每次移除服务都要删除代码,耦合度太高了。另外,A系统还要考虑其他下游系统会不会宕机后接收不到消息的问题。为此要考虑做一个重试机制?2.MQ解耦上图的场景中,维护这个代码:不需要考虑其他系统是否调用成功、失败超时。3.同步高延时场景这样一个请求全部完成,需要耗费的总时长是:820ms。用户通过浏览器发起这个请求,等待将近1秒钟,几乎不可能接受。一般的互联网企业,对用户的直原创 2021-06-14 17:47:16 · 158 阅读 · 0 评论 -
30 RocketMQ事务消息的代码实现细节
基于官方文档提供的事务消息API使用的例子来进行分析,这里会把订单系统的业务场景房子里面,加入一些伪代码进行参考。1. 发送half事务消息出去package com.mqTrsMessage;import org.apache.rocketmq.client.producer.DefaultMQProducer;import org.apache.rocketmq.client.producer.SendResult;import org.apache.rocketmq.client.p原创 2021-07-19 06:56:54 · 418 阅读 · 1 评论 -
37 生产案例:基于RocketMQ进行订单库数据同步的消息乱序问题及解决方案、代码实现
1. 消息乱序的场景前面说过了消息丢失、消息重复、消息处理失败三个问题,接下来是关于消息乱序的问题及解决方案。场景:消息乱序的发生场景大数据团队在获取订单数据库中的全部数据后,需要将订单数据保存一份在自己的大数据存储系统中,比如HDFS、Hive、HBase等。以上的过程在优惠后会基于Canal中间件去监听订单数据库的binlog,也就是通过一些增删改操作的日志,然后把这些binlog发送到MQ里去。然后大数据系统从MQ里获取binlog,落地到自己的大数据存储中去;再由大数据系统对存储原创 2021-07-25 19:47:30 · 1314 阅读 · 2 评论 -
03 系统面临的现实问题:订单退款流程失败以及订单支付超时问题
1.回顾支付后的业务流程支付成功后要做的业务如下图,包含扣减库存、通知发货、更新积分、发放优惠券、红包、push通知、更新订单状态等。2.退款流程有下单,也就有退款,这是订单支付的反向流程。分析:下单时,支付之后会发放优惠券、红包、积分,还会通知第三方发货等,那么现在退款了。 这些相关的福利也该退回才是,也就是说,退款之后要归还优惠券、积分、红包等。退款需要做的事:重新给商品增加库存 更新订单状态为“已完成” 减少你的积分 收回你的优惠券和红包 发送push告诉你原创 2021-06-14 13:06:08 · 1363 阅读 · 0 评论 -
22 消费者从Master或Slave拉取消息的策略
1.回顾Broker读写分离架构在该架构中,刚开始消费者是连接到Master Broker机器去拉取消息的,然后如果Master Broker机器觉得自己负载比较高,就会告诉消费者机器,下次可以从Slave Broker机器去拉取。2.CommitLog基于 OS Cache提升写性能的回顾Broker收到一条消息,会写入CommitLog文件,但是会先把CommitLog文件中的数据写入os cache(操作系统管理的缓存)中去。然后os自己有后台线程,过一段时间后会异步把os cac原创 2021-06-27 11:32:28 · 269 阅读 · 0 评论 -
31 Broker消息零丢失方案:同步刷盘 + Raft协议主从同步
1.使用事务消息机制,消息就一定不会丢失了吗通过使用事务消息机制,可以保证生产消息环节的消息不丢失,并且保证了两个业务系统的数据一致性。但是,这却不能保证数据一定不丢失。这里指的是MQ进程的数据丢失问题。场景分析假设订单系统通过事务消息的机制,通过half消息 + commit 的方式,把消息在MQ里提交了。也就是说,现在对于MQ来说,那条消息已经进入到它的存储层了,可以被红包系统看到了。订单系统生产的消息在commit之后,会从half topic里进入OrderPaySucces原创 2021-07-20 07:14:20 · 349 阅读 · 1 评论 -
39 生产案例:基于延迟消息机制优化大量订单的定时退款扫描问题、示例代码
一、基于延迟消息机制优化订单退款扫描问题1. 订单退款扫描的问题之前写过一个电商小程序,在它的购物流程中,作为用户在小程序上都会先选择一些商品加入购物车,然后对购物车里选择的一些商品统一下一个订单,此时后台的订单系统必然会在订单数据库创建一个订单。当用户下了一个订单之后,在订单数据库里会有一个订单,订单的状态却是“未支付” 状态,因为此时用户还没有支付该订单,而订单系统也在等待用户完成该订单的支付。这时就有两种可能了,一种可能是用户下单之后立马就支付掉了,那么接着订单系统可以走后续的流.原创 2021-07-26 22:22:24 · 210 阅读 · 0 评论 -
08 技术选型:Kafka、RabbitMQ以及RocketMQ
1.技术选型的考量条件业内常用的MQ有哪些? 每一种MQ各自的表现如何? 这些MQ在同等机器条件下,能抗多少QPS(每秒抗几千QPS还是几万QPS)? 性能有多高(发送一条消息给他要2ms还是20ms)? 可用性能不能得到保证(要是MQ部署的机器挂了怎么办)?2.深层次的考量他们会不会丢数据? 如果需要的话能否让他们进行线性的集群扩容(就是多加机台机器)? 消息中间件经常需要使用的一些功能他们都有吗(比如说延迟消息、事务消息、消息堆积、消息回溯、死信队列,等待)?3.Kafka、Ra原创 2021-06-14 18:40:54 · 8174 阅读 · 8 评论 -
12 RocketMQ高可用的生产部署架构
1.NameServer采用集群化部署,保证高可用让NameServer集群化部署,初步可以部署在三台机器上,可以充分保证NameServer作为路由中心的可用性,原创 2021-06-20 22:34:17 · 856 阅读 · 5 评论 -
10 MQ路由中心的架构原理
1.上节回顾在上小节的场景中,知道了RocketMQ是可以将消息进行分发,采取主从架构+集群部署可以达到高可用、高并发的目的。另外,就是每个MQ进程也就是Broker都将自己注册到了NameServer上,而生产者、消费者都是从NameServer去获取路由信息来决定写入、读取哪个Broker。2.新的问题生产者是以什么方式去NameServer拉取路由信息? 生产者怎么和broker建立连接和发送消息的? 消费者怎么拿到Broker里的消息的?通过什么方式连接?3. NameServ原创 2021-06-16 17:02:15 · 244 阅读 · 7 评论 -
21 消费者获取消息处理以及进行ACK的原理
1.消费组概念消费者组的意思,就是让你给一组消费者起一个名字。场景解释消费者组当前有个Topic为“TopicOrderPaySuccess”,此时有库存系统、营销系统等要去消费这个Topic中的数据。这里将库存系统命名为“stock_consumer_group”。设置消费者组的方式在代码里是这样的: DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("stock_consumer_group");假设该库原创 2021-06-27 10:21:14 · 323 阅读 · 0 评论 -
13 基于MQ实现订单系统的核心流程与第三方系统对接异步化改造
1.MQ生产集群原创 2021-06-21 22:33:31 · 2154 阅读 · 0 评论 -
部署: 搭建 Apache RocketMQ 单机环境与Rocketmq-console
环境需求:64位操作系统,建议使用Linux / Unix / CentOs7.3 64bit JDK 1.8+ Maven 3.2.x 一、安装Maven参考链接:二、安装RocketMQ1、关闭防火墙systemctl stop firewalld.service2、下载和构建wget http://mirrors.hust.edu.cn/apache/rocketmq/4.2.0/rocketmq-all-4.2.0-source-rel.原创 2021-07-12 06:39:50 · 488 阅读 · 1 评论 -
RocketMQ: Linux-单主部署、一主一从部署、双主双从部署、代码测试
一.RocketMQ单机部署 Hosts添加信息我们首先进入/etc/hosts来添加信息vim /etc/hosts添加信息如下:上传解压安装包通过XFTP工具将apache-rocketmq.tar.gz传到/usr/local/software,然后添加/usr/local/apache-rocketmq目录,再将apache-rocketmq.tar.gz解压到此目录下[root@rich apache-rocketmq]# mkdir /usr/local..原创 2021-07-14 09:24:19 · 1534 阅读 · 1 评论 -
43 RocketMQ对百万消息积压问题的处理方案
业务场景:在一个系统中,由生产者系统和消费者系统两个环节组成,生产者系统不停的把消息写入RocketMQ里去,然后消费者系统就负责从RocketMQ里消费消息。该系统在生产环境的高峰期内,大概有100多万条消息进入MQ。然后消费者系统从MQ里获取消息,并依赖Redis去进行一些业务逻辑的实现。某天在高峰期突然间出了问题,消费者系统依赖的Redis挂掉了,导致消费者系统也阻塞无法继续执行下去了。消费者系统的阻塞停止运行,意味着不会再从RocketMQ里去消费数据和处理了。而此时的生产者系统依旧原创 2021-07-27 21:05:08 · 3112 阅读 · 2 评论 -
36 消息处理失败场景下死信队列的解决方案
1. 消息处理失败的场景-优惠券系统的数据库宕机在基本确保MQ的消息不丢失,且同时不会对消息进行重复处理的情况下,在正常流程下,基本就没什么问题了。在MQ使用没问题之后,这里要考虑一个问题,那就是如果消费者所在的优惠券系统的数据库宕机了该怎么办?在前面的场景中,订单支付成功之后会推送消息到MQ,然后优惠券系统、红包系统会从MQ里获取消息去执行后续的处理,比如发红包或者发优惠券。如果优惠券系统的数据库宕机了,就会导致消费者端所在的系统从MQ里获取到消息之后没办法进行处理。在上述的场景.原创 2021-07-24 23:05:18 · 2948 阅读 · 0 评论 -
23 RocketMQ是如何基于Netty扩展出高性能网络通信架构的
1.Reactor主线程与长短连接在Broker里有一个名叫 “Reactor” 的线程,这个线程是负责监听一个网络端口的,比如监听个2888,39150这样的端口。短连接短连接,如果你要给别人发送一个请求,必须要建立连接 -> 发送请求 -> 接收响应 -> 断开连接,下一次你要发送请求的时候,这个过程得重新来一遍。每次建立一个连接之后,使用这个连接发送请求的时间是很短的,很快就会断开这个连接,所以他存在时间太短了,就是短连接。长连接长连接,建立一个练级 -&原创 2021-06-27 13:35:16 · 344 阅读 · 0 评论 -
11 RocketMQ主从原理、读写分离与故障转移
前面已经了解过的内容如下:集群中的每个Master Broker只存储一部分消息,通过主从保证高可用; 所有Brokerdou原创 2021-06-20 20:17:05 · 2536 阅读 · 1 评论