AWS 消息服务
AWS 消息服务
消息和事件这块是搭解耦架构的地基。这里整理四个服务:SNS 做发布订阅、SQS 做队列、EventBridge 做事件总线、Pinpoint 做用户触达。SNS 广播一对多,SQS 缓冲一对一,EventBridge 按规则路由事件,Pinpoint 面向终端用户发消息。
发布订阅:Amazon SNS
完全托管的发布-订阅(Pub/Sub)消息服务,让应用、分布式系统和微服务通过主题(topic)把通知发到多个订阅终端,提高解耦性和可扩展性。
- 发布-订阅模型:发布者把消息发到主题,多个订阅者(email、SMS、HTTP/S 端点、Lambda、SQS 队列等)接收。支持一对多广播,可把消息同时投递到多个 SQS 队列,确保消息到达不同目标系统。
- 多协议支持:email、SMS、移动推送、HTTP/HTTPS、Lambda、SQS。
- 高扩展高可靠:自动扩展处理大量消息,高可用、低延迟。
- 消息过滤:订阅者按消息属性过滤,只收感兴趣的消息。
- 安全控制:IAM 策略控制发布订阅权限,支持加密传输和消息加密。
典型场景:事件驱动架构的异步通知、系统故障即时告警、消息广播给多个系统、移动推送、工作流任务触发协调。
队列:Amazon SQS
SQS 是托管消息队列,常和 SNS 搭配:SNS 广播到多个 SQS 队列,每个队列后面挂一组消费者缓冲处理。备考时两个点反复考——可见性超时和扩展客户端库。
可见性超时(Visibility Timeout)
消费者从队列拉取消息后,消息不会立即删除,而是进入不可见状态,这段时间就是可见性超时。超时结束前:
- 消息对其他消费者不可见;
- 如果原消费者没主动删除消息,超时后消息重新变可见,可能被其他消费者再次处理,导致重复处理。
一个考题:应用从 SQS 拉消息写入 RDS 后删除,但 RDS 偶尔出现重复记录,而队列本身没有重复消息。要保证消息只被处理一次,用 ChangeMessageVisibility API 调用增加可见性超时,让消息保持不可见的时间足够长,避免还没处理完就被其他实例重复拉取。
扩展客户端库(Extended Client Library)
SQS 单条消息上限 256KB。要处理更大的消息(比如最大 50MB),用 Amazon SQS Extended Client Library for Java:它自动把超过 256KB 的大消息存到 S3,SQS 消息里只保留 S3 引用,应用只需调用库方法,代码改动最少。
事件总线:Amazon EventBridge
无服务器事件总线服务,用来构建事件驱动架构(EDA),连接不同应用、服务和系统,实时路由和处理事件。
- 事件总线:中心总线接收、过滤、路由各种来源的事件,支持自定义总线、AWS 内置服务总线和合作伙伴总线。
- 多种事件源:AWS 服务(EC2、Lambda、S3、CloudTrail 等)、SaaS 供应商(Zendesk、Shopify 等)、自定义应用。
- 事件路由规则:基于事件内容(事件模式)定义路由,支持多条件组合匹配,把事件转发到不同目标。
- 多样目标:Lambda、Step Functions、SNS、SQS、Kinesis、API Gateway 等,支持批量和异步调用。
- 无服务器:完全托管,按事件量计费。
一个典型工作流:S3 上传新文件触发 PutObject 事件 → EventBridge 按规则把事件路由给 Lambda → Lambda 处理数据 → 处理结果通过 SNS 通知相关人员。
要注意 EventBridge 本身只负责捕获、过滤和转发事件,不具备编排复杂工作流的能力。工作流编排归 AWS Step Functions——它设计状态机,控制任务执行顺序、分支、重试和错误处理:
| EventBridge | Step Functions | |
|---|---|---|
| 主要职责 | 事件捕获与路由 | 工作流编排与状态管理 |
| 是否构建流程 | 否 | 是 |
| 适用场景 | 事件驱动架构、消息分发 | 复杂任务流程、步骤控制 |
| 常见组合 | 用事件触发启动 Step Functions | 管理多步骤数据处理和业务逻辑 |
两者常配合:EventBridge 在数据变化、新资源创建等时触发事件,把事件送到 Step Functions 启动工作流,Step Functions 再分多步调用 Lambda、Glue、ECS 完成复杂业务逻辑。
用户触达:Amazon Pinpoint
客户参与(Customer Engagement)服务,通过多渠道与终端用户做个性化沟通和营销活动管理。和前面三个面向系统间通信的服务不同,Pinpoint 直接面向终端用户。
- 多渠道发送:email、SMS、推送通知、语音电话。
- 用户细分:按属性、行为、地理位置精准分群。
- 自动化营销旅程(Journeys):见下。
- 实时分析:发送量、送达率、打开率、点击率等数据,用于优化效果。
- 活动管理:创建、管理、监控营销活动,控制发送时间和频率。
- 易集成:通过 SDK 和 API 接入移动应用、网站、后台。
旅程(Journey)
旅程是营销自动化工具,基于用户行为、属性或触发条件,设计一系列有逻辑的、多渠道的沟通步骤。关键特点:多触点多渠道、条件分支与决策点(按点击/打开/回复动态调整后续步骤)、行为触发(注册/购买/使用事件启动)、自动化与定时发送、数据驱动分群精准触达。
常见用法:新用户欢迎旅程(注册后发欢迎邮件,几天后推激励通知)、购物车放弃提醒(加购未付自动发提醒短信和优惠券)、用户流失挽回(一段时间无活跃触发激励内容)、促销活动通知(对不同用户群分渠道推个性化信息)。