关注留言点赞，带你了解最流行的软件开发知识与最新科技行业趋势。
在本文中，了解 Amazon SQS 的工作原理以及如何使用它来创建分布式应用程序，探索 SQS 的组件及其架构。
什么是亚马逊 SQS？
Amazon SQS（简单队列服务）是一种消息队列服务，它使应用程序组件能够通过交换消息相互通信。这被广泛用于构建事件驱动系统或解耦AWS上的服务。
亚马逊 SQS 的特点
消息持久性：消息存储在队列中，直到它们被发送或接收端点传送或删除。有保证的消息传递：消息至少传递一次，并且与发送时的顺序相同。消息重新投递：如果一条消息未被确认，它将在从队列中删除之前重新发送最多3 次。可见性超时：消息可以设置为在设定的时间后过期和删除，即使它们尚未发送。
亚马逊 SQS 的优势
Amazon SQS 是一种高度可靠且可扩展的消息队列服务，使您能够可靠地连接您的应用程序。它提供以下好处：
拥有成本低：Amazon SQS 具有成本效益，因为它采用按使用付费的定价模式并且能够使用任何 AWS 服务。高吞吐量：每秒可处理超过100万条消息，延迟低于1 毫秒。容错：该服务被设计为具有高可用性和持久性，没有单点故障。安全性：Amazon SQS 在客户端之间发送消息时使用 TLS 和消息签名，以及访问服务的客户端的身份验证机制。
如何使用 SQS 以 FIFO 顺序处理消息
等等，队列不是应该设计成先进先出的吗？嗯，是的，但是对于 SQS，它变得有点复杂。AWS 声称他们已尽最大努力按顺序处理消息，但时不时会出现消息被不按顺序处理的情况。
SQS 具有具有大量冗余的分布式架构。这意味着有不止一个消息存储。在运行时，消息是从其中一个商店中随机选取的。
让我试着用一个类比来更好地解释这一点。假设一行三人去火车站售票柜台购票。他们决定站在三个不同的队列中，谁先拿到票，谁就会通知其他人，这样他们就可以从队列中出来——分布式和冗余。让我们假设所有三个队列在该实例中具有相同的人数。很巧的是，另一组三人几乎同时进入了车站。当他们分成三队时，第二组的一个人成功地超越了第一组，排在了其中一个队列的前面。轮到他们时，第二组的人比另一组先拿到票——这不是我们想要的，但有时会发生。
那么，出路何在？如果需要严格的 FIFO 顺序，AWS 建议使用 FIFO 队列。与标准 SQS 不同，FIFO SQS 保证严格排序。
打个比方，假设您走进一家银行并立即收到一个代币。代币持有者按顺序得到服务，排除了有人不按顺序得到服务的可能性。
如何处理消息？
标准 SQS 队列保证“至少一次”处理。这意味着消息不会丢失并且至少会被处理一次。但是“至少一次”应该是什么意思？这是否意味着可以多次处理消息？嗯，答案是肯定的。
让我们首先看一下消息生命周期。以下是阶段：
消息被放入队列。它被消费者捡起来。处理后，消费者将其从队列中删除。
注意：在后期处理中，消息不会自动删除——它必须由消费者明确删除。
在第2 阶段和第3 阶段之间，消息是“飞行中的”。当消息在传输中时，可见性超时开始发挥作用，它会抑制队列中的消息，使其不再被处理。可以配置可见性超时，默认值为30秒。这个想法是必须处理消息，然后在可见性超时到期之前从队列中删除消息，以避免重复处理。
但是，有时消息在处理过程中会卡住，导致可见性超时过期，消息会再次被消费者接收。此外，在删除过程中，其中一台服务器可能会脱机，并且消息会保留在该特定服务器上。当它恢复时，消息会被再次处理。因此，在使用标准 SQS 时，绝对有必要将应用程序设计为幂等的。也就是说，即使一条消息被处理了不止一次，也不应该对业务产生任何影响。
回到我们火车站的例子，让我们假设一旦一个团体中的一个人拿到了票，他就会给这个团体中的所有其他人发短信。但是，在发送文本时，如果其中一位接收者的手机掉线，则该人将收不到消息并会再次购买机票。这是一个消息可以被多次处理的常见场景。
另一方面，FIFO SQS 中的消息恰好被处理一次。这就引出了另一个重要的话题——如何处理重复的消息？标准 SQS 不关心您是否输入了重复的消息——下线应用程序应该是幂等的。
另一方面，FIFO 队列不允许重复。它创建一个重复数据删除 ID，它本质上是一个基于有效负载的哈希值。但是，如果必须在一个小的时间窗口内处理相同的消息：默认的重复数据删除 ID 将不起作用，并且必须创建一个自定义的随机重复数据删除 ID，并且将允许处理所有传入的消息，即使它恰好是与之前的一条消息相同。
您应该使用哪种类型的 SQS？
根据经验，您应该始终使用标准 SQS。它是分布式的、冗余的，并且具有无限的吞吐量。毕竟，它旨在相当轻松地扩展和服务所有类型的工作负载。但是，如果严格的顺序对于您正在构建的应用程序至关重要并且您不太关心吞吐量，那么显然，FIFO 将是您的最佳选择。