kafka topic 设计需兼顾命名语义、分区匹配负载、副本权衡可靠与成本、生命周期统一治理：命名用小写短横线格式并带领域前缀；分区数按峰值吞吐与消费者数预估，避免超200；生产环境副本设为3，清理策略依日志/状态类型选delete或compact；所有topic须注册cmdb并禁用手动删除。
Kafka 的 Topic 不是随便起个名字、设几个分区就完事的。它直接决定消息流转效率、系统可维护性，甚至影响业务一致性。设计得当，能支撑高吞吐、低延迟和长期演进；设计随意，后期扩容难、排查乱、迁移苦。
Topic 命名需清晰表达业务语义
命名不是技术问题，而是协作问题。一个好名字能让开发、运维、数据团队一眼看懂用途，避免误用或重复创建。
- 采用小写字母+短横线（kebab-case）格式，如 user-login-event、order-payment-result，禁用下划线或大驼峰
- 前缀体现领域或系统，例如 pay-、log-、iot-，便于集群级归类和权限控制
- 避免泛义词如 data、message、info；不加版本号（如 user-v2），版本应通过 Schema Registry 管理，而非 Topic 名
- 敏感业务建议加环境标识（仅限非生产环境），如 dev-order-confirmed，但生产环境一律去掉
分区数（Partitions）要匹配真实负载
分区数不是越大越好，也不是越小越省事。它直接影响消费者并发能力、重平衡开销和磁盘碎片程度。
- 预估峰值每秒写入量（TPS）和单条消息大小，按单分区 10–20 MB/s 吞吐反推最小分区数。例如：峰值 50 MB/s → 至少 3–5 个分区
- 考虑消费者组内最大并发消费者数，分区数 ≥ 消费者实例数（否则有消费者空闲）
- 避免过度分区：单 Topic 超过 200 分区会显著增加 ZooKeeper/KRaft 元数据压力和 Leader 选举复杂度
- 分区数支持在线增加，但不能减少；初期宁可略保守，后续按需扩容
副本与存储策略须兼顾可靠性与成本
副本不是“越多越稳”，而是要在可用性、写入延迟和磁盘开销之间找平衡点。
- 生产环境推荐 replication-factor=3：容忍单节点故障，满足多数一致性场景（如 ISR 数 ≥ 2 即可提交）
- 保留策略优先按时间（retention.ms），而非大小（retention.bytes），便于容量规划和合规审计
- 日志型 Topic（如访问日志）设为 cleanup.policy=delete，默认保留 7 天；状态型 Topic（如用户最新配置）设为 cleanup.policy=compact，配合 Key 使用
- 禁用 unclean.leader.election.enable=true，防止数据丢失——即使所有 Follower 都落后，也不应让非 ISR 成员成为 Leader
Topic 生命周期应纳入统一治理
Topic 是资源，不是一次性的配置。放任自流会导致僵尸 Topic 泛滥、配额超限、监控盲区。
- 所有 Topic 必须在 CMDB 或元数据中心注册，标注负责人、业务方、预期生命周期、SLA 要求
- 设置自动清理机制：非生产 Topic 超过 90 天无读写活动，触发告警；超过 180 天自动冻结并通知 owner
- 禁止手动执行
kafka-topics.sh --delete（Kafka 2.5+ 默认关闭），删除必须走审批流程 + 导出备份 + 确认下游无订阅 - 关键 Topic 开启 JMX 监控：关注 UnderReplicatedPartitions、ActiveControllerCount、RequestHandlerAvgIdlePercent 等核心指标
