/tags/confluent/ Recent content in Confluent on Hugo -- gohugo.io en Mon, 30 Mar 2026 10:04:30 +0800 /posts/confluent-kafka-partition-count-evaluation/ Mon, 30 Mar 2026 10:04:30 +0800 /posts/confluent-kafka-partition-count-evaluation/ 背景 我们的项目使用 Confluent Cloud 托管 Kafka 集群，在上线前需要确定每个 topic 的分区（partition）数量。Kafka 的分区数只能增加不能减少，因此更适合在初始阶段先做一轮带假设前提的评估。 本文记录这一评估过程。 业务规模 基础数据 (单 Topic) 参数 数值 单 Topic 日均消息量 4 亿条 活跃用户数 ~200 万 人均日均交易笔数 200 笔 每笔交易产生消息数 1 条 Topic 数量 约 60 个 集群日均总消息量 约 240 亿条 单 Topic RPS 推导 单 Topic 全天平均 RPS = 4亿 ÷ 86,400秒 ≈ 4,630 交易流量并非均匀分布。假设流量集中在约 8 小时的活跃窗口内： 单 Topic 活跃时段平均 RPS = 4亿 ÷ (8 × 3,600秒) ≈ 13,900 活跃窗口内还存在早晚高峰，峰值通常为活跃时段均值的 2–3 倍： /posts/confluent-kafka-connection-count-spring-boot/ Thu, 12 Mar 2026 06:00:00 +0800 /posts/confluent-kafka-connection-count-spring-boot/ When selecting a Confluent Cloud plan, one of the first limits you’ll hit is the maximum connection count. Enterprise clusters allow 18,000 connections per eCKU (raised 4× in the Q3 2025 update); Standard cluster limits are lower — check the current cluster types table for the exact figure. Miscounting by even one component can push you into throttling territory. This post gives you a practical formula for estimating connections in a Spring Boot application, explains what actually drives that number, and ends with a worked example for a multi-service deployment.