每天100亿消息，Kafka架构到底怎么设计？

消息中间件是大型架构核心，下面我详解每天100亿消息，Kafka架构如何设计？

每天100亿消息

每天100亿条消息，平均到全天约等于11.57万条/秒消息。

但系统设计绝不能只看平均值，真实业务通常有明显的峰谷差异，白天高峰可能是均值的5倍、10倍，甚至更高。

如果按照业务峰值是平均流量的5倍计算，集群至少要按照 58万条/秒 的写入能力规划，而不是仅仅满足11.57万条/秒。

假设平均每条消息1KB，那么每天的数据量就是约10TB级别。

再加上副本复制、日志保留、索引和网络开销，实际写入和存储需求会成倍放大。

Kafka集群到底怎么设计

这是最直接的方案：通过增加Broker数量、Topic分区和消费者并发，把吞吐能力横向铺开。

Kafka 的强项在于分区并行，因此集群规模的关键不是“单机多强”，而是“分区是否足够合理”。

Producer集群
      |
Kafka集群
  12～24个Broker
      |
Consumer Groups

每个Broker建议具备：

• 16核或更高CPU；

• 64 GB～256 GB内存，主要用于Page Cache；

• 10 GbE或更高速网络；

• 多块SSD，或者多磁盘JBOD；

• 独立磁盘目录配置；

• 3副本，跨机架分布。

这里的，副本机制是高可用设计的底座。

对于核心业务，副本数一般至少设置为3，以保证任意单机故障后仍可服务。

但副本数越多，写放大越明显，成本也越高，所以需要分级治理。

对极关键主题，可以采用 3 副本并开启较严格的确认机制。

对非核心主题，则可以根据业务容忍度适当降低成本。

此外，磁盘与网络是决定性能上限的关键。

Kafka 依赖顺序写，因此 SSD 或高性能云盘通常更适合高吞吐场景。

以上