为什么在AWS上应该使用简单队列服务（SQS）而不是ElastiCache？

Question

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

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

- nikk

Answer 1

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

哪一个“更好”？

这取决于您想要实现什么目标，在两种情况下，它们的功能几乎没有重叠，除了它们都是短暂存储信息的事实。

ElastiCache等缓存是频繁访问的信息可以存储在其中，以便在反复从其权威来源（通常是数据库）获取该信息比从高速缓存中获取该信息更昂贵（通常是资源或时间方面）时进行频繁检索。 缓存更像是带有开放后备箱并且每次需要存储新文档时自动将旧文档排出到碎纸机中的文件柜。 这被称为从缓存中逐出。 由于其目的，存储在缓存中的信息通常不被认为是持久存储。 节点失败或数据被逐出，您存储的内容就不再存在了。

“还隐含着如果缓存变得太旧或缓存变满，缓存可以过期或逐出值。”

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

没有问题，因为缓存不是权威数据源...但是在数据存在时，您可以快速访问它。 如果查找某些内容而缓存没有它，则需要从数据的权威来源获取它，并可选择将其副本发送回缓存中，以便下一个请求该信息的实体可以在缓存中找到它。

当您需要从缓存中获取内容时，只需特定地请求即可。

另一方面，像简单队列服务（SQS）之类的队列更像明信片--至少队列消息是这样的。您编写消息，将其发送到队列中，然后它会从另一端弹出--通常只发生一次。消息的排序不能保证（尽管它们通常按顺序到达），并且消息“至少传递一次”可以得到保障（不过，重复消息通常很少--但仍然存在可能发生重复传递，因为这是一个庞大的分布式基础架构）。

当您需要从队列中获取某些信息时，它会向您发送下一个排队的消息--您无法选择哪个消息。

如果您需要缓存信息以进行随机、快速和重复检索，并且该信息是可丢弃和可重新创建的，则当然应该选择ElastiCache 这两者中的选择。

如果您需要在运行独立或以不同速度运行的系统的两个部分之间发送消息，则需要消息队列，例如SQS。通常，小负载大小限制已经足够，因为没有必要在队列消息本身中发送数据块。相反，您发送对数据的引用，指针，事务表中的“id”或指向Web可访问对象（可能存储在S3中）的URL，队列消费者然后可以获取由队列消息引用的数据块，并对其进行操作。

- Michael - sqlbot

---

嗨，Michael，感谢你提供的好建议。我会考虑你的意见来评估我的决定。我还有另一个非常类似的问题在这里。请问您对此有何看法？ - nikk

公平地说，EC Redis 可以完美地用作队列 https://aws.amazon.com/redis/Redis_Streams_MQ/ ，但在这种特定情况下，您可能仍然是正确的。 - b.b3rn4rd

Answer 2

通过经验，我成功地理解了使用案例。实际上，我在大约两年前在AWS上部署了代码。我选择了SQS，因为它正是我需要将云应用程序的两个部分连接起来的工具。而且... 256 KB 的大小绰绰有余 ;).

- nikk