ZITADEL 通知处理机制的技术演进与实践

背景与挑战

在现代身份与访问管理系统中，通知服务（如短信验证码、邮件通知等）是用户交互的关键环节。ZITADEL 项目团队近期对其通知处理机制进行了重大改进，旨在解决原有架构中的性能瓶颈问题。

原有架构的问题

在原有实现中，ZITADEL 采用顺序处理模式处理通知事件。这种设计存在明显的局限性：

1. 处理延迟：事件必须按顺序处理，导致后续事件必须等待前一个事件处理完成
2. 扩展性差：无法充分利用系统资源进行并行处理
3. 缺乏弹性：没有完善的失败重试机制

新架构设计

核心思想

新架构引入了"通知聚合体"(Notification Aggregate)的概念，将通知处理分解为两个独立阶段：

1. 请求阶段：快速创建通知请求
2. 发送阶段：异步并行处理发送任务

事件流设计

新架构定义了以下关键事件类型：

• 请求事件：notification.(email|sms).requested
• 成功事件：notification.(email|sms).sent
• 失败事件：notification.(email|sms).attempt.failed
• 重试事件：notification.(email|sms).retry.requested
• 终止事件：包括放弃(abandoned)、取消(cancelled)等状态

组件分工

1. 通知生产者：

   • 监听原始事件(如code.added)
   • 创建初始的requested事件
   • 保持顺序处理模式确保事件顺序

2. 消息发送者：

   • 定期查询未处理的通知请求
   • 批量锁定待处理事件
   • 并行发送通知
   • 记录处理结果

关键技术实现

事件存储增强

为支持新架构，事件存储系统进行了以下改进：

1. 条件查询：支持"NOT IN"类型查询，便于查找未完成的通知
2. 行级锁定：使用PostgreSQL的行锁机制确保并发安全
3. 延迟处理：通过not_before_time字段支持延迟重试

重试与退避机制

系统实现了灵活的重试策略：

1. 基础延迟：首次失败后按固定间隔重试
2. 最大尝试次数：可配置的最大重试次数
3. 消息TTL：超时自动放弃处理
4. 未来扩展：计划支持指数退避等高级策略

系统配置

通知系统提供了丰富的配置选项：

Notification:
  MaxAttempts: 3                # 最大重试次数
  RetryDelay: 1s                # 重试基础延迟
  MessageTTL: 60s               # 消息生存时间
  Workers: 5                    # 并发工作线程数
  MaxInFlight: 100              # 最大并行处理数

优势与价值

新架构带来了显著改进：

1. 性能提升：通过并行处理大幅提高吞吐量
2. 可靠性增强：完善的失败处理机制提高送达率
3. 可观测性：丰富的事件类型便于监控和调试
4. 弹性扩展：可根据负载动态调整工作线程

总结

ZITADEL 的新通知处理机制通过解耦请求与发送、引入并行处理和弹性重试策略，有效解决了原有系统的性能瓶颈。这一改进不仅提升了用户体验，也为未来进一步优化通知服务奠定了坚实基础。