如何选取 CKafka 副本数?
建议您创建 Topic 时选择2副本或3副本存储数据,保障数据可靠性。默认创建的 Topic 是2副本,如果业务需要更高的可用性,则可以指定选择3副本运行。如果 Topic 需要更多的副本数,可以 提交工单 进行处理。新建 Topic 时副本选择方式如下图所示。 为了提高数据的安全性,当前 CKafka 已经禁止单副本 Topic 的创建,如您账户下有单副本的 Topic,建议按如下步骤迁移:
1. 创建新的 Topic,选择相同的分区,选取双副本。
2. 生产消息到新的 Topic 中,存量的单副本 Topic 继续被消费。
3. 消费完毕后修改消费者配置,订阅新的 Topic 进行消费。
为什么设置了 Topic 消息保留的时间,在其设置的时间点之后仍然可以查询到消息?
1. 消息中增加了一个时间戳字段和时间戳类型。目前支持的时间戳类型有两种:CreateTime 和 LogAppendTime 前者表示生产者创建这条消息的时间; 后者表示 broker 接收到这条消息的时间。如果客户端生产消息时间的时间戳数据不合法,会影响 broker 服务端删除数据。
2. 主题中分区数过多,消息数据过少,且分区内只存在一个日志段文件,则不会删除消息。
3. 日志删除任务会检查当前日志的大小是否超过设定的阈值,即每个分段1GB大小。若日志段中最大的时间戳数据在保留的时间内则不会删除消息。
为什么 Topic 数量(分区总数)存在限制?
Kafka 的 Topic 总数(分区总数)太多会使集群性能和稳定性下降。
因为单机可承载的分区数是有限度的,如果需要更多的分区那么就需要添加节点,需要更多的成本投入。Kafka 的存储和协调机制是以分区为粒度的,分区数太多,会导致存储碎片化严重,单机层面的随机写增多,集群层面分区 Leader 切换效率降低,Controller 节点故障切换变慢等情况。导致集群性能和稳定性下降。
Topic 数量和分区数量有什么关系?
CKafka 以分区(partition)作为分配单位。
总分区数 = TopicA × 副本数 + TopicB × 副本数 + ...... + TopicN × 副本数。
即副本数也算在总分区个数里面,例如客户创建了1个 Topic、6个分区、2个副本,那么分区额度一共用了1 × 6 × 2 = 12个。
分区数:一个物理上分区的概念,一个 Topic 可以包含一个或者多个 partition。
副本数:partition 的副本个数,用于保障 partition 的高可用,为保障数据可靠性,当前不支持创建单副本 Topic,默认开启2副本。
本页内容是否解决了您的问题?