type
status
date
slug
summary
tags
category
icon
password
有三种类型的notification sys
push sms email
一般透过3rd party services
Notification servers: They provide the following functionalities:
• Provide APIs for services to send notifications. Those APIs are only accessible internally
or by verified clients to prevent spams.
• Carry out basic validations to verify emails, phone numbers, etc.
• Query the database or cache to fetch data needed to render a notification.
• Put notification data to message queues for parallel processing.
Reliablity:
data loss:
receive a notification once?
完全正确！Event ID是解决"恰好一次"问题的核心概念。
什么是Event ID？
Event ID就是事件的全局唯一标识符，它确保：
- 同一个业务事件，无论被处理多少次，都有相同的ID
- 不同的业务事件，即使内容相似，也有不同的ID
类比：
就像身份证号码一样，每个人（事件）都有唯一的号码，即使有重名（相似内容），身份证号也不会重复。
🔧 Event ID的设计策略
1. 业务语义化ID
构成要素：
优势：
- 可读性强，容易理解和调试
- 包含业务语义，便于排查问题
- 自然去重，相同业务事件ID相同
2. 组合哈希ID
当业务信息太长时：
📊 Event ID在通知系统中的生命周期
1. 事件产生阶段
业务系统生成Event ID：
2. 通知处理阶段
通知服务使用Event ID：
3. 去重记录阶段
持久化已处理的Event ID：
🔄 不同场景下的Event ID策略
1. 重试场景
网络超时重试：
2. 多实例并发场景
多个通知服务实例同时处理相同事件：
3. 延迟处理场景
延迟队列中的事件：
🎯 Event ID的高级应用
1. 事件溯源（Event Sourcing）
完整的事件历史：
2. 业务幂等性保证
基于Event ID的业务幂等：
3. 跨系统一致性
多个系统使用相同Event ID：
💾 Event ID的存储和管理
1. 存储策略
Redis + 数据库双写：
2. 数据清理
过期数据清理：
3. 性能优化
批量查询优化：
⚠️ Event ID设计的注意事项
1. ID冲突问题
避免意外冲突：
2. ID长度平衡
可读性 vs 存储效率：
💡 核心总结
Event ID是通知系统"恰好一次"的关键：
- 唯一标识：每个业务事件都有全局唯一的ID
- 天然去重：相同事件ID只处理一次
- 业务语义：ID包含足够的业务信息
- 系统一致性：多个系统使用相同Event ID保证一致性
- 可追溯性：完整记录事件处理历史
设计原则：
- 业务导向：ID要反映真实的业务事件
- 全局唯一：跨系统、跨时间都不重复
- 信息充分：包含足够的上下文信息
- 格式一致：团队内统一ID生成规则
需要retry？
通知系统需要重试的根本原因：
- 分布式系统天然不可靠：网络、服务、依赖都可能失败
- 外部依赖不可控：第三方推送平台、邮件服务等有自己的限制
- 用户体验要求：用户期望收到所有重要通知
- 业务连续性：通知失败可能影响业务流程
- 成本效益：自动重试比人工处理更经济
保持幂等性
问题场景：
- 第一次发送推送请求
- 推送平台收到并处理成功
- 但响应在网络中丢失
- 通知服务以为失败，重试发送
- 用户收到两次相同推送
解决方案：使用Event ID确保幂等性
- 每次重试使用相同的Event ID
- 推送平台根据Event ID去重
- 即使重试多次，用户只收到一次推送