如何选取 CKafka 副本数？
建议您创建 Topic 时选择2副本或3副本存储数据，保障数据可靠性。默认创建的 Topic 是2副本，如果业务需要更高的可用性，则可以指定选择3副本运行。如果 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副本。
Topic 创建失败怎么办？
已创建的所有 Topic 的分区数之和达到实例规格的分区数上限
建议对 Kafka 实例扩容，或者删除不需要的 Topic。
在删除 Topic 期间创建同名 Topic
Topic 删除是异步操作，下发删除指令后，系统会异步的删除该 Topic 的元数据。若在此期间创建同名 Topic，系统会提示 Topic 已经存在，届时请您稍后重试。这里需要等待1分钟左右，再进行重建操作。
Topic 已经存在集群当中
Topic 已经存在集群当中，创建重名的 Topic 就会提示 Topic 已经存在，建议重新设置 Topic 名称。
