组成架构

云消息队列 Confluent 版是一个流数据平台，能够组织管理来自不同数据源的数据，是一个稳定高效的系统。如下图所示，它由六个组件构成，分别为Kafka Broker、Rest Proxy、Connect、Zookeeper、ksqlDB、Control Center。

集群资源评估

Kafka Broker资源评估

• 首先，需要评估您的业务需求，需求参数由下表列出。

  需求参数	参数说明
  扇出因子	写入的数据会被consumer消费多少次，其中不包含Broker内部副本的复制流量。
  数据峰值流入	业务数据的峰值流量，单位：MB/s。
  数据平均流入	业务数据的平均流量，单位：MB/s。
  数据保留时长	数据保留时长，默认7天。
  分区副本因子	分区副本因子，默认为3，即每个分区具有3个副本。

• 估算Broker的节点数：理想情况下，单个Kafka Broker最大能够支持100 MB/s的流量；建议生产集群至少需要4个Broker节点数，并保留50%的IO带宽资源冗余。此外，从分区副本限制考虑，每个Broker不应超过2000个分区副本；整个集群不应超过200,000个分区副本。如果预估集群总分区副本数量会比较多，建议您从总分区数来评估所需Broker的节点数。

  说明

  Broker节点数 = Max（4，数据峰值流入 * （扇出因子 + 2 * 分区副本因子-1) * 2 / 400 MB/s）。

• 估算每个Broker的CU数量：由于所需CU数量与集群配置、客户端配置及其使用方式、分区数量、集群规模、Consumer个数、Producer个数等都有关系，难以估算。建议您创建生产集群时，每个Broker使用8 CU以上每Broker的配置，开发测试集群使用4 CU每Broker的配置。同时，建议您每4 CU的Broker上不应超过100个leader副本或300个分区副本（包含leader副本）。

• 估算每个Broker的磁盘大小：每个Broker的磁盘大小 = Max（1TB，数据平均流入 * 数据保留时长 * 分区副本因子 / Broker节点数）。

Connect资源评估

• 节点数评估：建议选择2个节点以上以保证Connect为高可用的。

• CU评估：建议选择每个节点8 CU以上。

Schema Resgitry资源评估

• Schema Resgitry生产环境建议配置2个节点，每个节点2 CU。

Control Center资源评估

• Control Center生产环境建议配置1个节点，计算资源为4 CU以上，数据存储300 GB以上。

ksqlDB资源评估

• 节点数评估：建议选择2个节点以上以保证REST Proxy为高可用的。

• CU评估：建议选择每个节点4 CU以上。

• 存储评估：ksqlDB的存储大小依赖于聚合语句以及并发查询的数量，默认选择100 GB。

REST Proxy资源评估

• 节点数评估：建议选择2个节点以上以保证REST Proxy为高可用的。

• CU评估：如果您需要通过REST Proxy进行消息的持续生产和消费，您需要选择每个节点8 CU以上；否则，您可以选择每个节点4 CU。

集群资源性能对比

下表展示了不同CU个数下，集群的总吞吐量变化，以及单个Producer时延变化。您可以根据业务的数据流量以及时延要求，选择合适的集群CU个数。

默认情况下，云消息队列 Confluent 版集群为4 Broker规格，具备400 MB/s吞吐量的集群性能。如果您希望增加集群的吞吐量性能，可以对集群进行水平扩容。每新增加一个Broker，集群吞吐量性能增加100 MB/s。

下表列出了不同Broker个数下，对应的集群吞吐量性能、消息处理能力，以及能够支持的Partion数量。

集群规格选择建议

以下给出典型场景下的集群规格建议，您也可以参考Confluent官网指导文档。

集群组件资源分配规则

下表列出各组件的资源配置范围。

相关文档

Confluent提供了针对Kafka和Confluent Platform的资源评估工具，该工具适用于云消息队列 Confluent 版，详情请参见Sizing Calculator for Apache Kafka and Confluent Platform。