RocketMQ消息中间件(二)：MQ的理论支撑1亿QPS高并发和高可用机制？认识什么是同步机制？异步机制？MQ的好处？MQ的流量削峰？MQ高可用机制： broker主从架构以及多副本策略_rocketmq qps

前言：

上一讲，以图文的方式，我们以一个订单系统举例，讲了很多可能或者是会遇到的问题，这讲我们主要先对MQ有个认识，通俗易懂的了解MQ的作用，为什么使用MQ，使用之后会发生什么？这里给出上一章的一个链接【https://blog.csdn.net/weixin_46950473/article/details/114849418】

1：什么是同步机制呢？

同步机制比较简单，打个简单的比方生活中的例子，一秒即可就懂了机制了，例如：我现在煮好了饭才能吃饭，不然就只能喝西北风，也就是我必须要完成这件事情，才能做下一件事情；

如图：【同步机制】

2：认识异步机制，引入MQ

异步机制其实并不陌生，像ajax的异步回调function等等这些都属于异步机制，通俗易懂的来讲就比较适合举例了，例如：拿上面的举例来说：我现在把饭煮了，然后再去炒两个菜这就是属于异步机制，大概意思就是，用户请求过来做饭，我做饭了，但是熟没熟先不管，我先response响应给你，我做的事情已经做了；

如图：【异步机制】

2.1：思考+图解+考量【引入了MQ的好处+场景举例说明】

· 这里首先我们插入一张图片，根据图来做思想斗争【MQ的作用】：

1.从上面这个图就可以看出来这是一个异步请求的机制，那么仔细想想，如果客户端请求到系统A，A需要耗费20ms，发送消息到MQ需要5ms，假设服务B的逻辑比较复杂需要200ms才能完成对应的操作，那么此时整个响应至少就变成了20ms+5ms+200ms，总共耗时需要225ms，至于现在的客户端，在这225ms的时间就在原地打圈圈等待，此时的用户体验性是非常差的；
2.综合图来看，图中使用的就是同步机制，那么client端请求到系统A，在系统A中花费了20ms，随之向MQ发送了一条消息花费了5ms，随之直接将请求响应回去给客户端，那么整个请求过程是不是只花费了25ms呢？用户体验感也好，可以先做自己想做的事情，等他想要获取这个数据的时候，这个数据已经异步调过来了；学过ajax的，应该对这个流程是非常熟悉的，还有lazy懒加载这些机制等等。

此时看完这个图和下面的简单分析，我们再回头思考一下上一章的问题点是不是就已经有解决方案了，这里留个问题咱们一起在评论区互动一下，上面引入MQ，使用异步机制，解决了什么问题？ 这里原本是想铺垫一下的，但是没必要一层一层铺垫，直接在这里解答一下个人的观点：

引入MQ消息中间件，极大的降低了系统自己的耦合度，如果此时系统B出现了故障,那么系统A只用自己正常响应客户端，系统B自己处理异常即可，不用影响到服务A的正常业务。

3.MQ的流量削峰

流量削峰，简介大白话其实就是：降低mysql或者是redis的QPS压力，举个例子：假设公司现在的mysql数据库，能承载的QPS是5000/s，一台MQ能承载的并发量大约是几万这个样子，假设给服务A做扩容，将服务A扩容成20台机器，能承载1w的qps，那么想象一下，此时大促销或者是做活动，QPS直接上升到1w/1秒，mysql数据只能抗住最多5000每秒的QPS，怎么办？

如图：【MQ的流量削峰】

直接看图，貌似整个高并发得到了解决，就很nice，这个时候，【访问的QPS高峰期实际上也就是那么一段时间】高峰期过去了，qps降低到了1000/s，而系统B还在消化之前落下的，慢慢就能跟上节奏了，MQ中积压一些qps是没有关系的，因为MQ是基于磁盘操作的，不会丢失数据；

那么想想问题：如果系统A和B之间解耦，A执行成功，B处理失败了，数据一致性的问题怎么解决呢？这个提一嘴，就不深入了，问题解决方案一：MQ的最终消息一致性，B系统消费成功，A系统可以通过观察者模式的zk来实现解决；

4.简单了解MQ的理论支撑1亿QPS高并发和高可用机制？

上面我们已经知道了流量削峰，那么想想，这个是有来了1个亿的qps，当然，有个万来或者是几万qps的并发，基本上都是中大电商流量了，这里为了更有乐趣一些，学习不枯燥，先定个小目标，干他1个亿；小二上图：
【承载一个亿的qps，满满的高级感】

这里做个解释：

1.每台机器上部署的RocketMQ进程一般称之为Broker，每个Broker都会收到不同的消息，然后就会将这批消息存储在自己的本地磁盘文件中(这里是不是就要回想到为什么MQ中积压一些qps是没有关系的)；
2.假设有1亿条消息，10台机器都部署了RocketMQ的Broker，理论上就可以让每天机器上面存储1000万条消息

MQ海量数据的由来：

本质上RocketMQ存储海量消息的机制就是为了分布式的存储，所谓的分布式存储，就是把数据分散在多台机器上来存储，每台机器存储一部分消息，这样多台机器就可以存储海量的消息了；

5.MQ的高可用broker(master和salve)：

那万一要是其中的一台broker出现了宕机，那岂不是丢失了1000w条消息数据，这不是扯犊子吗？【这不就铺垫起来了-MQ的高可用机制】
MQ高可用机制：==broker主从架构以及多副本策略==

简单来说broker是有两种角色的：master(主)
slave(从)，这不又联想起redis的主从架构了，看到这里，还没看redis承载几十万QPS的原理以及机制的，可以去我主页专栏，REDIS中看看；

上一波图：【broker高可用解决方式的演变】

针对以上的图，做个简单的步骤和图解：

1.master broker收到消息之后会同步给slave broker，这样slave broker上就能有一模一样的一份副本数据
2.这样同一条消息在RocketMQ整个集群里就有两个副本了，一个在master broker，一个在分支slave broker里面
3.这个时候如果一个master broker出现故障，还有一个slave broker上有一份数据副本，可以保证数据不丢失，还能继续对外提供服务，保证了MQ的可靠性和高可用性

问题接着演化：数据路由的问题，怎么知道访问哪个broker
【有哪些broker？要怎么样连接到哪一台broker上去发送消息和接收消息？这是一个大问题】

RocketMQ为了解决这个问题，有一个NameServer的概念，她也是独立部署在几台机器上的，然后所有的broker都会把自己注册到NameServer上去，NameServer就知道了集群上有哪些Broker了

【NameServer的引进】

解释：

对于这些个系统而言，如果他要发送消息到broker，会找NameServer去获取路由的信息，就是集群里有哪些broker等信息，如果系统要从broker获取信息，也会找NameServer获取路由的信息，去找到对应的broker获取消息

这期内容比较多，暂时分享到这里！

最后谢谢大家！这篇文章其实干货不多，但是任何一个技术点，都有一个由来，有了由来才能更深刻的学习，带着问题去学习如何解决问题如果此篇文章有不足的地方，或者是有错误的观点，欢迎大家在评论去指出！共同学习，努力进步！

声明：转发请备出处！谢谢！所有的原图可以找我申领，redis的生产环境的部署，集群的搭建，哨兵模式，主从分离，redis如何支撑海量数据+几十万的QPS，master node和slave node的主从分离痛点等等，消息中间件的所有草图，我会全部以分享的形式上传，本人的全部画图笔记，可以无条件分享！