mjunz的博客

真实的情况是，如果这个-XX:MaxGCPauseMillis = 20参数设置过⼩，G1垃圾回收器会因为这个⽐较⼩的停顿时间，⽽给新⽣代⼀个⾮常⼩的空间，这就导致频繁的触发YGC。例如是4核那么线程数就是3，如果⾃定义⼀个公⽤线程池，所有消费者都使⽤这个线程池，假如开启了80个线程，但是真正处理消费后的核⼼⽅法逻辑的，其实只有3个线程。根据上面列举的可能原因，除了Broker本身外，还有⼀些其他的可能原因，就是batchSize过⼤，或者是Chanel接⼝太忙。超时时间调得⼤⼀点，会不会就解决了？

所以此时需要临时修改那4个消费者的代码，让它们获取到消息后不依赖NoSQL，直接把消息写入一个新的Topic，这时候的速度是很快的，因为仅仅是读写RocketMQ而已。然后新的Topic会有20个MessageQueue，于是部署20台临时增加的消费者去消费新的Topic，消费新的Topic时才依赖NoSQL。那么此时可能就会有一个问题：如果订单团队使用的Topic，被商品团队不小心写入了错误的脏数据，那就可能会导致订单团队的Topic里的数据出错。当处理完百万积压的消息后，就可以下线多余的16台机器了。

正是这个消息乱序的原因，导致大数据存储中的数据有误。所以，如果优惠券系统从RocketMQ那里拿到一个订单的两条重复的支付成功消息，这时候只要去优惠券数据库中查询一下，比如查询id=1100的订单是否已经发放过优惠券、是否有优惠券的记录，如果有的话，就不要重复发券了。在订单数据库的同步过程中，产生消息乱序问题的根本原因是：属于同一个订单的binlog进入了不同的MessageQueue，从而导致一个订单的binlog被不同机器上的Consumer获取来处理，最终导致这一个订单的binlog被乱序执行。

但是从订单系统和红包系统当天那个时间段的日志来看，居然只看到订单系统推送消息到RocketMQ的日志，却没看到红包系统从RocketMQ中消费消息以及发现金红包的日志。所以订单系统在收到订单支付成功的通知后做的第一件事，不是先让订单系统做一些增删改操作，而是先发一个half消息给RocketMQ以及等待它的成功响应，也就是初步和RocketMQ建立联系和沟通，从而让订单系统确认RocketMQ还活着，RocketMQ也会知道订单系统后续可能想发送一条很关键的不希望丢失的消息给它。

然后订单系统接着会发送一个订单支付的消息到RocketMQ中，积分系统会从RocketMQ里获取消息然后去累加积分，营销系统会从RocketMQ里获取消息然后发送优惠券，推送系统会从RocketMQ里获取消息然后推送短信，仓储系统会从RocketMQ里获取消息然后生产物流单核和发货单、通知仓库管理员打包商品、准备交接给物流公司发货。无论是大数据团队，还是未来公司的其他技术团队，比如说开放平台团队，人工智能团队等，只要想要订单数据，都可以直接从这个RocketMQ里去获取完整的订单数据。

也就是说，哪怕生产环境中极端情况下，RocketMQ的TPS飙升到8万TPS，知道机器资源也是大致可以抗下来的，不至于出现机器宕机的情况。从消息中间件到底是什么开始，然后考虑如何对MQ进行技术选型，接着了解RocketMQ的核心技术原理，然后是RocketMQ的生产部署方案如何制定，接着开始上手部署一个小规模的RocketMQ集群，同时做好集群的可视化监控，并且对小规模的RocketMQ集群进行生产级的参数调整，然后对RocketMQ集群进行压测，最后根据压测结果规划一个生产集群进行部署。

订单系统在创建订单时已经调用库存系统锁定了用户要买的商品的库存，结果用户跳转到支付界面后却放弃了支付，如果订单一直不付款，那么它对应的商品库存就会一直锁定，影响其他用户的购买。比如更新订单的状态是在自己公司的订单系统内部完成的，扣减库存是在自己公司内部的库存系统完成的，增加积分是在自己公司内部的积分系统完成的，派发优惠券红包是在自己公司内部的营销系统完成的。一般来说，跟第三方系统的交互往往是最麻烦的。比如在这个订单支付流程里，订单系统其实是要调用很多其他系统的，有库存系统、积分系统、营销系统、仓储系统等。

那些节点收到这个Leader的心跳后，就会重置自己的倒计时，比如原来的倒计时还剩10ms，收到Leader心跳时就重置为200ms。Follower节点通过Leader的心跳去不断重置自己的倒计时，不让倒计时到达，以此来维持Leader的地位，否则倒计时一到达，它就会从Follower转变为Candidate发起新一轮的Leader选举。此外，Push模式下有一个请求挂起和长轮询的机制：当拉取消息的请求发送到Broker，结果发现没有新的消息给处理时，就会让请求线程挂起，默认是挂起15秒。

所以当ConsumerGroup的一个Consumer需要读取ConsumeQueue里的某逻辑偏移量offset位置的消息时，就会根据该消息的逻辑偏移量offset，去定位到ConsumeQueue磁盘文件中的位置((offset - 1) * 20字节)作为起始位置，然后再连续读取20字节即可，这样就可以快速地将消息读取出来。其中的亮点是基于OS的PageCache来写入数据，Broker的JVM进程崩溃(高概率)是不会导致PageCache的数据丢失的。这种情况发生的概率还是比较高的。

Producer发送请求到NameServer的拉取Topic路由数据的过程：首先封装一个Request请求对象，然后通过Netty客户端发送请求到NameServer，接着会接收到NameServer返回的一个Response响应对象，于是就可以从Response响应对象里取出所需的Topic路由数据并更新到自己本地缓存里。此外，Push模式下有一个请求挂起和长轮询的机制：当拉取消息的请求发送到Broker，Broker却发现没有新的消息可以处理时，就会让处理请求的线程挂起，默认是挂起15秒。

由于NameServer需要接收Broker发送过来的要把自己注册到NameServer上的请求(因为知道有哪些Broker和管理Broker)，以及需要接收客户端发送过来的从NameServer拉取元数据的请求(因为客户端需要知道一个Topic的MessageQueue都在哪些Broker上)，所以才需要在NameServer中创建NamesrvController这个类专门用来接收Broker和客户端的网络请求。毕竟Broker要处理各种请求，不同的请求需要用不同的线程池里的线程进行处理。

大纲1.RocketMQ整体运行原理的介绍顺序2.RocketMQ生产者是如何发送消息的3.Broker是如何持久化接收到的消息到磁盘上4.基于DLedger技术的Broker主从同步原理5.消费者进行消息拉取和消费的过程6.消费者从Master或Slave上拉取消息的策略7.RocketMQ如何基于Netty进行高性能网络通信8.基于mmap内存映射实现磁盘文件的高性能读写9.RocketMQ的整体运行原理总结1.RocketMQ整体运行原理的介绍顺序一.生产者往Broker集群发送消息的底层原理二.Br