16｜集群：如何构建分布式的消息队列集群？（下）
元数据存储服务设计选型
基于第三方存储引擎
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了构建分布式消息队列集群的关键技术，重点讨论了元数据存储服务的设计选型。首先分析了基于第三方存储引擎和集群内部自实现元数据存储两种方案的具体实现。针对基于第三方存储引擎的集群架构，介绍了元数据存储服务的选型和实现，以及构建集群的方式。其次，讨论了集群内部自实现元数据存储的方案，包括在Broker内部构建元数据集群、利用内嵌到进程的小型分布式存储服务以及部署持久化的单机存储引擎等技术实现。最后，以ZooKeeper和Kafka为例，介绍了它们基于不同方式构建集群的实现思路。文章通过对元数据存储服务设计选型和实现方案的详细分析，为构建分布式消息队列集群提供了有益的指导和思路。文章还提出了基于KRaft的Kafka架构相比基于ZooKeeper架构更为简单清晰的观点，并探讨了消息队列集群中修改配置/权限操作的流程。文章内容丰富，涵盖了技术实现细节和架构设计思路，对于从事分布式系统开发和架构设计的读者具有重要参考价值。
《深入拆解消息队列 47 讲》，新⼈⾸单¥59
全部留言(1)
- 最新
- 精选
张申傲请问下强哥，在Kafka KRaft这类架构中，Controller-Broker节点的职责会不会过重呢？ 它相当于Metadata Service Leader + Broker集群的Controller双重角色，既要管理元数据信息，又要维护Broker集群的状态和数据同步，感觉Controller-Broker的负载会有点高。 这种集群内部实现元数据服务的架构，有没有可能把两类职责拆分开呢？比如Broker-1作为Broker集群的Controller，Broker-2节点作为Metadata Service的Leader？作者回复: 先补充一个信息，当前的Kafka 的Kraft模式，不区分Metadata Service Leader和Broker Controller，统一称为Controller。 然后说一下我的看法：从理论上来看，是有这个可能，但是我认为风险可控。主要有三点原因： 1. 当前 Kafka kraft 模式的 controller 支持两种部署模式： a. 独立部署，固定某些节点只能承担controller角色，不承担Broker角色。即这台节点的资源都是给controller用的，从而控制这个节点的负载。 b. 混合部署，在流量低的时候可以混部controller和broker，此时在流量上涨的情况下，就有可能出现你说的问题。 2. Controller 在内核会有一些优化机制，用来降低controller的压力。比如数据预加载机制，用来在controller切换时，新的controller节点不需要加载全部数据，从而控制负载。 3. kafka本身的集群管控类操作也不会频繁。因此对controller的压力没有那么大。
2023-07-26归属地：北京2
