为什么我应该在 AWS 上使用简单队列服务 (SQS) 而不是 ElastiCache

Question

SQS 看起来很容易使用，但有一些消息大小限制，例如256 KB 消息大小（非常非常小）。另一方面，ElasticCache 似乎更高端一些？我不确定这个假设是否正确 - 请纠正我。

我正在使用一种或另一种类型的消息传递（和/或缓存）系统在 AWS 上部署应用程序。在什么情况下我会选择其中一种？

Answer 1

将 SQS 与 ElastiCache 进行比较有点像将明信片与文件柜进行比较。

哪个“更好”？

这取决于你想要完成什么，在这两种情况下，它们的功能几乎没有重叠，除了它们都临时存储信息这一事实。

缓存（如 ElastiCache）是一个可以存储经常访问的信息以便在从其权威来源（通常是数据库）重复获取信息时进行频繁检索的地方，其成本（通常在资源或时间方面）比从缓存中获取它是。缓存更像是一个带有开放式背面的文件柜，在需要存储新文件时，它会自动将旧文件排入碎纸机。这称为从缓存中逐出。由于其目的，存储在高速缓存中的信息通常不被认为是持久存储的。某个节点发生故障，或者数据被驱逐，您存储的内容不再存在。

“另外一个隐含的事实是，如果值太旧或缓存已满，缓存可能会过期或驱逐值。”

——http://aws.amazon.com/blogs/aws/amazon-elasticache-distributed-in-memory-caching/

没问题，因为缓存不是权威的数据源...但是当数据在那里时，您可以非常快速地访问它。如果您查找某些内容并且缓存中没有它，则转到数据的权威来源，并可选择将其副本发送回缓存，以便下一个请求它的实体可以在缓存中找到它.

当你想从缓存中获取某些东西时，你会去请求那个东西，特别是。

另一方面，像简单队列服务 (SQS) 这样的队列更像是一张明信片 - 或者，至少，队列消息是这样的。您编写消息，将其发送到队列中，然后它会从另一端弹出——通常是一次。不能保证消息的顺序（尽管它们通常按顺序到达）并且消息是guaranteed to be delivered "at least once"（尽管同样，重复消息通常很少见——尽管如此，它是一个庞大的分布式基础设施，所以重复传递是可能）。

当您需要队列中的某些内容时，它会向您发送排队的下一条消息——您无需选择哪条消息。

如果您需要缓存信息以进行随机、快速和重复检索，并且信息是一次性和可重新创建的，那么 ElastiCache 当然是两者的选择。

如果您需要在独立运行或以不同速度运行的系统的两个部分之间发送消息，那么您正在寻找消息队列，例如 SQS。通常，较小的有效负载大小限制绰绰有余，因为没有必要在队列消息本身中发送数据块。相反，您发送对数据的引用、指针、来自事务表的“id”或指向 Web 可访问对象（可能存储在 S3 中）的 URL，然后队列使用者可以获取由排队消息，并对其采取行动。

Answer 2

通过经验获得正确的用例。实际上大约 2 年前在 AWS 上部署了代码。选择 SQS，因为它正是我需要连接我的云应用程序的两个部分。事实上...... 256 KB 的大小已经足够了；）。