基于Spring Boot+Kafka的10万用户级通知服务架构方案咨询

现有方案的可取之处 #

• 架构拆分思路合理：采用Spring Boot独立微服务承载通知逻辑、用Kafka做通知消息解耦的设计，匹配团队现有技术栈，和主站业务边界清晰，能够支撑10万级用户的基础需求
• 核心功能点无遗漏：覆盖了提醒增删改、双渠道触达、离线未读通知留存的核心需求，基础接口/add、/update、/delete的设计符合常规CRUD逻辑

现有方案的明显缺陷 #

• 定时轮询机制存在性能与精度的双重问题：Quartz每分钟轮询数据库拉取未来1分钟待触发提醒的设计，一方面在提醒量级上涨后会产生高频全表扫描，给数据库带来持续的线性压力；另一方面轮询粒度为分钟级，提醒触发最大延迟接近1分钟，用户感知差
• 消息投递链路存在冗余故障点：将批量发送逻辑封装为/sendHTTP接口供定时任务调用，多了一层不必要的网络跳转，一旦接口超时、鉴权异常就会直接导致提醒漏发，链路可靠性差
• 投递逻辑缺失状态判断：方案仅设计了两个Kafka主题分别承接邮件、UI通知，没有做用户在线/离线状态的路由，不管用户是否在线都推送实时UI通知，会产生大量无效消息，浪费Kafka与长连接资源
• 功能未形成闭环：没有对应用户离线后下次登录拉取未读通知的实现设计，需求没有完全落地

优化后实现路径（完全适配现有Spring Boot+Kafka技术栈，无额外组件引入） #

• 优化定时触发逻辑：替换原有的分钟级全表轮询，采用本地时间轮+增量预加载机制：服务启动时将未来1小时内的待触发提醒按时间分片加载到服务内存的时间轮中，后台线程每10秒做一次增量同步，仅查询新增、变更的落在未来1小时窗口内的提醒，无需每分钟扫表，触发精度可以提升到秒级，数据库查询压力降低90%以上
• 简化消息投递链路：移除独立的/sendHTTP接口，提醒触发逻辑直接在通知微服务内部完成，到点的提醒直接组装消息发布到Kafka，砍掉不必要的HTTP调用环节，减少故障点
• 拆分双渠道投递逻辑：
  • 邮件渠道：单独创建notify-emailKafka主题与对应消费组，消费到提醒消息后直接调用邮件服务发送，配置3次失败重试，重试失败的消息进入死信队列做人工兜底，该流程不受用户在线状态影响
  • 站内通知渠道：用轻量缓存维护用户在线状态（仅存储用户近10分钟的长连接标识即可，10万用户内存占用不到100MB），触发提醒时先判断用户状态：用户在线的情况下，将消息推送到notify-ui-realtime主题，由长连接服务实时推送给前端；用户离线的情况下，直接将通知写入未读通知表，不推送实时消息，等用户下次登录时，直接从未读表拉取全量未读通知即可，无需在消息队列中留存离线消息
• 解决数据一致性问题：新增、更新、删除未触发的提醒时，除了写入数据库，同时发送一条提醒变更事件到Kafka，所有服务节点消费到变更事件后，同步更新本地时间轮中的对应提醒数据，避免出现“用户已经删除提醒但节点本地时间轮仍留存旧数据导致误发”的问题
• 容量适配参考：针对10万终端用户的规模，Kafka通知相关主题配置3个分区、消费组部署3个服务实例即可完全承载流量，无需过度设计

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