mazon Simple Queue Service (SQS)是一种完全托管的消息队列服务，可以让你分离和扩展微服务、分布式系统和无服务应用程序。
在讲解SQS之前，首先让我们了解一下什么是消息队列。
消息队列
还是举一个电商的例子，一个用户在电商网站下单后付款后，应用服务器马上查询/更新数据库，连接支付网关并查询支付状态，通知短信/邮件网关发送相关短信/邮件，更新库存系统，更新物流系统……最后返回信息给用户，“您的下单已成功”。
但是如果网站的访问数很大，或者正值促销活动（比如淘宝双11，京东618）呢？
这个时候每一个流程都是一个瓶颈，一旦某一个地方达到了瓶颈或者出现故障，又或者用户下单的时间比程序处理订单的时间还要久的情况下，都会让用户得不到成功下单的结果，或者得到结果的时间非常长，导致用户体验不好。
这个时候，我们就要考虑到应用程序的解耦（decouple）。
我们可以引入消息队列，让不同的应用程序之间打断强连接的关系，互不干扰。
应用服务器在接收到用户付款的订单之后，就把相关的信息丢到消息队列，并且返回用户“您的下单已成功，请稍后查看详细订单状态”。
而支付网关、短信/邮件网关、库存系统、物流系统等等可以到消息队列里面拉取信息，并且进行相关的数据更新和操作。
这些操作可能不需要是实时的，但是至少能保证这些队列里的信息最终都会被执行。比如下单后我不一定马上能收到短信/邮件的通知，我可能5分钟/10分钟之后才收到这些信息通知，但这个并不影响正常的业务。
这样子，消息队列就起到了连接上层业务和下层业务的作用。
Amazon SQS相当于提供了一个分布式、高可用、高性能的消息队列服务。
SQS特点
SQS有两种不同类型的队列，它们分别是：
- 标准队列（Standard Queue）
- FIFO队列（先进先出队列）
标准队列
标准队列拥有无限的吞吐量，所有消息都会至少传递一次，并且它会尽最大努力进行排序。
标准队列是默认的队列类型。
FIFO队列
FIFO (First-in-first-out)队列在不使用批处理的情况下，最多支持300TPS（每秒300个发送、接受或删除操作）。
在队列中的消息都只会不多不少地被处理一次。
FIFO队列严格保持消息的发送和接收顺序。
更多关于标准队列和FIFO队列的区别，可以查看我需要哪种类型的队列？
SQS的其他特点
- SQS是靠应用程序去拉取的，而不能主动推送给应用程序，推送服务我们使用SNS（Simple Notification Service）
- 消息会以256 KB的大小存放
- 消息会在队列中保存1分钟~14天，默认时间是4天
- 可见性超时（Visibility Timeout）
- 标准SQS队列保证了每一个在队列内的消息都至少会被处理一次
- 长轮询（Long Polling）
Amazon SQS 延迟队列
延迟队列可让您将针对使用者的新消息传递操作推迟特定的秒数，例如，当您的使用者应用程序需要更多的时间处理消息时。如果您创建延迟队列，则发送到队列的任何消息在延迟期间对使用者都不可见。队列的默认（最短）延迟为 0 秒。最大值为 15 分钟。
延迟队列类似于可见性超时，因为这两种功能都使得使用者在特定的时间段内无法获得消息。二者之间的区别在于：对于延迟队列，消息在首次添加到队列时 是隐藏的；而对于可见性超时，消息只有在从队列使用后 才是隐藏的。下图说明了延迟队列和可见性超时之间的关系。
Amazon SQS 可视化超时
当消费者从队列中接收并处理一个消息时，该消息会留在队列中。Amazon SQS不会自动删除该消息。因为Amazon SQS是一个分布式系统，不能保证消费者真正收到消息（例如，由于连接问题，或由于消费者应用程序中的问题）。因此，消费者在接收和处理消息后必须从队列中删除该消息。
在收到一个消息后，它立即留在队列中。为了防止其他消费者再次处理该消息，Amazon SQS设置了一个可见性超时，即Amazon SQS防止其他消费者接收和处理该消息的时间段。一个消息的默认可见性超时是30秒。最小是0秒。最大的是12小时。有关使用控制台为队列配置可见性超时的信息。
- 正在飞行中的信息
一个Amazon SQS消息有三种基本状态。
1.由生产者发送至队列。
2.由消费者从队列中接收。
3.从队列中删除。
当生产者将消息发送到队列中，但消费者还没有从队列中接收到消息时（即状态1和状态2之间），该消息被认为是被存储的。对存储的消息的数量没有配额。当消费者从队列中收到一条消息，但尚未从队列中删除时（即在状态2和3之间），该消息被认为是在飞行。对飞行中的消息的数量是有配额的。
对于大多数标准队列（取决于队列流量和消息积压），最多可以有大约120,000条飞行中的消息（消费者从队列中收到，但尚未从队列中删除）。如果您在使用短轮询时达到这个配额，Amazon SQS会返回OverLimit错误信息。如果您使用长轮询，Amazon SQS不会返回错误信息。为了避免达到配额，你应该在处理完信息后从队列中删除这些信息。您也可以增加您用来处理消息的队列的数量。要请求增加配额，请提交一个支持请求。
对于先进先出的队列，最多可以有20,000条机内消息（消费者从队列中收到，但尚未从队列中删除）。如果你达到这个配额，Amazon SQS不会返回错误信息。
- 设置可见性超时
可见性超时从Amazon SQS返回一个消息时开始。在这段时间内，消费者会处理并删除该消息。但是，如果消费者在删除消息之前失败了，并且您的系统在可见性超时之前没有为该消息调用DeleteMessage动作，那么该消息对其他消费者来说就变得可见了，并且该消息会被再次接收。如果一个消息必须只被接收一次，你的消费者应该在可见性超时的时间内删除它。
每个Amazon SQS队列的默认可见性超时设置为30秒。你可以为整个队列改变这个设置。通常情况下，你应该将可见性超时设置为你的应用程序处理和删除队列中的消息所需的最大时间。当接收消息时，你也可以为返回的消息设置一个特殊的可见性超时，而不改变整个队列的超时。欲了解更多信息，请参见及时处理消息一节中的最佳做法。
如果你不知道处理一个消息需要多长时间，为你的消费者进程创建一个心跳。指定初始可见性超时（例如，2分钟），然后–只要你的消费者仍然在处理消息–保持每分钟延长2分钟的可见性超时。
- 改变信息的可见度超时
当你从队列中收到一条消息并开始处理它时，队列的可见性超时可能不够（例如，你可能需要处理并删除一条消息）。你可以通过使用ChangeMessageVisibility动作指定一个新的超时值来缩短或延长消息的可见性。
例如，如果一个队列的默认超时是60秒，从你收到消息到现在已经过了15秒，而你发送的ChangeMessageVisibility调用的VisibilityTimeout设置为10秒，那么这10秒就从你发出ChangeMessageVisibility调用的时候开始计算。因此，任何试图改变可见性超时或在你最初改变可见性超时（总共25秒）10秒后删除该消息的尝试都可能导致错误。
- 终止一个消息的可见性超时
当你从队列中收到一个消息时，你可能会发现你实际上并不想处理和删除这个消息。Amazon SQS允许你终止特定消息的可见性超时。这使得该消息对系统中的其他组件立即可见，并可用于处理。
要在调用ReceiveMessage后终止消息的可见性超时，请在VisibilityTimeout设置为0秒时调用ChangeMessageVisibility。