主流消息中间件架构分析
消息中间件原理
消息中间件原理消息中间件是一种用于不同应用程序之间进行通信的软件。
它可以帮助应用程序在分布式系统中进行异步通信，从而实现解耦和提高系统的可伸缩性。
消息中间件的原理是基于消息传递模式，它将消息从一个应用程序传递到另一个应用程序，从而实现应用程序之间的通信和协作。
消息中间件的原理主要包括消息传递、消息队列和消息路由。
首先，消息传递是消息中间件的核心原理，它通过将消息从一个发送者传递到一个或多个接收者来实现应用程序之间的通信。
这种消息传递可以是同步的，也可以是异步的，这取决于应用程序的需求。
通过消息传递，应用程序可以实现解耦，即发送者和接收者之间不需要直接进行通信，它们只需要将消息发送到消息中间件，由消息中间件负责将消息传递给接收者。
其次，消息队列是消息中间件实现异步通信的重要手段。
消息队列是一种存储消息的数据结构，它可以暂时存储消息并按照一定的规则进行管理和处理。
通过消息队列，发送者可以将消息发送到队列中，而接收者则可以从队列中获取消息进行处理。
这种异步通信可以提高系统的可伸缩性，因为发送者和接收者之间的通信不再是实时的，它们可以根据自己的处理能力和负载情况进行消息的发送和接收，从而实现系统的平稳运行。
最后，消息路由是消息中间件实现消息传递的关键。
消息路由可以将消息从发送者传递到接收者，并且可以根据一定的规则和条件对消息进行过滤和路由。
通过消息路由，消息中间件可以实现消息的可靠传递和负载均衡，从而保证系统的稳定性和可靠性。
消息路由还可以根据消息的内容和属性将消息进行分类和分发，从而实现消息的多路复用和选择性接收。
综上所述，消息中间件的原理是基于消息传递、消息队列和消息路由的。
它通过这些原理实现应用程序之间的异步通信，从而实现解耦和提高系统的可伸缩性。
消息中间件在分布式系统和微服务架构中具有重要的作用，它可以帮助应用程序实现高效的通信和协作，从而提高系统的性能和可靠性。
希望本文对消息中间件的原理有所帮助，谢谢阅读！。
中间件的分类和功能应用场景
中间件的分类和功能应用场景中间件是一种位于操作系统和应用程序之间的软件，它具有丰富的分类和功能应用场景。
本文将围绕中间件的分类和功能应用场景展开阐述。
一、中间件的分类1. 消息中间件：消息中间件是一种用于实现应用程序之间异步通信的中间件。
它可以将消息发送者和接收者解耦，提高系统的可靠性和可扩展性。
消息中间件常见的应用场景包括分布式系统、微服务架构、异步任务处理等。
2. 缓存中间件：缓存中间件是一种将数据存储在内存中，提供高速数据访问的中间件。
它可以减轻数据库负载，加快数据读写速度，并提供数据的高可用性。
缓存中间件常见的应用场景包括网站加速、数据缓存、分布式锁等。
3. 反向代理中间件：反向代理中间件是一种将客户端的请求转发到多个服务器上的中间件。
它可以实现负载均衡、高可用性和安全性。
反向代理中间件常见的应用场景包括网站负载均衡、HTTPS加密传输、请求过滤等。
4. 分布式计算中间件：分布式计算中间件是一种将任务分解并分布到多台计算机上进行并行计算的中间件。
它可以提高计算效率、减少计算时间，并实现大规模数据处理。
分布式计算中间件常见的应用场景包括大数据分析、机器学习训练、科学计算等。
5. 服务网格中间件：服务网格中间件是一种用于管理和控制微服务架构中服务间通信的中间件。
它可以提供服务发现、负载均衡、故障恢复等功能，简化微服务架构的开发和维护。
服务网格中间件常见的应用场景包括微服务架构、容器编排等。
二、中间件的功能应用场景1. 异步消息传递：消息中间件可以实现异步消息传递，将消息发送者和接收者解耦。
它常用于分布式系统中，可以提高系统的可靠性和可扩展性。
例如，电商网站的订单系统可以将订单消息发送到消息中间件，然后由库存系统和物流系统异步消费这些消息，实现订单处理的解耦和异步化。
2. 数据缓存：缓存中间件可以将数据存储在内存中，提供高速数据访问。
它常用于加速网站访问、减轻数据库负载，提高系统的响应速度。
例如，电商网站的商品信息可以缓存在缓存中间件中，减少对数据库的查询，提高用户访问速度。
中间件知识
中间件知识1，常见应用系统开发构架：传统的两层结构：表示层（Presentation Layer）：用于处理人机交互。
目前最主流的两种表示层是Windows桌面和IE浏览器方式。
它主要责任是处理用户请求，例如鼠标点击、输入、HTTP请求等，实际部分业务逻辑。
数据层（Data source Layer）：处理数据库、消息系统、事务系统。
实际部分业务逻辑。
经典的三层结构：表示层（Presentation Layer）：用于处理人机交互。
目前最主流的两种表示层是Windows桌面和IE浏览器方式。
它主要的责任是处理用户请求，例如鼠标点击、输入、HTTP请求等。
业务层（Business Layer）：模拟了企业中的实际活动，也可以认为是企业活动的模型。
数据层（Data source Layer）：处理数据库、消息系统、事务系统。
通用的四层结构：表示层（Presentation Layer）：用于处理人机交互。
目前最主流的两种表示层是Windows桌面和IE浏览器方式。
它主要的责任是处理用户请求，例如鼠标点击、输入、HTTP请求等。
业务层（Business Layer）：模拟了企业中的实际活动，也可以认为是企业活动的模型。
数据层（Data source Layer）：处理数据库、消息系统、事务系统。
安全层（Security Layer）：管理系统身份验证、授证、日志等。
主要产品：应用中间件、平台中间件、工作流中间件、数据传输中间件等。
2，什么是中间件中间件（middleware）：是基础软件的一大类，属于可复用软件的范畴。
顾名思义，中间件处于操作系统软件与用户的应用软件的中间。
中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。
在众多关于中间件的定义中，比较普遍被接受的是IDC表述的：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。
信息系统架构分析与中间件
一、分布式信息系统1.1分布式信息系统结构分布式信息系统是多个节点的系统，每个数据节点分布在不同区域，拥有各自的终端，承担系统的不同工作角色。
犹如一个有机体的器官，相对独立，又相互关联。
图，多个数据节点构成的分布式信息系统异步数据流转和同步协同作业是数据节点关联的两种形式。
1.2分布式信息系统的异步数据流转图，数据节点异步数据流转消化其它节点提供的数据，同时，为相关节点提供加工后的业务数据是数据节点重要的业务功能。
流通与节点之间数据，犹如有机体的血液，携带着不同的信息能量实现1 / 7相关业务器官功能联动。
数据在各个节点之间的流转逻辑和效率是整个系统功能和性能的核心，同时也是信息系统的一个核心技术。
1.3数据节点间的同步协同作业终端的一些业务请求，需要一个以上的节点联合操作才能够完成。
这种联合完成一个客户请求的功能称为同步协同作业。
跨节点任务需要考虑动态的业务流程和任务完整性等内容。
是信息系统的的又一核心技术。
图，业务请求的跨节点联合实现图中，节点B处理终端的请求时，需要与节点A联合操作。
节点C处理终端请求时，也需要与节点A合作完成。
1.4分布式信息系统技术模型图，数据管道类型2 / 7一个单机版信息系统，是一个简单的C/S模式。
而多节点业务系统存在同步、异步两种S/S结构。
分布式信息系统技术模型可以可以分为四个方面：数据结构、终端界面、同步S/S和异步S/S。
同步S/S可以称为同步协同作业总线，异步S/S可以称为异步数据流转总线。
图，分布式信息系统架构抽象模型1.5数据通道是信息系统的技术关键从“技术模型”可以看出分别式信息系统存在三种数据通道：C/S 访问通道，同步S/S访问通道，异步S/S数据流转通道。
每个通道都有复杂的交互协议和任务控制逻辑。
构建这些三类通道是系统开发的核心技术。
二、分布式信息系统架构中间件2.1信息系统数据通道中间件在当前市场上为了满足快速开发的需要，出现了一些中间件产品，如消息中间件、交易型中间件、数据库复制系统等。
如何进行分布式系统架构设计
如何进行分布式系统架构设计在当今互联网时代，随着大数据和云计算的崛起，分布式系统架构设计越来越成为互联网应用领域的主流趋势。
分布式系统架构设计的核心目标在于提高系统的可靠性、可伸缩性和可维护性。
一、概述随着数据量的不断增加，单一系统已经无法承载大规模的数据处理需求。
为了提高系统的处理能力和可靠性，分布式系统应运而生。
在分布式系统中，不同的计算资源被分布在多个计算节点之上，形成了一个协同工作的整体系统。
因此，分布式系统架构设计需要兼顾系统结构和实现方式两个方面。
二、分布式系统结构设计原则1. 服务分类和分层在分布式系统中，通常将系统中的服务按照功能划分为不同的服务分类。
不同的服务之间可以根据实际需要进行不同的部署和管理。
同时，可以通过分层来实现系统的各个服务之间的上下游功能调用。
2. 模块化设计在分布式系统中，系统的各个服务在功能上可以进行细分，每个细分功能模块可以独立的运行和部署。
这样，可以让系统更加模块化，架构更加清晰。
3. 异步化设计在分布式系统中，由于各个服务之间的通信以及数据的传输，通常需要较长的时延。
因此，在系统设计上可以采用异步化的方案，减少系统响应时间，提升系统的处理能力。
三、分布式系统实现方式1. 服务端框架服务端框架可以帮助我们快速搭建分布式系统，例如：Dubbo、Spring Cloud、Apache Thrift等。
这些框架提供了完善的服务化治理方案，可以通过框架来完成服务发布和服务的管理。
2. 消息中间件消息中间件是分布式系统实现的一种重要方式，通过消息中间件，可以实现分布式系统之间的异步通信。
目前业界比较主流的消息中间件有：Apache Kafka、RabbitMQ等。
3. 分布式存储分布式系统离不开分布式存储。
分布式存储可以通过对象存储、分布式文件系统、键值存储等多种方式实现。
常见的分布式存储方案有：Hadoop HDFS、Ceph、GlusterFS、MongoDB等。
中国中间件市场规模、中间件市场份额占比、中间件厂商的核心竞争力及中间件行业格局发展前景
中国中间件市场规模、中间件市场份额占比、中间件厂商的核心竞争力及中间件行业格局发展前景一、现状目前，全球的中间件市场规模约320亿美元。
随着云计算、大数据、物联网等数字化技术普及以及政务大数据、智慧城市、企业上云等行业数字化热点项目的推进，大量新的市场需求将会出现。
2019年中国中间件市场总体规模达到72.4亿元，同比增长11.40%。
预计2023年，中国中间件市场空间13.6亿美元，5年复合增长率15.7%。
随着国产中间件厂商技术的升级，以东方通、宝兰德和普元信息为代表的国产厂商赶超者，在电信、金融、政府、军工等行业客户中不断打破原有的IBM和Oracle的垄断，逐步实现了中间件软件产品的国产化自主可控。
预计国产厂商在电信行业的国产替代空间为14亿元，在金融行业的国产替代空间为21亿元，在政府行业的国产替代空间为23亿元。
总替代空间高达57.4亿元。
中间件是居于操作系统之上、应用之下，实现分布式计算、数据通信以及为应用从数据库是和服务器中，读取写入各种数据的计算机软件，是IT系统进行通信和传递消息的纽带。
在现代分布式计算架构下，中间或Middle实际指代中间件在应用系统结构中居于各类应用与操作系统之间，是一种为分布式计算环境提供通信服务、交换服务、语义互操作服务等系统之间协同集成服务，解决系统之间互连互通问题，帮助用户灵活、高效地开发和集成应用软件的基础型软件。
交易中间件是一种对象请求代理中间件，一般基于标准的构建框架，用于实现不同厂家软件之间相互调用和交互操作，它是面向对象技术与分布式计算技术相互结合的产物。
消息中间件是中间件家族中非常广泛的一种中间件，其主要作用是解决分布式计算环境下，多个子系统间的消息通信问题。
应用服务器中间件位于客户浏览器和数据库之间，为应用程序提供业务逻辑的代码，应用服务器通过组件的应用程序接口将商业应用逻辑曝露给客户端的程序，同时为应用提供运行平台和系统服务，并管理对数据库的范围。
中间件的常见类型
中间件的常见类型中间件是指位于操作系统和应用程序之间的一层软件，它可以在应用程序和操作系统之间进行通信和交互。
中间件的作用是提供一种机制，使得应用程序能够更加高效地运行，并且具有更好的可扩展性和可维护性。
在实际开发中，常见的中间件类型包括缓存中间件、消息中间件、日志中间件和安全中间件等。
一、缓存中间件缓存中间件是一种常见的中间件类型，它的主要作用是在应用程序和数据库之间增加一层缓存层，以提高数据访问的性能和效率。
常见的缓存中间件有Redis、Memcached等。
缓存中间件可以将频繁访问的数据缓存到内存中，从而减少对数据库的访问次数，提高数据的读取速度。
此外，缓存中间件还可以实现数据的分布式存储和高可用性，提高系统的稳定性和可靠性。
二、消息中间件消息中间件是一种用于实现应用程序之间异步通信的中间件，它可以将消息发送者和接收者解耦，从而提高系统的可扩展性和可维护性。
常见的消息中间件有RabbitMQ、Kafka等。
消息中间件通过将消息发送到消息队列中，然后由消费者从队列中读取消息并进行处理。
这种方式可以实现异步处理和流量削峰，从而提高系统的吞吐量和性能。
三、日志中间件日志中间件是一种用于记录应用程序运行日志的中间件，它可以将应用程序的日志信息写入到指定的日志文件或日志数据库中，方便开发人员进行系统故障排查和性能分析。
常见的日志中间件有Log4j、logback等。
日志中间件可以记录应用程序的运行状态、错误信息、调试信息等，帮助开发人员快速定位问题和解决bug。
四、安全中间件安全中间件是一种用于保护应用程序安全的中间件，它可以在应用程序和网络之间增加一层安全防护层，提供身份认证、访问控制、数据加密等安全功能。
常见的安全中间件有Spring Security、Shiro等。
安全中间件可以对用户的身份进行认证和授权，控制用户的访问权限，保护应用程序的数据不被非法访问和篡改。
总结：中间件是一种位于操作系统和应用程序之间的软件，它可以提供各种功能和服务，帮助应用程序更高效地运行。
消息中间件的概念
消息中间件的概念
消息中间件（Message Oriented Middleware，MOM）是一种在分布式系统中用于传递消息的软件中间件。
它提供了一个可靠的、异步的消息传递机制，用于在不同的应用程序、系统或服务之间进行通信和数据交换。
消息中间件的主要功能包括：
1. 消息传递：它允许应用程序通过发送和接收消息来进行通信，而不是直接调用对方的函数或方法。
消息可以是文本、数据对象或其他形式的信息。
2. 解耦：消息中间件将发送方和接收方解耦，使它们不需要知道对方的具体实现细节、位置或运行状态。
发送方只需将消息发送到中间件，而接收方可以在需要时从中间件获取消息。
3. 可靠性：消息中间件通常提供可靠的消息传递机制，确保消息不会丢失或重复传递。
它可以处理消息的确认、重试和容错等问题。
4. 异步性：消息中间件支持异步通信，发送方发送消息后可以立即继续执行其他操作，而无需等待接收方的响应。
这有助于提高系统的并发性和性能。
5. 可扩展性：消息中间件通常支持分布式部署和横向扩展，以便处理大规模的消息流量和高并发的应用场景。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
主流消息中间件架构分析Kafka首先还是来看Kafka的系统架构（做消息中间件逃不开要去了解Kafka）。
Kafka ecosystem包含以下几块内容：•Producer•Consumer•Kafka cluster•ZooKeeper其中ZooKeeper承当了NameServer的角色，同时用于保存系统的元数据，提供选主、协调等功能。
Broker是真正的服务端，用于存储消息。
可用性首先看外部依赖的可用性。
如果你的系统“强依赖”了外部的其他服务，那么你的系统的可用性必然和外部服务的可用性相关。
（强依赖表示不可脱离依赖的服务保持正常运行）从上面的架构可以看出Kafka只是依赖了ZooKeeper，而ZooKeeper本身是高可用的（2N+1个节点的ZK集群可以容忍N个节点故障），所以不会对整个集群的可用性造成影响。
接着看Kafka自身的可用性。
谈可用性必然就会涉及到备份问题，没有备份就意味着存在单点问题，也就没有高可用可言了。
所以我们具体来看一下Kafka的备份策略。
Kafka Replication的数据流如上图所示，从图中可以得到的一些信息：1. 分区是有备份的，如topic1-part1上图中有3个2. 分区的备份分布在不同的Broker上，上图中topic1-part1分布在broker1、broker2、broker3上，其中broker1上的为Leader3. 分区的Leader是随机分布的，上图中topic1-part1的Leader在broker1，topic2-part1的Leader在Broker上，topic3-part1的Leader的Broker4上4. 消息写入到Leader分区，之后通过Leader分区复制到Follower分区Kafak这样的Replication策略，保证了任何一个Broker出现故障时，系统依旧是可用的。
如broker1出现故障，此时会重新选举topic1-part1的Leader，之后可能是broker2或者broker3上的topic1-part1成为Leader然后负责消息的写入。
所以系统的可用性取决于分区备份的数量，这个备份数据是可配置的。
Kafka自身通过Replication实现了高可用，结合依赖的ZooKeeper也是高可用，所以整个系统的可用性得到了较好的保障。
可靠性在消息中间件中，可靠性主要就是写入的消息一定会被消费到，条消息不会丢失。
在分布式环境中消息不丢失有两点：1. 消息在成功写入一个节点后，消息会做持久化2. 消息会被备份到其他物理节点只要做到上面两点就可以保证除所有节点都发生永久性故障的情况下数据不会丢失。
Kafka Broker上写入的消息都会刷盘（可以是异步刷盘也可以是同步刷盘），也会备份到其他物理节点，所以满足以上两点。
异步刷盘结合多节点的备份策略也能提供比较好的可靠性，除非是机房掉电之类的情况导致所有节点未刷盘的数据丢失。
当然，消息丢失不一定指消息真的从磁盘上被销毁或者没被存储下来，如果消息被存储下来了，但是没办法被消费，对客户端来说也是消息丢失。
比如Consumer收到消息后进行ACK之后再消费，如果在消费之前Crash了，那么下一次也不会拿到这条消息，也可以理解成消息丢了，但是这这篇文章中我们不讨论这种情况。
评价优点1. 部分功能托管给了ZK，自身只需要关注消息相关的内容，从这个角度上说是简化了部分内容2. 机器利用率高。
从上面备份的策略可以看出不同Broker之间数据是互为备份的，这样的结构相对于主从模式提高了机器利用率（大部分主从模式，从都是无用状态的）缺点1. 引入了ZK，增加了外部依赖，增加了运维的复杂性备份的方式从系统架构上说，互为主备是较好的方式，但是实现上会比较复杂，如果是自己去实现一个MQ，还是从主从的模式入手比较容易。
Kafka的备份策略及基层WAL的实现就比较复杂了，这个以后有机会说RocketMQ(图片取自RocketMQ_design文档)RocketMQ中包含以下几块内容：•Producer•Consumer•NameServer•BrokerProducer及Consumer和Kafka相同（所有的MQ都会提供Producer和Consumer），Rocket也是有Broker集群，和Kafka最大的区别是RocketMQ自己实现了一个集群模式的NameServer服务。
可用性RocketMQ的可用性也分为NameServer和Broker两块讨论。
NameServer是集群模式的，且“几乎”是无状态的，可以集群部署，所以不会存在可用性的问题。
（无状态意味着每个节点是独立提供服务的，只需要部署多个节点就可以解决可用性的问题）Broker的可用性又可以分为两块，对一个Topic而言，它可以分布在多个Master Broker上，这样在其中一个Broker不可用之后，其他的Broker依旧可以提供服务，不影响写入服务。
在一个Master Broker挂掉之后虽然可以通过其他Master来保证写入的可用性，但是已经写入到故障Broker的部分数据可能会无法消费。
RocketMQ通过Master-Slave的模式来解决这个问题。
Master永久故障后可以将Master上的读取请求转移到Slave上，这样可以保证系统的可用性（Master-Slave之间是异步复制的，意味着可能少量数据还没有从Master复制到Slave，这个在可靠性部分讨论）。
综合上面的两点，RocketMQ也提供了高可用的特性，且可用性只取决于自身的服务，没有像Kafka一样引入额外的，像ZK这样的服务。
可靠性可靠性从单个Broker写入消息的可靠性和消息备份两个角度去考虑。
RocketMQ采用了同步刷盘的方式来持久化写入的消息。
同步刷盘和异步刷盘的唯一差别是异步刷盘写完pagecache直接返回，而同步刷盘需要等待刷盘完成之后才返回，写入流程如下：1. 写入pagecache，线程等待，通知刷盘线程进行刷盘2. 刷盘线程刷盘后，唤醒前端等待线程，可能是一批线程3. 前端等待线程想用户返回写入结果同步刷盘必然耗时要比异步刷盘要大，如何解决同步刷盘带来的性能的损耗后面在谈采用同步刷盘的方式，从单个节点的角度出发可靠性要比异步刷盘的方式要高，因为只要Producer收到消息写入成功的反馈，那么这条消息必然刷盘了，不会应为掉电等原因导致消息丢失。
单个节点必然会面对单点问题，当一个节点永久故障无法恢复时，哪怕这条消息已经持久化了也是没有意义的。
相对于Kafka的互为备份的方式，RocketMQ采用的M-S的方式。
M-S方式就遇到了主从复制延迟的问题（异步复制永远是延迟的），那么在Master不可用后可能会导致部分数据丢失。
RocketMQ针对这种场景，提供了同步双写的模式。
评价优点1. 无外部依赖（这个以为着你的系统不需要额外的服务，无论从运维或者可用性出发，这确实是一个优点）缺点1. M-S结构带来的机器利用率问题（大部分时候Slave可能是空闲的）受限于M-S的机器利用率，实际上不会采用一主多从的模式，绝大部分是一主一从，部分可靠性要求没那么高的业务甚至都是没有挂载Slave的。
这点得到了阿里内部开发同学的确认，这也是M-S模式的缺陷。
MQ的一些其他架构Kafka引入了外部的ZK，而RocketMQ的主从模式又不够“好”，那能不能结合一下两种模式呢？接着来讨论几种笔者考虑的架构。
结合Kafka和RocketMQ这种架构主要就是在Kafka的基础上移除对ZK的依赖。
引入ZK主要是为了解决分布式系统的协调问题，另外Kafka会将元数据（Topic的配置、消费进度等信息存在ZK上）保存在ZK 上，同时提供NameServer的服务。
在这点上比较赞同RocketMQ的做法。
元数据其实都可以存储在Broker上，因为Broker是有状态的，所以在它上面的消费进度等信息其实和其他Broker是无关的（如果是有相互备份的需要同步这块数据），所以NameServer可以很轻量级，做成无状态的。
RocketMQ确实也这样去做了，NameServer的代码大约1000行，还是比较简单的。
这种架构在实现上有一个最大的问题就是移除了ZK之后，内部采用互为主备的方式需要对每个Topic的Partition选出Leader。
在无中心节点的架构中自己来实现选主是一件非常困难的事情，包括要去处理网络分区等问题。
当我们在以上架构中取解决这个问题其实可以通过一些妥协，比如可以先选出中心节点，然后由中心节点来负责剩余的选主相关的问题。
中心节点可以简单的通过人工指定的方式，中心节点本身的可用性其实并不是非常重要，因为脱离中心节点系统是可以正常运行的，只是无法进行选主。
系统的可用性取决与是否中心节点故障同时有其他节点发生故障（牺牲了一些自动化运维，因为没有考虑中心节点的高可用，但是除去了外部依赖，系统设计总是会有tradeoff）。
移除NameServer深入考虑一下：•元数据信息无非Topic配置、消费进度，数据量不会很大，完全可以存储直接存储在Broker上•且Broker本身已经是多节点的，天然的就可以实现元数据的备份将元数据存储在Broker上之后会面临一个问题：每一个Broker必须拥有所有的元数据，那么所有Broker之间需要通信来获取Topic数据（如果只是数据可用新，只是几个Broker之间备份）。
这个问题可以引入Gossip之类的协议来实现，所以架构可以去掉上面的NameServer，演变成如下结构：到这里，架构其实就剩下一个Broker集群，Broker之间的数据采用Kafka的备份策略，Broker 之间的元数据通过Gossip协议来完成复制。
到这里其实系统架构非常简单了，感觉也没有可以移除和变更的内容了（笔者的信仰——简单即美）。
但是其实一直忽略了一个问题就是上面的tradeoff，最终对于一个系统，我们肯定希望足够自动化，所以我们还是要去解决中心节点的高可用问题。
如何在Broker中选出一个唯一的Leader，这个其实就是分布式系统的一致性问题，只要引入一个可以解决分布式系统一致性问题的协议即可，比如Raft、Paxos之类。
所以这个架构理论上是可行的：•无NameServer；•Broker之间采用互为主备的方式来保证系统的可用性和可靠性；•引入Gossip协议来复制元数据；•引入一致性协议来解决选主的问题；o简单点可以用一致性协议来选中心节点，由中心节点负责协调其他问题o本身也可以通过一致性协议直接来进行每一个Topic的Partition的选主问题如果我们自己去写一个MQ之前说过公众号希望写一个类似《从入门到XXX》的系列文章，所以并不希望一上来就将系统实现设计的太复杂，以致于自己都无法实现。