基于Apache Kafka与Spring Boot的通知系统架构及优化咨询

1. 现有架构是否合理？ #

现有架构存在几个明显的不合理点：

• 每个用户一个消费者的设计完全不可行：用户量一旦增长到几万、几十万级别，消费者实例会爆炸式增长，直接耗尽服务器资源，而且Kafka本身也不支持这种规模的消费者数量。
• 存在数据一致性风险：先写notification表再发Kafka消息，或者顺序反过来，都可能出现不一致情况——比如写表成功但消息发送失败，用户收不到通知；或者消息发出去了但写表失败，消费者拿到消息后查不到对应数据。
• 消息内容过于单薄：只发送“收到通知”这类消息，消费者拿到后还得额外查询数据库获取具体通知内容，增加了系统延迟和复杂度。

2. 空闲生产者数量、Broker配置、扩容系数相关问题 #

• 空闲生产者数量：如果你的生产者是随请求创建（每个评论请求新建一个Kafka生产者实例），那空闲生产者会非常多，这是严重错误的用法——Kafka生产者是线程安全的，应该在Spring Boot中配置全局复用的生产者实例，这种情况下不存在“空闲生产者”的问题，只会有少量（和服务实例数一致）生产者保持连接，闲置时资源占用极低。
• Broker配置数量：初期中小规模场景（日活10万以内，每秒几百条消息），3个Broker足够——满足Kafka高可用要求（副本数设为3，单个Broker故障不影响服务）。大规模场景则按吞吐量、存储需求估算：比如单台Broker可承载每秒1-2万条消息，根据峰值QPS计算所需Broker数量。
• 扩容系数：一般遵循“资源使用率达70%左右时扩容”的原则，比如Broker的CPU、内存、磁盘使用率长期超过70%，就考虑新增节点。另外要提前规划分区数，分区数建议设为Broker数的整数倍（比如3个Broker对应6或9个分区），后续扩容Broker时可重新分配分区，避免热点问题。

3. 架构不稳定的最优解决方法 #

针对现有问题，最优优化方案如下：

• 重构消费者架构：放弃“每个用户一个消费者”的设计，改用消费者组+用户ID哈希分区的模式：
  • 创建通知主题，设置合适的分区数（3-10个，根据用户量调整）。
  • 启动固定数量的消费者实例（3-5个，根据服务器资源调整），全部加入同一个消费者组。
  • 发送消息时将用户ID作为消息key，Kafka会根据key哈希值将消息分配到固定分区，同一个用户的通知会被同一个消费者处理，消费者处理后可通过WebSocket推送给用户，或存入Redis供客户端拉取。
• 解决数据一致性问题：
  • 方案一：使用Spring Kafka事务功能，将写数据库和发Kafka消息纳入同一个事务，确保操作要么全部成功要么全部回滚。
  • 方案二：采用CDC（变更数据捕获）工具（如Debezium），监听notification表的新增数据，自动将变更同步到Kafka，避免手动发消息的一致性隐患。
• 优化消息内容：将通知完整信息（评论内容、用户昵称、时间等）放入Kafka消息中，消费者拿到消息后直接可推送给用户，无需额外查询数据库。
• 强化消息可靠性：生产者开启acks=all，确保消息被所有副本确认；设置合理的重试次数和间隔；消费者开启手动提交偏移量，确保消息处理完成后再提交，避免消息丢失。

内容的提问来源于stack exchange，提问作者sandesh a