如何选取 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副本。
