Amazon Simple Queue Service （SQS） 在与云架构中的服务消息收发、排队和解耦相关的主题中发挥着关键作用。
- 知识点：亚马逊SQS是全托管消息队列服务，能让分布式应用或服务间解耦通信。常用于消息缓冲、任务处理、工作负载分配，可应对高吞吐量场景，还具备容错能力 。
- 注意事项：理解其在分布式架构里承担的“中间人”角色很关键，设计系统时，要精准定位哪些交互适合用SQS解耦。
以下是考试中可能出现的 SQS 相关主题和关键概念的细分：
1.SQS 概述
- 目的：SQS 是一项完全托管的消息队列服务，支持微服务、分布式系统和无服务器应用程序的解耦。
- 主要特点：
- 可扩展性：自动扩展以处理消息量。
- 可靠性： 确保使用重试策略传送消息（至少传送一次）。
- 安全性：支持对静态消息（使用 AWS KMS）和传输中消息进行加密。
- 成本：根据请求数量和负载大小收费。
- 队列类型：
- 标准队列：至少一次传输，吞吐量不受限制。
- FIFO 队列：先进先出传输、恰好一次消息处理。
2.SQS 中的队列类型
- 标准队列：
- 最适合吞吐量至关重要且消息顺序不严格的场景。
- 提供至少一次传递，并且消息可能会不按顺序传递。
- FIFO 队列：
- 保证消息按照发送的确切顺序（先进先出）进行处理。
- 支持恰好一次消息处理，并确保没有重复消息。
- 限制：单个 FIFO 队列每秒最多 300 个事务 （TPS），但这可以通过批处理来增加。
3.消息生命周期
- 发送：可以使用 AWS SDK、CLI 或 API 将消息发送到队列。
- 接收：使用者可以轮询队列中的消息。
- 可见性超时：检索到消息后，它在指定的持续时间内对其他使用者不可见。这可确保没有其他使用者处理同一消息。
- 消息保留期：SQS 消息的默认保留期为 4 天，您可以将保留期设置为 60 秒到 14 天。
- 死信队列 （DLQ）：无法成功处理的消息可以发送到死信队列。这允许您隔离有问题的消息以供以后调查。
- 延迟队列：您可以将消息的传送延迟可配置的时间。
4.安全功能
- 访问控制：使用 IAM 策略，您可以控制谁可以发送和接收消息。
-加密：- 服务器端加密 （SSE）：确保使用 AWS KMS 密钥对消息进行静态加密。
- 传输中加密：SQS 自动使用 TLS （SSL） 来保护传输中的数据。
5.与其他 AWS 服务集成
- Lambda 集成：当新消息到达队列时，SQS 可以触发 AWS Lambda 函数。这通常用于无服务器应用程序。
- SNS 到 SQS：SNS（简单通知服务）可以将消息发布到 SQS 队列，从而允许扇出消息传输。
- CloudWatch 监控：SQS 与 CloudWatch 集成以监控队列长度、消息使用时间和消息传输等指标。
- Amazon EC2 和 Auto Scaling：EC2 实例可以轮询 SQS 队列以处理消息。Auto Scaling 组可以配置为根据消息数量进行扩展。
6.SQS 最佳实践
- 消息批处理：您可以批量处理消息（每批最多 10 条消息，每批 256 KB）以降低成本并提高吞吐量。
- 长轮询：这允许您通过在返回响应之前等待消息到达（最多 20 秒）来降低持续轮询的成本。
- 错误处理和 DLQ：如果您的消费者无法处理消息，请使用 Dead Letter Queues 进行隔离和分析。
7.性能和可扩展性
- 吞吐量：标准队列提供无限的吞吐量;FIFO 队列具有吞吐量限制，但可以通过批处理来增加。
- 扩展：SQS 会自动扩展以满足需求，无需任何人工干预。
8.成本管理
- SQS 定价基于请求数量（每个发送、接收或删除操作）和传输的数据量。
9.SQS 和事件驱动型架构
- SQS 常用于事件驱动架构中，用于解耦服务。创建者将消息发送到队列，使用者异步处理它们。
10.故障 排除
- 您可能需要解决与失败的消息处理或消息传送相关的问题。使用 CloudWatch 指标和 DLQ 进行诊断。
11.SQS 的应用示例
-
用例识别：
- 选择何时使用 SQS 而不是 SNS 或 EventBridge 等其他服务。
- 使用 SQS 来解耦系统、提高可扩展性或减少组件之间的紧密耦合。
-
排队策略：
- 如何配置正确的队列类型（Standard 与 FIFO）。
- 处理消息处理失败（死信队列、可见性超时）。
-
安全和加密：
- 使用 IAM 角色和策略设置访问控制。
- 使用 AWS KMS 配置消息加密。
-
成本优化：
- 了解 SQS 的定价模型。
- 通过使用长轮询、消息批处理和减少请求数量等功能来优化成本。
- SQS队列类型：
- 知识点：有标准队列和FIFO队列。标准队列至少一次交付，尽力保证顺序；FIFO队列保证消息按发送顺序精确处理一次。
- 注意事项：对顺序敏感场景，如金融交易，必须选FIFO队列；若顺序不太重要，标准队列的高吞吐量优势更值得考虑。
- 队列配置：
- 知识点：可在创建或更新队列时，配置消息保留期，范围是60秒到14天。
- 注意事项：依据业务需求设保留期，太短可能丢失未处理消息，太长则增加存储成本。
- 死信队列（DLQ）：
- 知识点：捕获多次尝试后仍无法成功处理的消息，辅助故障排查与调试。需创建独立队列，在源队列配置 RedrivePolicy 。
- 注意事项：合理设置最大接收次数，避免正常的偶尔处理失败消息也进入DLQ；定期查看DLQ，清理不再需要的问题消息。
- 可见性超时：
- 知识点：处理中的消息超时时，会对其他消费者再次可见，可能导致重复处理。
- 注意事项：结合业务处理逻辑、性能，精准设置超时时间，过短易重复处理，过长则降低消息处理效率。
- 消息删除：
- 知识点：消息成功处理且执行 DeleteMessage API调用后，才从队列删除；未成功处理就会留存，直至成功或过期。
- 注意事项：处理完务必及时调用删除API，不然队列易堆积大量无效消息，增加成本与管理难度。
- 扩展和吞吐量：
- 知识点：标准队列吞吐量近乎无限，自动扩展；高容量应用可利用FIFO队列分片、多队列并行处理提升效率。
- 注意事项：预估业务量增长，提前规划好多队列、分片策略，避免后期重构。
- 与其他AWS服务集成：
- 知识点：能与Lambda借助事件源映射集成，消息入队自动触发函数；和SNS集成可在消息入队时推送通知。
- 注意事项：配置集成时，留意权限、数据格式，像Lambda函数入参需匹配SQS消息格式。
- 消息属性：
- 知识点：是附着在消息上的键值对，用于传递如数据类型、处理选项等元数据。
- 注意事项：别把核心业务数据放属性，只放辅助处理的额外信息，而且键名要有意义、规范。
- 长轮询：
- 知识点：开启后，队列等消息到达或长轮询超时才响应，减少空响应，降低成本。
- 注意事项：要权衡等待时间与业务实时性需求，对实时性高业务，不宜设太长等待时间。
- 安全与访问控制：
- 知识点：用IAM策略和SQS队列策略，控制特定IAM角色或用户对队列的访问权限。
- 注意事项：遵循最小权限原则，严谨设置策略，定期审计权限。
- 成本优化：
- 知识点：成本受请求次数、数据传输量、消息保留时长影响。
- 注意事项：监控成本指标，从上述因素找优化点，比如启用长轮询降请求次数。
- 消息处理最佳实践：
- 知识点：含使用多个消费者并行处理、合理设可见性超时、利用DLQ、开启长轮询。
- 注意事项：综合业务场景运用，不能盲目照搬，例如简单低负载场景，无需过多消费者。
- 事件驱动架构中的SQS：
- 知识点：在事件驱动架构里，SQS用于解耦组件，组件异步处理队列中的事件/消息，实现可扩展性、容错性。
- 注意事项：设计架构初期，梳理好各组件职责、交互流程，保证解耦合理，不然易出现架构混乱。