消息中间件优化高手笔记

语雀完整版：

https://www.yuque.com/g/mingrun/embiys/on4n2m/collaborator/join?token=TRa20JcUyRGC1b04&source=doc_collaborator# 《消息中间件优化高手笔记》

入门&&集群搭建

1. mq的作用 儒袁给的答案是 异步、削峰、解耦，黑马给的答案是解耦、削峰、数据分发
   解耦主要是可以防止某一个步骤 走不通而危害全局
   数据分发是 可以让多个系统来消费数据，而生产者则无需关心谁消费了

1. 单机版主要安装步骤 和问题：
   解压安装包，然后命令启动nameserver和broker，其中broker需要更改启动脚本，修改默认占用内存大小

rocket mq集群搭建

1. 各个角色

   

1. 集群特点：nameserver 是一个无状态节点，master与slave是一对多的关系，broker中包含 master和slave，它要定时向nameserver 注册topic信息

1. 集群模式：
   单master模式
   多master模式
   多master 多slave模式（异步）：主备间有短暂延迟，性能高
   多master 多slave模式（同步）：没有延迟，比异步模式性能低10%

   

1. 集群的工作流程：

• • 启动nameserver 作为路由中心，等待broker puducer consumer连接上来

• • Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。

• • 收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。

• • Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。

• • Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息。

1. 搭建集群大致流程
   配置host、防火墙、环境变量、消息存储日志，然后在第一台机器上配置broker-a 下的 mater-1和salve-2(改配置文件) 然后第二台机器反过来

从零开始成为消息中间件高手

阶段一：订单系统中所面临的痛点

000、开篇词工程师们学习技术的痛点:纯理论、不知道如何实战!

多思考 多学习

001、一个真实电商订单系统的整体架构、业务流程及负载情况

1. 订单系统的大致业务流程

   

1. 订单系统的主要功能模块

   

002、授人以渔:能概括一下你们系统的架构设计、 业务流程以及负载情况吗

1. 技术的学习要在真实的环境中，发现其中的痛点，并且用技术去解决它

1. 多思考 想象自己的系统用户量级增长几百上千倍

003、系统面临的现实问题:下订单的同时还要发券、发红包、Push推送， 性能太差!

1. 发现系统某一个业务中的性能问题

1. 系统负载推算：
   根据用户使用习惯 推算出高峰以及总的负载量，根据机器配置 判断是否能够承载

004、授人以渔:你们系统的核心流程性能如何?有没有哪个环节拖慢了速度?

1. 思考系统的负载，在一定流量下考虑如下文图

系统的核心业务流程性能如何？
核心流程的每个步骤要耗费多长时间？
现在核心流程的性能你满意吗？是否还有优化的空间？
在系统高峰期的时候，机器和数据库负载很高，是否对核心流程的性能有影响？
如果有影响的话，会有多大的影响？

005、系统面临的现实问题:订单退款时经常流程失败，无法完成退款!

1. 退款问题：退款的流程也很复杂，耗时也很长，如果第三方支付系统退款失败了也很难受

1. 用户一直未支付问题

006、授人以渔:你们系统出现过核心流程链路失败的情况吗?

1. 系统的使用mq的一些流程

007、系统面临的现实问题:第三方客户系统的对接耦合性太高，经常出问题!

与第三方系统的耦合 带来了不确定性，不稳定性，而且性能会比较差

008、授人以渔:你们有没有跟第三方系统对接过，有遇到什么问题吗?

有啊 坑爹的微信

009、系统面临的现实问题:大数据团队需要订单数据，该怎么办?

1. 大数据 统计一些有价值的数据，从海量的用户数据当中，其中如果直接使用sql进行查询 会影响系统的性能，cpu 磁盘负载会很高，curd性能很差，尤其是几百行的大SQL

010、授人以渔:你们有没有遇到过自己系统的数据，其他团队需要获取的?

1. 有，要警惕乱搞把别人的数据库搞炸了

011、系统面临的现实问题:秒杀活动时数据库压力太大，该怎么缓解

要早回家防止被绿

012、授人以渔:你们系统会不会遇到流量洪峰的场景，导致瞬时压力过大?

我的系统压力有多高 全靠你想象

013、阶段性复习:一张思维导图给你梳理高并发订单系统面临的技术痛点!

very good

014、阶段性复习：放大100倍压力，也要找出你系统的技术挑战！

找一个流程，看他有没有定时补偿机制（对异常数据的修复），性能如何 各个链路的流量暴增会怎样，有一些步骤失败了会怎样 ，是否集成了第三方的服务，是否稳定？

阶段二：RocketMQ原理 与集群搭建与压测

015、解决订单系统诸多问题的核心技术:消息中间件到底是什么?

异步、削峰、解耦

016、授人以渔:结合自己的系统问题思考一下，MQ有什么用处?

在自己项目里面 这些功能哪些地方能用到

017、领导的要求:你来对Kafka、 RabbitMQ 以及RocketMQ进行技术选型调研

1. activeMq： 已经没人用了

1. kafka：性能高，吞吐量高（qps：十几万）,缺点是会丢失数据，功能较少，一般用在日志采集，用户数据采集

1. rabbit：可保证数据不丢失，吞吐量较低（几万），语言是erlong

1. rocket：就决定是你了

018、授人以渔:你们公司主要使用的MQ是哪种?为什么要选用它?

🐇 🚀

019、新技术引入:给团队分享RocketMQ的架构原理和使用方式

RocketMQ整体架构图：首先就是请求分散到多态机器上，压力分摊掉，然后就是分布式存储，海量的数据 存储在多个broker上，然后就是为了保证高可用，从节点备份有主节点的数据，然后就是数据路由，它由NameServer管理

020、授人以渔:结合你对其他MQ的了解，思考RocketMQ的设计有何特点?

他们都是如何集群化部署抗高并发的？
他们对海量消息是如何分布式存储的？
他们是如何实现主从多备份的高可用架构的？
他们是如何实现集群路由让别人找到对应的机器发送消息和接收消息的

021、设计生产架构之前的功课:消息中间件路由中心的架构原理是什么?

1. NameServer可以集群部署，每个broker启动的时候 要向每一个NameServer注册

1. 然后每个系统 自己去从NameServer拉取 broker信息

1. broker 挂了 NameServer怎么感知到：
   broker向server发送定时心跳，120秒不动了就是挂了

1. broker 挂了 系统怎么刚知道：
   主备切换，后续再看

022、授人以渔:要是没有这个路由中心，消息中间件可以正常运作么?

不能

023、设计生产架构之前的功课: Broker的主从架构原理 是什么?

1. master 和slave采用的是pull模式，也就是slave主动从master那里拉取消息

1. 写入数据会写入master，消费者消费消息从 Master Broker 或者 Slave Broker，根据负载 和消息同步程度来定

1. slave挂掉没啥事儿，但是mater挂掉之后 4.5之前不能自动主备切换，之后有Dledger 可以实现，部署一主多从，自动选举主节点

024、授人以渔: Broker主从同步有没有数据不一致问题?

有的

025、落地第一步: 设计-套高可用的消息中间件生产部署架构

1. 第一步：NameServer 集群化部署，部署到三台机器上，它的特点是 每个nameserver都有完整的信息

1. 第二步：使用Dledger ，一主双从

Topic

1. 概念：topic 是MQ中的一个核心的数据模型，代表一类数据集合

1. 存储方式：分布式存储，每个topic下的数据可能放到多个 broker上，然后broker心跳的时候 需要把有哪些topic和它对应的数据 发给NameServer

其它点

1. 生产者投递消息：生产者是先会向 NameServer拉取路由信息，然后投递消息，而且投递的是master节点

1. 消费者拉取消息：和消费者一样 可能从master或者slave

1. 整体架构：高可用、高并发、海量消息、可伸缩
   高可用 就是比如nameserver 在多台机器，随便挂掉一个也没事儿，还有Dledger 下的一主双从（主从切换），高并发 就是多台机器去抗，海量消息就是topic的分布式存储，可伸缩就是可以部署多个broker

026、授人以渔:你们公司的消息中间件生产环境如何部署的?

随便搞的单机

027、部署一个小规模的RocketMQ集群，为压测做好准备?

1. 机器配置

NameServer：3台机器，每台机器都是8核CPU + 16G内存 + 500G磁盘 + 千兆网卡
Broker：3台机器，每台机器都是24核CPU（两颗x86_64 cpu，每颗cpu是12核） + 48G内存 + 1TB磁盘 + 千兆网卡
生产者：2台机器，每台机器都是4核CPU + 8G内存 + 500GB磁盘 + 千兆网卡
消费者：2台机器，每台机器都是4核CPU + 8G内存 + 500GB磁盘 + 千兆网卡

1. 编写简单的测试代码：创建几个线程，循环在消费者和生产者里面发送和获取

028、授人以渔:动手完成一个小规模的RocketMQ集群的部署进行练习?

扛不住机器

029、生产运维:如何对RocketMQ集群进行可视化的监控和管理?

1. 也是使用rocketmq console，然后在页面中进行观察，而机器本身的负载则需要借助其它工具

030、授人以渔:你们公司的MQ集群是如何进行监控和管理的?

公司没有 我有

031、 RocketMQ生产集群准备:进行OS内核参数和JVM参数的调整

1. 对这种中间件的压测 必须要考虑到参数调整，比如线程数和内存，以此来发挥最大性能

1. 涉及到的参数：网络I/O相关的，线程相关的，内存使用相关的

1. jvm参数调整 ：值得一看

1. rocketmq核心参数：sendMessageThreadPoolNums

032、授人以渔:你们公司的MQ集群是如何配置生产参数的?

可以！ 要给大佬递冰可乐

033、小规模RocketMQ集群进行压测， 同时为生产集群进行规划

1. 极限负载值很好测，直接多个线程 去跑，得出最高的tps，但最好是得出最高负载值，在tps和负载之前取得一个平衡值

1. 总结一波

   

034、授人以渔:你们公司的MQ集群做过压测吗?生产集群是如何规划的?

没有

035、阶段性复习:一张思维导图给你梳理消息中间件集群生产部署架构规划

036、阶段性复习:按照你们公司的真实负载，设计消息中间件集群生产架构

可以有

阶段三：系统改造

037、基于MQ实现订单系统的核心流程异步化改造，性能优化完成!

1. 存在的问题汇总：
   订单退款失败问题、跟第三方物流系统耦合导致的性能抖动问题、
   大数据团队直接查询订单库的问题、秒杀活动时订单库压力过大的问题、
   关闭订单时扫描大量订单数据的问题

1. 进行订单系统改造(异步改造)，这里要搞定黑马的订单系统，并且尽量在自己项目里模拟出一个类似的场景

   

038、授人以渔:如果在你们系统的核心流程引入MQ,应该如何改造系统?

正需要考虑这个

039、基于MQ实现订单系统的第三方系统异步对接改造，解耦架构完成!

消息发送模式

1. 同步发送：单个线程发送过去SendResult sendResult = producer.send(msg)

1. 异步发送：发送的时候代码继续往下走，MQ会走SendCallBack进行回调

producer.send (message, new Sendcallback() {@overridepublic void onSuccess (SendResult sendResult) {}@overridepublic void onException(Throwable e) {}
});

1. 单向发送：不管返回结果，生死由天 producer.sendoneway(msg);

消费模式

1. Push消费模式：由broker主动推送消息给消费者 （DefaultMQPushConsumer）

1. Pull消费模式：消费者主动来拉取（DefaultMQPullConsumer）

040、授人以渔:如果你们系统要对接第三方系统，应该如何设计?

没人管

041、基于MQ实现订单数据同步给大数据团队，应该如何设计?

1. 使用cannal中间件去监听 BingLog ，然后发送到rocketMQ中

042、授人以渔:对其他团队要获取你们核心数据的问题，应该如何解决?

从哪获取，怎么获取，用什么技术，给我的系统造成了哪些压力

043、秒杀系统的技术难点以及秒杀商品详情页系统的架构设计

1. 商品团队的秒杀架构优化：页面数据静态化（学成在线的 cms功能）

1. 商品团队的秒杀架构优化：多级缓存 ，CDN + Nginx + Redis，nginx基于lua脚本实现本地缓存？

044、授人以渔:你们有没有类似秒杀的业务场景?如果没有，自己想一个出来!

当然没有， 全靠想象💭

045、基于MQ实现秒杀订单系统的异步化架构以及精准扣减库存的技术方案

1. 使用答题防作弊：要用答题的（比如验证码） 来防止用户刷接口

1. 将抽奖业务独立出来：这就是微服的好处

1. 抢购完成后过滤掉无效请求：ZooKeeper中写入一个秒杀完毕的标志位，然后ZK会反向通知Nginx中我们自己写的Lua脚本，通过Lua脚本后续在请求过来的时候直接过滤掉

1. 使用RocketMQ进行削峰

总结：

• 在前端/客户端设置秒杀答题，错开大量人下单的时间，阻止作弊器刷单

• 独立出来一套秒杀系统，专门负责处理秒杀请求

• 优先基于Redis进行高并发的库存扣减，一旦库存扣完则秒杀结束 (重点就是这里，不要走数据库，用redis完成，如红包雨)

• 秒杀结束之后，Nginx层过滤掉无效的请求，大幅度削减转发到后端的流量

• 瞬时生成的大量下单请求直接进入RocketMQ进行削峰，订单系统慢慢拉取消息完成下单操作

046、授人以渔:如果你们有类似秒杀的瞬时高并发场景，应该如何改造?

怎么处理，怎么做

047、阶段性复习: - 张思维导图给你梳理全面引入MQ的订单系统架构

048、阶段性复习:思考一下，如果你们系统全面接入MQ架构该如何设计?

结合项目多考虑一下

阶段四

49、精益求精:深入研究下生产者到底如何发送消息的?

1. 问题总结：

看看Broker对于接收到的消息，到底是如何存储到磁盘上去的？
基于DLedger技术部署的Broker高可用集群，到底如何进行数据同步的？
消费者到底是基于什么策略选择Master或Slave拉取数据的？
消费者是如何从Broker拉取消息回来，进行处理以及ACK的？如果消费者故障了会如何处理？

1. Topic、MessageQueue以及Broker 之间的关系：一个topic可能分布在多个Broker上，而一个topic下会有多个队列，这些队列来存储所有的数据，来实现数据分片

1. 生产者发送消息的时候写入哪个MessageQueue： 均匀写入

1. broker发生了故障该怎么办？
   Producer  中开启一个开关，sendLatencyFaultEnable, 他会发现故障之后先回避一段时间，然后再去访问

   

50、授人以渔: Kafka、 RabbitMQ有 类似MessageQueue的数据分片机制吗

有的

51、精益求精:深入研究一下Broker是如何持久化存储消息的?

1. mq最重要的一个环节：Broker数据存储  ，决定了吞吐量，消息不能丢失

1. 消息顺序写入机制：
   将消息写入一个叫CommitLog  的日志文件，每个文件1gb 满了再新建

1. MessageQueue 是如何存储的：
   它对应了一系列的consumequeue文件在 $HOME/store/consumequeue/{topic}/{queueId}/{fileName}下面，文件中存储的是每条消息在 CommitLog中对应的偏移量

1. CommitLog写的性能为何如此高：
   顺序写：直接在commitLog文件中追加，比随机写快上好多倍
   PageCache :先写入缓存，然后再由I/O线程将数据 刷入磁盘

1. 同步刷盘和异步刷盘：
   同步就是 强制从pagecache中刷入磁盘，如果挂掉了 生产者有感知，可重发，而异步则无感知，会丢失数据，当时性能会提高很多。

52、授人以渔:同步刷盘和异步刷盘分别适用于什么场景呢?

就看可不可以 丢失数据了，然后看看兔子和kafka怎么做的默认

53、精益求精:基于DLedger技术的Broker主从同步原理到底是什么?

1. 用DLedger 的CommitLog替换 Broker的CommitLog （dledger 也可以干这件事儿）

1. DLedger基于Raft协议选举Leader Broker：
   第一轮都会投给自己，然后都随机进入休眠，谁先醒过来把票给别人 然后都投给他，最后达成
   3台机器 / 2+ 1个人  也就是大多数，就可以了

1. DLedger基于Raft协议 进行多副本同步：
   数据同步分为两阶段，uncommitted和commited
   Leader 上的 DLedger收到uncommitted后会把uncommitted 发给Follower Broker的DLedgerServer ，Leader Broker收到超过半数的Follower Broker返回ack之后，就会将消息标记为committed状态 ,然后发送就会发送commited消息给Follower Broker机器的DLedgerServer，让他们也把消息标记为comitted状态。

54、授人以渔:采用Raft协议进行主从数据同步，会影响TPS吗?

超过半数的Follower Broker都写入uncommitted消息之后，才会返回给生产者成功的ack，效率肯定下降

55、精益求精:深入研究一下消费者是如何获取消息处理以及进行ACK的?

1. 消费者组：比如对于订单这个一 topic，有库存系统 和营销系统，这是就可以有两个消费者组 stock_consumer_group，marketing_consumer_group，这两个组都会拉取消息，而组内部的集群则只会有一个拉取

   

1. 集群模式消费和广播模式消费：
   集群模式就是组内只会有一个 消费 ，广播则是所有

1. MessageQueue与消费者的关系 :
   一个topic下的多个MessageQueue均匀分摊给组内多个机器去消费，而机器消费与MessageQueue 是一对多的关系

1. Push和Pull的消费模式：
   Push的本质还是 Pull，前者的时效性更好，实现思路是：当消费者发送请求到Broker去拉取消息的时候，如果有新的消息可以消费那么就会立马返回一批消息到消费机器去处理，处理完之后会接着立刻发送请求到Broker机器去拉取下一批消息。

1. Broker如何将消息取出来 返回给消费者：
   从 MessageQueue0找到对应的ConsumeQueue0 ，找到第一条消息的offset，然后去CommitLog 中找到这个offset对应的数据

56、授人以渔:消费者到底什么时候可以认为是处理完消息了?

拉取不到

57、精益求精:消费者到底是根据什么策略从Master或Slave上拉取消息的?

1. 消费者对 ConsumeQueue  的读取：
   ConsumeQueue  写入数据也是会走 OSCache，而且因为占用空间小 会被存储于内存中，所以消费者读取的时候性能非常高

1. CommitLog的读取：
   是基于os cache+磁盘一起读取的 ，CommitLog占用空间大 不会全在内存，所以只能从 osCache中读取一部分

1. Master Broker什么时候会让你从Slave Broker拉取数据：
   当还没拉取的消息 已经大于了内存（OSCache），会需要的频繁从磁盘中读取的时候，就会让你去从slave中拉取。

58、授人以渔:消费者是跟所有Broker建立连接，还是跟部分Broker建立连接?

部分的吧 我也不知道 这咋推断出来

59、探秘黑科技: RocketMQ是如何基于Netty扩展出高性能网络通信架构的?

1. Reactor主线程（监听）与长短连接

1. 直接总结：

Reactor主线程在端口上监听Producer建立连接的请求，建立长连接
Reactor线程池并发的监听多个连接的请求是否到达
Worker请求并发的对多个请求进行预处理
业务线程池并发的对多个请求进行磁盘读写业务操作

60、授人以渔: BIO、 NIO、AIO以及Netty之间的关系是什么?

必须要复习一下

61、探秘黑科技:基于mmap内存映射实现磁盘文件的高性能读写

多看多研究这个

62、授人以渔:思考一个小问题, Java 工程师真的只会Java就可以了吗?

不行啊

63、抛砖引玉:通过本专栏的大白话讲解之后，再去深入阅读些书籍和源码

ok

64、授人以渔:一个学习方法的探讨，如何深入研究一个技术?

65、阶段性复习:一张思维导图带你梳理RocketMQ的底层实现原理

不要忘了截图

66、阶段性复习:在深度了解RocketMQ底层原理的基础之上，多一些主动思考

要看下

阶段五

67、生产案例:从RocketMQ全链路分析一下为什么用户支付后没收到红包?

1. 消息丢失的几种情况：
   到了MQ，但是先进了 OSCache，宕机了，就完犊子了
   进入磁盘，磁盘花了
   到了消费者，消费者还没开始处理 宕机了，已经消费的 offset还自动已经提交到了broker，

68、发送消息零丢失方案: RocketMQ事务消息的实现流程分析

1. 发送half消息到MQ去，试探一下MQ是否还活着，如果挂了 系统可以做一系列的回滚操作

1. 订单系统出了问题：告诉mq要回滚，删除之前的half消息

1. 订单系统完成了本地事务之后：提交commit，然后红包系统就能看见它发的消息了

1. 一直没收到half的响应：mq那边挂了，而且他还把这个 half消息保留了下来，然后mq会有一个补偿机制，时间过长后 会调用你的接口，问你是要提交还是 callback

   

69、RocketMQ黑科技解密:事务消息机制的底层实现原理

1. 为什么half消息在commit之前 消费者无法获取到？
   因为他放到了RMQ_SYS_TRANS_HALF_TOPIC 和它对应的ConsumeQueue  里面，没有走指定的topic

1. 如果因为各种原因 一直没有执行 commit和callback，会一直请求你的回调接口，最多15次，还不成功就默认走callback

1. callback如何执行的：
   写一条rollback OP记录到OP_TOPIC这个Topic里，标记某个half消息是rollback了

1. commit如何执行的：
   OP_TOPIC里写入一条记录，标记half消息已经是commit状态了，然后把RMQ_SYS_TRANS_HALF_TOPIC中的half消息给写入到指定的topic的ConsumeQueue里去

70、为什么解决发送消息零丢失方案，一定要使用事务消息方案?

如果不用rocket的事务消息，可以采用同步发送消息，如果有异常就不断重复的方案，还可以放到同一个事物中和数据库操作，但是都有缺点

71、用支付后发红包的案例场景,分析RocketMQ事物消息的代码实现细节

具体代码都在这！

072、Broker消息零丢失方案:同步刷盘+ Raft协议主从同步

1. 在mq中消息的丢失：还在OSCache中的时候宕机，进了磁盘后 磁盘故障

1. OSCache中丢失数据的解决方案：
   调整为异步刷盘，mq告诉我们成功的时候 消息就已经进入到磁盘中了

1. 主从架构避免磁盘中的消息丢失：
   就是让多台机器保有数据

73、Consumer消息零丢失方案:手动提交offset +自动故障转移

1. 什么时候丢失：
   消费者拿到消息后直接提交了这条消息的offset到broker去说自己已经处理过了，然后挂了

1. 解决：
   有代码去实现 消费者代码执行完了 才回复执行成功了

74、基于RocketMQ设计的全链路消息零丢失方案总结

1. 性能上的下降：
   使用事务消息 因为请求次数增多 性能下降
   采用 同步刷盘 ，写OsCache只需要0.1ms，同步则需要10ms
   集群 之间通信也会很耗时

75、生产案例:从RocketMQ底层原理分析为什么会重复发优惠券?

1. 生产者造成的：采用错误重试代码 可能会造成这个原因

1. 消费者造成的：在返回给mq消费成功的时候 挂了或者重启，mq以为消费者没成功，重发了

76、对订单系统核心流程引入幂等性机制，保证数据不会重复

1. 业务判断法：对一些字段进行判断

1. 基于redis的缓存幂等性机制：生产者把消息写入redis中进行标识（但要注意写入redis的时候挂掉系统）

77、如果优惠券系统的数据库宕机，如何用死信队列解决这种异常场景?

1. 如果对消息的处理有异常，可以返回RECONSUME_LATER状态 （比如作为消费者的优惠劵系统 数据库挂了 ）

1. mq对重试消息是怎么做的：
   对你这个ConsumerGroup ，有一个专门的叫做%RETRY%VoucherConsumerGroup的重试队列来存放，然后再每隔一定的时间来重试，最多重试16次，16次还不成功 就进入名称为 %DLQ%VoucherConsumerGroup的死信队列

78、生产案例:为什么基于RocketMQ进行订单库数据同步时会消息乱序?

1. 业务背景：例如在做binlog 同步的时候 ，mq中的消息出现了乱序，执行的sql语句也就出现了乱序

1. 为什么出现乱序：
   发送的消息 到了同一个topic上的不同的messageQueue上
   消费消息时 发送到了同一个组上的 不同机器

79、在RocketMQ中，如何解决订单数据库同步的消息乱序问题?

解决方案：比如可对订单的id 进行取模，让他都进到一个 MessageQueue上，然后再让一个消费者去消费

80、基于订单数据库同步场景,来分析RocketMQ的顺序消息机制的代码实现

代码

81、如何基于RocketMQ的数据过滤机制，提升订单数据库同步的处理效率

1. 可以给消息设置属性和tag，消费的时候可以根据他们进行过滤，还可以根据sql语句进行过滤

82、生产案例:基于延迟消息机制优化大量订单的定时退款扫描问题!

1. 业务背景： 商品下单的 30分钟内请付款

1. 实现方案一：定时扫描 超过30分钟的 给关闭掉。  数据量比较多 或者有多个数据库 什么时候扫，扫那些 就不太好搞了

1. 实现方案二：使用延迟消息，发送一个延迟消息，让消费者30分钟后可以搜到，然后判断这个订单是不是已经付款了

83、基于订单定时退款场景，来分析RocketMQ的延迟消息的代码实现

延迟队列代码

84、在RocketMQ的生产实践中积累的各种一手经验总结

1. 怎么去找 在mq中的消息

1. 消息零丢失方案的补充： 尤其是对于金融项目，如果mq崩溃了 最好把消息存入数据库，做好备份 容灾

85、企业级的RocketMQ集群如何进行权限机制的控制？

1. 权限控制：让指定的 团队 只能写入指定的topic 然后就是各种配置

86、如何对线上生产环境的RocketMQ集群进行消息轨迹的追踪

1. 怎么搞 开启broker的一个配置 traceTopicEnable=true ，然后用代码去消费

87、由于消费系统故障导致的RocketMQ百万消息积压问题，应该如何处理

1. 如果可以丢失掉，那就改消费者代码 让其快速消费 直接丢掉

1. 如果不可以丢掉，那就增加机器，增加消费者的数量，快速消化掉这些数据（比如 有4个topic，4台机器 ，20个messageQueue ，现在就扩充16台，但是面对 4个topic 4个messageQueue这种情况就没法了）

88、金融级的系统如何针对RocketMQ集群崩溃设计高可用方案?

对于这种金钱类的系统，如果是mq挂了的情况，可以使用代码进行降级，使用try-catch 重试几次，不行就说明mq挂了，然后就把消息 持久化起来，等mq恢复过来 就重发消息

89、为什么要给RocketMQ增加消息限流功能保证其高可用性?

要加限流算法 防止这种情况

90、设计一套Kafka到RocketMQ的双写 +双读技术方案，实现无缝迁移!

迁移步骤：先是双写到两个mq中，然后双读 只不过rocket的消费者代码 不落库，这个过程中 统计每日两个mq消息的数量，和处理后的结果，都一致的话 就判定可以迁移，然后再停掉 Producer系统，全写到RocketMq

阶段六 ：源码阶段

待更新