Kakfa 实例均为集群化部属，每个 Kakfa 实例由多个 Broker 组成。本文档介绍如何保障 Kafka 集群各个 Broker 之间的数据均衡。

数据均衡

每个 Kakfa 实例由多个 Broker 组成。不同 Broker 之间的数据流量、磁盘占用率一致时，可以最大程度发挥 Kakfa 实例的性能。在部分场景中，Broker 之间的数据可能不均衡，例如 Broker 的分区数量差异较大，分区数较多的 Broker 可能业务流量大、磁盘占用率高，可能导致磁盘倾斜率较大。Kafka 实例规格以 Broker 性能的最大值为基准，在数据不均衡的场景中如果仅个别 Broker 达到当前规格的性能阈值，则可能触发限流，造成其他 Broker 资源浪费。

保障 Kafka 集群数据均衡

推荐通过以下方式保障 Kafka 集群数据均衡。

合理创建资源

Kafka 实例的每个 Topic 可以划分为多个分区，每个分区都是一个有序的队列，分区数量影响 Topic 承载业务流量的能力。创建 Topic 时需要指定分区数量，Kafka 实例会将分区尽可能均衡地划分给各个 Broker，每个 Broker 均负责集群中部分数据的处理和存储。
如果需要保证每个 Broker 的数据存储和数据处理相对均衡，创建 Topic 时，分区数量等参数设置需要满足以下规则：

规范数据写入方式

除了合理创建资源之外，还需要规范消息生产行为，尽可能保证数据的均衡性。建议生产者客户端在消息发送时使每个分区尽可能被公平的选择，例如消息发送时的分区选择使用轮询的方式。
本文档以 Confluent 官方客户端为例，说明分区选择对数据均衡的影响。

• 当发送的消息未手动指定写入分区编号且消息未指定消息 key 时，分区选择将会使用轮询的方式，此时消息写入基本可以保证数据处理和存储的相对均衡。
• 若消息指定了分区，则消息会写入用户指定的分区中，此时数据处理和存储是否均衡取决于用户指定分区时的策略。
• 若消息未指定分区，但是指定了消息 key，则分区选择会由消息 key 的哈希结果来决定，此时数据处理和存储是否均衡，取决于消息 key 得到的哈希结果是否均衡。