Amazon web services 为什么要在AWS上通过ElastiCache使用简单队列服务（SQS）

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

---

我正在利用一种或另一种类型的消息传递和/或缓存系统在AWS上部署应用程序。在什么情况下，我会选择一个而不是另一个

比较SQS和ElastiCache有点像比较。。。寄明信片到文件柜

哪一个更好

这取决于您想要完成什么，在这两种情况下，它们的功能几乎没有重叠，只是它们都暂时存储信息

与ElastiCache一样，缓存是一个存储频繁访问的信息以供频繁检索的地方，当重复从其权威来源获取该信息时，通常数据库在资源或时间方面比从缓存获取该信息更昂贵。缓存更像是一个文件柜，有一个打开的背面，当需要存储新文件时，可以自动将旧文件排入碎纸机。这称为从缓存中逐出。由于其用途，存储在缓存中的信息通常不被认为是持久存储的。节点出现故障，或者数据被逐出，并且您存储的内容不再存在

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

-

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

当你想从缓存中得到某样东西时，你就去索要，特别是

另一方面，队列（如简单队列服务SQS）更像一张明信片——或者，至少，队列消息就是这样的。您编写消息，将其发送到队列中，然后从另一端弹出—通常是一次。虽然消息按顺序到达是很常见的，但是消息的顺序并不能得到保证，而且消息也是如此，通常情况下，重复的消息是很少的-尽管如此，它是一个庞大的分布式基础设施，因此重复的传递是可能的

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

如果您需要缓存信息以进行随机、快速和重复的检索，并且这些信息是一次性和可再现的，那么ElastiCache当然是这两种选择中的一种

---

如果您需要在独立运行或以不同速度运行的系统的两个部分之间发送消息，那么您需要寻找一个消息队列，例如SQS。通常，小负载大小限制已经足够了，因为不需要在队列消息本身中发送数据块。相反，您发送一个对数据的引用、一个指针、一个来自事务表的id或一个可能存储在S3中的web可访问对象的URL，然后队列消费者可以获取队列消息引用的数据块，并对其采取行动。

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

嗨，迈克尔，谢谢你的大力支持。我会考虑你的建议来评估我的决定。我还有一个非常类似的问题。我能听听你的看法吗？公平地说，EC redis可以完美地用作队列，但在这种特殊情况下，你可能仍然是准确的