其他
微服务失败重试(2)AWS 消息服务选型对照表
目前开源和 AWS 原生的消息中间件特别丰富,客户常常不知道如何如何选择,本文整理了一张表,具体应用场景可以对照来看哪个是最适合消息系统;对于应用依赖的关键特性建议再对照官方文档和咨询原厂技术人员。
特性 | Amazon SQS | Amazon SNS | Amazon MQ | Amazon EventBridge |
Release Date 发布日期 | 2006.07 | 2010.04 | 2017.10 | 2019.07(由CloudWatch Event 演进而来) |
Entity Type 消息机制 | Queue (Similar to JMS) 消息队列服务 | Topic (Pub/Sub system) 发布订阅 | Managed Service for Apache ActiveMQ | JSON 消息 规则订阅 |
Message Consumption 消费机制 | Pull Mechanism 轮询 | Push Mechanism 推送 | JMS, NMS, AMQP, STOMP, MQTT, and WebSocket. Point-to-point (message queues), publish-subscribe(topics), request/reply, persistent and non-persistent modes, JMS transactions, and distributed (XA) transactions | Push Mechanism 推送 |
Persistence 持久化 | 消息保存在跨可用区分布式存储,最多保存14天 Messages per queue (backlog) = Unlimited Storage 无限 Messages per queue (in flight) = Max 120,000 Msg, FIFO Max 20,000 Msg (读取但未删除的消息数) Messages per queue (in memory) = FIFO Max 20,000 Msg | SNS provides durable storage of all messages that it receives. 也提供了跨可用区的持久存储 | 支持:非持久模式/快速使用者/批处理事务 Multiple Availability Zones (AZs) redundantly stored 多可用区冗余存储 99.999999999% (eleven 9’s) message durability 11个9持久性 | SLA 99.99% |
Types of Supporting Endpoints 支持的消息消费者服务或协议 | 您可以将 Amazon SQS 与 Amazon EC2、Amazon EC2 Container Service (Amazon ECS) 和 AWS Lambda 等计算服务以及 Amazon Simple Storage Service (Amazon S3) 和 Amazon DynamoDB 等存储和数据库服务结合使用,从而让应用程序具有更高的灵活性和可扩展性 | 6 种类型的目标:“HTTP”, “HTTPS” | ”Email”, “Email-JSON” | “SQS” | "SMS" | Mobile Push Notifications | Lambda Function | 各种消息协议的客户端 | 有 90 多项 AWS 服务可以用作 EventBridge 的事件源 有超过 15 项 AWS 服务可以用作 EventBridge 的事件目标,其中包括 AWS Lambda、Amazon SQS、Amazon SNS、Amazon Kinesis Streams 和 Amazon Kinesis Firehose |
Max Message Size 消息大小 | 256KB文本(支持引用S3对象的消息最大2GB) | 256KB (Except for SMS Message) | 可配置,100KB 上下,持久性存储的延迟和吞吐对性能有影响 | 256KB(Reqest 大小) |
Delivery Reliability 消息传输的可靠性 | 延迟 0 ~ 15 秒 标准队列至少一次 FIFO 仅一次 支持长轮询(默认20秒,避免空消息) | 典型延迟不超过 30 毫秒 Most time exactly once to subscribers. 大多数情况仅一次 Msg Orders best efforts to match publisher orders 最大程度保持顺序 A automatically retry patterns (linear, geometric, exponential backoff) 自动重试机制 | 取决于消息大小,实例大小和存储特性 | 典型时延半秒 |
Retry Pattern Example 如何处理失败重试 | 死信队列保存“毒丸”消息 | SQS (subscribing endpoint): If a SQS queue is not available, SNS will retry 10 times immediately, then 100,000 times every 20 seconds for a total of 100,010 attempts over more than 23 days before the message is discarded from SNS. (1)立刻重试10次(2)每隔20秒重试一次,总计不超过10,000次 (可最多持续23天) Lambda: If Lambda is not available, SNS will retry 2 times at 1 seconds apart, then 10 times exponentially backing off from 1 seconds to 20 minutes and finally 38 times every 20 minutes for a total 50 attempts over more than 13 hours before the message is discarded from SNS. (1)每隔1秒钟,重试一次,总共2次(2)接着随机在1分钟~20分钟选一个时间间隔重试不超过20次(3)每隔20分钟再重试38次;总共50次尝试,持续最长12个小时的重试尝试。 | 支持自定义重传策略和死信队列 | 支持失败自动重试,最长事件消息保留24小时左右 默认重试策略,利用指数退避算法,最多重试次数在185次左右 |
API Limits API 调用限制 | 标准 队列每个 API 操作支持接近无限的每秒事务数 (TPS) | 订阅筛选策略 -200 每个账户 发布 - 300次/秒 ~ 30000次/秒(不同区域不一样) | Connections per wire-level protocol:1,000 (100 for mq.t2.micro brokers) 每个代理用于其他实例类型的存储容量200GB, mq.t2.micro 代理的存储容量 20GB每个代理250用户 每个用户20组 | PutEvents - 400 次/秒(可提升);其他50次/秒 目标触发调用 - 750次/秒 每个规则最多5个目标 |
Message Filtering 消息过滤能力 | 不适合 | Filter Policy based on Message Attributes, for SQS subscribing endpoint, a max 10 name-type-value allowed | 支持 | Amazon EventBridge 使用基于 JSON 并且明确的事件结构,让您能够创建应用于整个事件正文的规则,以便选择要发送到目标的事件。 |
Message Delivery Status 消息传递状态 | 不适合 | Support Logging delivery status to cloudwatch logs | 不适合 | 不适合 |
Pricing Model 价格模型 | Lightweight, fully managed 轻量级纯托管 Amazon SQS 的费用按请求数计算,再加上从 Amazon SQS 传出数据的数据传输费 (传输到同一区域内的 Amazon EC2 实例或 AWS Lambda 函数的数据除外)。 | Lightweight, fully managed 轻量级纯托管 Publishes by 1 million request units 每100万个发布消息 Notification Delivery (No charges for SQS & Lambda Functions) 消息通知(对于 SQS 和 Labmda 函数免费) Data Transfer Out of SNS ( Free between EC2 & SNS within the same region) 数据传出SNS(EC2 和 SNS 同一个区域免费) | Per Broker Instance(EC2) 每个实例 Per storage (GB-month) 存储(GB月) | 每100万个发布事件 |
Common User Scenarios 常见用户场景 | 适用于微服务、分布式系统和无服务器应用程序的完全托管的消息队列;Amazon SQS 可以大规模处理工作,每天处理数十亿条消息。 | SNS + SQS to build 1:N system compontents architecture Mobile Device & Applications notifications | Industry-standard APIs and protocols | Amazon EventBridge 是直接与第三方 SaaS 合作伙伴集成的唯一一种基于事件的服务构建的应用程序需要对来自 SaaS 应用程序和/或 AWS 服务的事件做出反应,建议您使用 Amazon EventBridge |
“微服务失败重试”系列展望:
AWS 消息服务选型和对比(本篇)
AWS Lambda 函数的错误处理和重试机制
近期原创: