千万级Push链路演进之路

背景：该业务场景常见于促销活动通知，有时候运营配置某些活动后，要全量的通知给用户。在该项目中，push通知链路共有三个阶段，伴随用户量和业务复杂度的上升，不断地对该链路进行优化。

阶段一：初期，滚动拉取用户数据，采用线程池或for循环，调用推送接口。进行模板组装和SDK调用

瓶颈：

• 性能效率方面：
  • 资源占用高：若用for循环调用推送接口，需依次处理每个用户，用户量大时耗时久，易引发系统长时间资源占用，拖慢其他业务。
  • 吞吐量受限：线程池若线程数设置不合理，或无有效任务队列、拒绝策略，高并发下会线程竞争、任务积压，降低推送吞吐量，无法及时触达大量用户。
• 稳定性与可靠性方面：
  • 异常影响范围大：滚动拉取用户和循环推送中，单个用户处理出错，若未妥善隔离，可能让整个循环中断或影响其他用户处理，降低推送成功率与系统稳定性。
  • 缺乏容灾重试：未对失败推送任务有效重试、降级，遇到网络抖动等临时问题，会大量丢失推送，影响活动触达效果，且难定位恢复故障。
• 业务灵活性与扩展性方面：
  • 耦合度高：模板组装、SDK 调用和用户拉取推送流程耦合，后续要换推送 SDK 或改模板，需改动大量代码，增加维护成本与升级风险。
  • 难适配复杂场景：业务复杂后，如按用户分层、分时段推送，现有简单循环难扩展，要大改流程才能支持，限制业务创新优化。

阶段二：引入mq和模块划分

成效：

• 性能效率方面
  • 提高并发处理能力：引入 MQ 集群，通过 MQ 分区和多消费节点实现了并发消费。相比阶段一单纯使用线程池或 for 循环依次处理用户，并发消费能同时处理多个推送任务，大大提高了 push 的时效性，减少了整体推送耗时，能够更好地应对大量用户的推送需求 ，提升了系统的吞吐量。
  • 资源利用更合理：运营服务和推送服务职责分离，使得各自可以根据业务特点进行针对性的资源配置和优化。例如，运营服务专注于活动创建和用户数据查询，推送服务专注于消息组装和推送，避免了阶段一中因功能耦合导致的资源过度占用和相互影响，提高了系统资源的利用效率。
• 稳定性与可靠性方面
  • 解耦降低风险：MQ 解耦了运营服务与推送服务，使得一个服务出现问题时，不容易影响到另一个服务。比如运营服务在创建活动或查询用户数据时遇到短暂的性能问题，不会直接导致推送服务的阻塞或中断，降低了单个服务故障对整个推送链路的影响范围，提高了系统的稳定性。
  • 失败重试机制：MQ 具备消息持久化和重试机制，对于推送失败的消息可以进行重新投递和处理，一定程度上解决了阶段一中缺乏有效容灾重试的问题，提高了消息推送的成功率和可靠性。
• 业务灵活性与扩展性方面
  • 配置化管理：提供活动配置、推送模板配置等能力，代码可以根据配置信息动态进行推送渠道选择和模板内容构建。这使得在面对不同类型的促销活动或者业务需求变化时，无需修改大量代码，只需要调整配置即可，提高了业务的灵活性和可维护性。
  • 抽象工厂模式：推送服务根据消息推送类型选择对应的组件工厂进行消息组装，采用抽象工厂模式实现了推送组件的可插拔性。当需要新增推送渠道（如增加新的 APP 推送方式或新的短信供应商）时，只需要扩展对应的组件工厂和推送组件，而无需修改其他部分的代码，降低了代码耦合度，增强了系统的扩展性。

但这种升级后仍存在瓶颈：

• 推送效率与资源利用问题：虽用 MQ 解耦和多消费节点，但用户数据处理和推送未充分利用分批（Batch）处理与多节点并行拆分。面对千万级用户，若单节点线性处理，即使多消费节点，整体推送仍慢；且未对用户任务合理拆分合并，网络请求、线程创建等资源开销大，影响推送时效性与资源利用率。
• 幂等性保障不足：未明确对推送幂等性的处理（如重复推送问题）。若 MQ 消息重试、消费异常等，可能导致同一用户重复接收推送，影响用户体验，也增加系统无效处理压力。
• 任务拆分与并行度不足：对大规模用户推送，未将用户任务精细拆分为小批次（如按用户 ID 区间拆分），也未充分利用多节点并行消费。当用户量激增，单节点或少量节点处理易出现任务积压，拖慢整体推送进度。

 最终版本：以40w用户举例，实际可以支持千万级用户pus

优势：

• 效率与资源优化：
  • 任务拆分与 Batch 处理：通过 “活动消费者拆分用户 ID 区间任务（1000 个用户为 1 个任务，再拆 100 个为 1 个 list ）” + “线程池 + MQ 的 batch 消息”，大幅减少网络请求次数。比如 1k 数据，原单条推送需 10s，Batch 处理仅需 100ms ，提升推送效率。
  • 多节点并行：用户提取消费者多个节点并行，结合节点多线程（如 4C8G 机器 30 线程），将推送耗时从阶段二的高耗时，优化到分钟级，极大提升并发处理能力与时效性。
• 幂等性保障：引入 Redis 判断是否发送过，推送成功更新 Redis ，避免同一用户重复推送，解决阶段二可能的重复推送问题，保证推送幂等性，减少无效处理，提升系统可靠性与用户体验。
• 任务流程精细化：细化推送流程各环节（从活动创建发 MQ ，到活动消费者拆分任务、用户提取消费者分批处理，再到推送服务消费者线程池处理），通过 “获取最大用户 ID → 拆分区间 → Batch 处理 → 多节点并行”，让大规模用户推送任务分配更合理，充分利用资源，适配高并发场景。

最后，此版本以可满足当时项目的用户体量和时效要求