标签：存储 架构 字节 Offer 部署 Broker Topic 秀出 NameServer
前言
微服务是近年来备受关注的话题，相比于传统的SOA而言，更容易理解，也更容易实践，它将“面向服务”的思想做得更加彻底。有人说它非常好，但就是“玩不起”，why？
微服务是一种分布式系统架构，它建议我们将业务切分为更加细粒度的服务，并使每个服务的责任单一且可独立部署，服务内部高内聚，隐含内部细节，服务之间低耦合，彼此相互隔离。此外，我们根据面向服务的业务领域来建模，对外提供统一的API接口。微服务的思想不只是停留在开发阶段，它贯穿于设计、开发、测试、部署、运维等软件生命周期阶段。
可见，我们提到的微服务，实际上是一种架构思想，我们不妨称它为“微服务架构”。今天就带着大家；来学习这份阿里技术专家手写的《微服务架构笔记》，让你成为一名优秀的微服务架构师。
NameServer的部署
关于NameServer，我们之前的文章已经详细讲解过了集群化的内容，这里直接把它部署到三台机器上，作为一个高可用集群
Broker的部署
Broker的部署我们之前也有讲到过，主要使用的是4.5版本后的Dledger自动化切换主从的集群
Broker与NameServer之间的通信协议是什么呢？http、rpc还是tcp呢？
其实它们之间采用的是TCP长连接通信，也就是说Broker会跟每个NameServer建立TCP长连接，然后定时通过TCP长连接发送心跳请求过去。
访问MQ的系统（生产者和消费者）的部署
一定会有大量的系统访问RocketMQ，因为RocketMQ就是为此而生的，有些系统自己本身既是生产者又是消费者，所以这些系统的部署也要考虑进去。
对这些系统部署的考虑，其实不应该是搞MQ的部门来考虑的，如果系统本身是自己公司的，可以提出一些建议，让生产者和消费者都集群化部署，保证高可用。但如果是第三方系统，那就无法插手了，我们能做到的只有考虑第三方系统崩溃，无法与MQ正常通信的情况下，如何让MQ正常运转。
Topic是什么
Topic是mq的核心数据模型，如果直接翻译是主题的意思，但是听到主题的解释，是不是一脸懵逼，是不是瞬间想到的是手机主题，电脑主题。
所以它不能直译，它表达的就是一个数据集合的含义，集合的是同一类的数据，不同类型的数据存到不同的Topic中。
所以系统无论是要写入消息还是读取数据，最开始都是要先定义Topic的，然后再从定义的Topic中获取同类型的数据。
那么Topic是如何在Broker中存储的呢？
存储的方式其实就是分布式存储。我们在定义Topic的时候指定它里面的数据分布到多台的Broker上进行存储，这里要注意的一点是，实际上分布的对象是MasterBroker，SlaveBroker会向MasterBroker拉取数据，作为一个副本存在。而Broker在向NameServer发送心跳的时候，会把Topic存储在哪些Broker中的信息告诉NameServer。
生产者如何发送消息给Broker
前边我们聊过，发送消息前首先是定义Topic，然后发送消息的时候是要指定你要发送到哪个Topic中去的。
既然我们知道了要发送到哪个Topic中，下一步就是要定位Topic的位置，如何定位呢？就是与NameServer建立Tcp长连接，定时拉取注册信息，可以获取到这个Topic目前被分配到哪些Broker中。然后就可以根据负载均衡算法，选定一台Broker(具体的负载均衡算法后边文章再介绍)。
选定了Broker后，就可以再与Broker建立Tcp长连接，通过Tcp长连接发送消息给Broker中的Topic。
而Broker在接收到消息后，就会把消息存储到磁盘中，再往后就是SlaveBroker与MasterBroker数据同步，形成副本，保证高可用了。
整个过程就是这样的。
消费者如何从Broker上消费消息
说完了生产者发送消息的过程，我们再来聊聊消费者消费消息的过程。
其实消费者消费消息的过程和生产者是类似的，同样第一步也是定义Topic，然后从NameServer获取信息，定位到Topic所在的多个Broker，之后负载均衡定位到要访问的Broker，与Broker建立连接获取消息。
这里唯一不同的就是，再获取消息的时候是可能在MasterBroker上获取的，也可能在SlaveBroker上获取，要依据当时的情况而定。
整体架构总结
最后我们再来看一看这套架构，是可以实现完全的高可用的。
NameServer集群化部署，Broker集群化部署，还可以通过Dledger自动化切换主从，生产者消费者也是集群部署，随便挂了一台不受影响。
而且这套架构也不怕高并发，高并发下的消息可以分布到多个Broker下处理，减少系统压力。
然后我们的集群可以存储海量的消息，因为存储方式是分布式存储的。
最后，这套架构是具有可扩展性的，如果业务需求并发量增大，也是可以扩展Broker的数量以支持更高的并发和更大的存储的。
这样我们的RocketMQ的生产部署架构就算完成了。
好了，今天就说到这里，欢迎小伙伴们一起走入消息中间件的世界。
总结
在清楚了各个大厂的面试重点之后，就能很好的提高你刷题以及面试准备的效率，接下来小编也为大家准备了最新的互联网大厂资料。
]
[外链图片转存中…(img-4PWnOvs7-1621218175895)]
[外链图片转存中…(img-GBjEaE1n-1621218175897)]
标签：存储,架构,字节,Offer,部署,Broker,Topic,秀出,NameServer 来源： https://blog.csdn.net/m0_56605033/article/details/116918239
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。