1. Introduction

  • 创建主题时，必须提供分区数partition count和复制因子replication factor；

  • 此两选项影响系统的performance和durability

  • 若分区数在主题生命周期topic lifecycle内增加，
    将破坏Key的排序保证break key ordering guarantee；

  • 若复制因子在主题生命周期内，则会给集群带来更大压力，
    可能因broker使用更多网络流量和额外空间而导致性能意外下降，请慎重；

AddingReplicaSpaceAddNetworkTraffic

  • 最好第一次就获得正确的分区数和复制因子；

2. Choose Partition Number

  • 选择分区数需考量点：

    • 从单个分区消费时我们期望达到的最大吞吐量(以MB/s为单位)是多少，根据环境测量；

    • 若根据Key向分区发送消息，稍后添加分区可能非常有挑战性，
      故请根据预期的未来使用情况来计算吞吐量throughput；

  • 拥有更多分区的优点：

    • 更好的并行性parallelism和吞吐量throughput，分区是并行性单位；

    • 使我们能在一个组中运行更多消费者以进行扩展，如有3个分区，
      则最多可以有3个消费者处于活动状态，其它消费者将保持不活动状态；

    • 若集群包含大量broker，则拥有更多分区将充分利用这些broker，如有2个分区的主题，
      则只能托管在两个broker上，其它broker将保持空闲状态，资源使用效率低下；

  • 分区多的缺点：

    • 每个分区都有一个partition leader，由Zookeeper选举产生，
      Zookeeper上的负载增加，增加leader election的时间；

    • 此问题在没Zookeeper的Kafka得到解决；

    • Kafka打开更多文件，可打开的文件数量与OS限制有关，尽管可在OS设置中更改为更高的值；

  • 权衡优缺点：

    • 若有少于6个broker的集群，请创建3倍broker的数量，即3X，
      其背后的原因是，随时间推移，若有更多broker，将有足够的分区来覆盖cover；

    • 若有超过12个broker的大集群，请创建2倍于broker的数量；

    • 若还需考虑一个族中以所需的峰值吞吐量peak throughput运行所需的消费者数量，
      如高峰时需20个消费者，则主题中至少需20个分区；

    • 若还需考虑生产者的吞吐量，若我们有一个高吞吐生产者，
      或若它未来几年会增加，请将分区数保持为broker数量的3倍；

  • 每个主题有大量分区是好的，但请不要选择像1000这样高得离谱的
    absurdly分区数，除非我们知道需要所有的这些分区；

3. Choose Replication Factor

  • 为提高可靠性reliability和容错性fault tolerance；

  • 分区的复制replication是必要的，注：主题复制不会增加消费者的并行性；

  • 复制因子选择权衡因素：

    • 应该至少为2，最大为4，建议数量为3，因它在性能和容错之间提供正确的平衡；

    • 且云提供商通常提供3个数据中心/可用性区域作为区域的一部分进行部署；
      data center/availability zone to deploy to as region part；

    • 具有更高复制因子的优势在于：为系统提供更好的弹性resilience；

    • 若复制因子为N，则若acks=0或acks=1或(N-min.insync.replicas)
      broker在不影响可用性的情况下可能失败；

  • 高复制因子的缺点：

    • 生产者经历更高的延迟，因若acks=all，则返回ack之前需将数据复制到所有replica broker；

    • 系统需更多的磁盘空间；

  • 权衡复制因子：
    ** 将其设置为3即可开始(必须至少3个broker)；

    • 若由于更高的复制因子而出现性能问题，则应获得更好的broker，而不是降低复制因子；

    • 生产中永远不要将其设置为1，这意味没有容错能力，若分区丢失，将丢失数据；

    • 查看acks机制和min.insync.replicas部分，权衡对复制因子的影响；

4. Cluster Guideline

  • Kafka集群大小权衡：

    • 由Zookeeper管理时，集群中的所有broker最多20w个分区，
      confluent仍建议每个代理最多4000个分区；

    • 因broker宕机，Zookeeper需进行大量leader election；
      此问题由无Zookeeper的KRaft模式下解决；

    • 若集群需超过20w个分区，请遵循Netflix模型创建更多的Kafka集群；