RocketMQ消息中间件(四)：如何设计一套高可用的消息中间件的部署？MQ的核心数据模型：Topic？生产者系统是如何将消息发送给broker的？ 消费者是如何拉取消息的？MQ的整体架构四大特征

前言：

前三篇文章我们一起分析了一个订单系统中的痛点，不知道到这里的时候，有没有志同道合的猿友已经联想到了一些对应的解决方案，带着问题学习，学以致用，才是最大的进步，目前所在的公司有没有链路能用上MQ消息中间件，为什么使用rocketMQ这个技术，不使用kafka等等其他的消息中间件技术，深思迟疑中，问题中成长，行动中才能生存！

1.如何设计一套高可用的消息中间件的部署？

1.1：NameServer集群化部署，保证mq整套系统的高可用性，
nameServer的设计主要是采用peer-to-peer的模式来做的，也就是可以集群化部署，但是里面然后一台机器都是独立运行的，跟其他机器没有然后通信，每台nameserver实际上都会有完整的集群路由信息，包括所有的broker节点信息和我们的数据信息，等等，所以只要任何一台nameserver存活下来，就可以保证mq系统正常的运行，不会出现故障，因此nameserver的集群化不是是必须的第一步；

1.2：基于dledger的broker主从架构部署，在rocketMQ4.5以前的那种普通的master-slave架构来部署，能在一定程度上保证数据不丢失，也能保证一定的可用性，但是这种方式的缺陷是很冥想的，就是master宕机了之后，没有办法让slave broker自动切换为master broker，需要手动运维修改配置信息，重启机器才行；
· rocketMQ4.5之后已经基于dledger技术实现了可以自动让slave broker自动切换选举成master broker的功能，那么选择基于dledger的主备自动切换的功能来进行生产架构的部署；
· dledger技术是要求至少得是一个master 带两个slave，这样三个broker组成一个group，也就是走位一个分组来运行，一旦master 宕机，他就可以从剩余的两个slave中选举出来一个新的master对外提供服务
注释：每个broker(不管是master还是slave都会将自己注册到所有的nameserver上面去)，然后每个master broker还会把数据同步给slave broker，保证一份数据在不同的机器上面有多份备份

1.3：使用mq系统多机器部署集群，下一步一定会有很多系统使用rocketMQ，有些系统是作为生产者往MQ中发送消息，有些系统是作为消费者从mq中获取消息，还有的系统又是生产者又作为消费这，所有要考虑好这些系统的部署，而对于这些多个系统部署而言，奔上就不应该在mq的考虑范围内，但是还是要提前做好建议规划，就是无论作为生产者还是消费者的系统，都应该多机器集群化部署，保证自己本身作为消费者还是生产者的高可用性。
1.3.1：因为一个系统如果就部署在一台机器上，然后作为生产者向MQ发送消息，那么一旦哪台机器上的生产者系统挂了，整个流程就断开了，不能保证整个系统的高可用信息，但是如果在多太系统上部署生产者系统，然后一台机器生产者挂了，其他机器上的生产者系统可以继续运行；
1.3.2：PS：消费者系统也是集群化部署的，如果一台机器上的消费系统挂了，其他机器上的消费者系统应该是可以继续运行的。

上个图：

回顾下【broker是如何跟nameServer进行通信的？】

1：broker每隔30秒就会发送心跳到所有的nameServer上去，然后每个nameserver都会每隔10s检查一次有没有哪个broker超过120s没有发送心跳的，如果有就会直接认为那个broker已经宕机了，从路由信息中删除这个broker；
1.1：broker和nameserver之间的通信协议是：rpc调用还是http协议？还是tcp长连接呢？ 在rocketMQ的实现中，采用的是tcp长连接进行通信的；
1.2：也就是说：broker会跟每个nameserver都建立一个tcp长连接，然后定时通过tcp长连接发送心跳请求过去；
小结一下：所以各个NameServer就是通过跟Broker建立好的长连接不断收到心跳包，然后定时检查broker有没有120s都没有发送心跳包，来判定集群各个broker到底挂掉了没有；

2.MQ的核心数据模型：Topic？分布式存储？

MQ的数据模型是什么？你投递出去的消息在逻辑上到底是放到哪里去的？是队列吗？还是其他的什么呢？

引出MQ中的核心数据模型：Topic
什么是topic？举例说明：

· 例如：现在一个订单系统需要往MQ中发送订单小熊，那么此时就应该建一个topic，她的名字可以叫做topic_order_info,也就是一个包含了订单信息的数据集合；

· 然后订单系统投递的订单消息都是进入到这个topic_order_info这个数据集合中去的，那么她可以指定从topic_order_info这里面去获取消息，获取出来的都是他想要的订单消息了；

· 【一句话表达：topic其实就是一个数据集合的意思，不同类型的数据得放入到不同的topic里面去】；

· 要是有一些商品数据要发送到MQ中，这时就应该创建一个topic，例如叫做topic_product_info，代表里面都是商品数据，那些想要从MQ里获取商品数据的系统就可以从topic_product中获取了；

· 所以简单来说，你的系统如果要往MQ中写入消息或者获取消息，首先第一步就是要创建一些topic，作为数据集合存放不同类型的消息，例如说t订单的opic，商品的topic，等等；

问题：topic作为一个数据集合是在如何在broker集群中存储的？
【引出分布式存储概念】

例如：现在有一个订单topic，可能订单系统每天都会往里面投递几百万数据，如何这些数据在MQ集群中还得保留好几天，那么最终可能会有好几千万的数据量，这个还只是一个topic；

那么如果有很多的topic，并且里面都有大量的数据，最终加起来的总和也许是一个惊人的数字，这个时候，如此大量的数据本身是不大可能存放在一台机器上的；

一台机器没办法存储这么多的数据，咋办？【分布式存储】

topic分布式存储：

· 可以在创建topic的时候指定让他里面的数据分散存储在多台broker机器上面，例如一个topic有1000万条数据，此时有两台broker，那么就可以每天broker存放500万条数据。

· 这样就可以把一个topic代表的数据集合分布式存储在多太机器上面；汇报心跳机制同时汇报topic数据情况；

· 每个broker在进行定时的心跳汇报给nameServer的时候，都会告诉NameServer自己当前的数据情况，比如有哪些topic的数据在自己这里，这些信息都是属于路由信息的一部分

· broker心跳时候汇报给nameserver自己的数据情况，这样每个nameserver都知道集群中有哪些broker，每个broker都存放了哪些topic的数据；

如图：

3.生产者系统是如何将消息发送给broker的？

首先在发送消息之前，得先有一个topic，然后在发送消息的时候，得指定要发送到哪个topic里面去。

知道了要发送的topic，那么就可以跟nameserver建立一个TCP长连接，然后定时的从他那里拉取到最新的路由信息，包括集群中又要哪些broker，集群中有哪些topic，每个topic都存储在哪些broker上面；

然后生产者系统自然就可以通过路由信息找到自己要投递消息的topic分布在哪几台broker上，此时可以根据负载均衡算法，从里面选择一台broker机器出来，比如轮询算法，或者是hash算法，都可以，选择一台broker之后，就可以跟那个broker建立一个tcp长连接，然后通过长连接向broker发送消息即可；

broker接收到消息后：

broker收到消息后就会将消息保存到自己的本地磁盘中；

注意事项：

生产者一定是投递消息到master broker，然后masterbroker会同步数据给他的slave
brokers，实现一份数据同步多份副本，保证master故障的时候数据不丢失，而且可以自动把slave切换为master提供服务；

4.消费者是如何从broker上拉取消息的？

消费者系统和生产者系统原理是类似的，首先更nameserver建立scoket长连接，拉取路由信息，接着找到自己要获取消息的topic在哪几台broker上，就可以跟broker建立长连接，从里面拉取消息了。

也有一个注意点：

消费者可以会从master broker拉取消息，也可能从slave
broker拉取消息，都有可能，要看返回时候的第一次拉取返回时候的一切状况；

【结合拉取消息和发送消息的图形】

5.小结一下此时的MQ架构的四大特征

rocketMQ整体架构：高可用、高并发、海量信息、可伸缩性

1、整个这套生产架构是实现完全高可用的，因为nameserver随便一台机器挂了都不怕，nameserver是集群部署的，每台机器都有完整的路由信息；
2、broker随便挂了一台机器也不怕，挂了slave对集群没有太大的影响，挂了master也会基于dledger技术实现自动切换为master broker；
3、生产者和消费者系统随便挂了一台都不怕，因为生产者系统和消费者系统也是集群化部署的，就算出现宕机，其他机器也会接管工作的。
4、而且这个架构可以抗下高并发，因为假设订单系统对订单topic要发起每秒10万QPS的写入，那么只要订单topic分散在5台master broker上，实际上每个master broker都会承载2万QPS的写入，也就是说高并发场景下的10万QPS可以分散到多太broker上抗下来。
5、然后集群足矣存储海量消息，因为所有数据都是分布式存储的，每个topic的数据都是分布式存储在多台broker机器上面的，用集群多台masterbroker就足以存储海量的消息。
6、所有，用多个master broker部署的方式+topic分散在多台broker上的机制，可以抗下高并发访问已经海量消息的分布式存储；
7、每个master broker有两个slave broker结合dledger技术可以实现故障时的自动slave-master切换实现高可用性。
8、这套架构还具备伸缩性，如果要抗更高的并发，存储更多的数据，完全可以在集群里加入更多的broker机器，这样就可以线性的扩展寄去了。

总结到这里第四章，自己和一起浏览文章的朋友们对MQ也有了个基础的概念，当然这四章都是一些理论已经可能会遇到的问题以及实际在开发过程中遇到的一些难题和痛点，下一章慢慢会开始分享如何实际操作一波MQ的使用。

第三章链接地址： RocketMQ消息中间件(三).

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