SQS看起来很容易使用，但有一些邮件大小限制，例如256 KB的消息大小（真的，非常小）。另一方面，ElasticCache似乎更高端？我不确定这些假设是否正确 - 请纠正我。
我正在使用一种或另一种类型的消息传递（和/或缓存）系统在AWS使用上部署应用程序。在什么情况下我会选择一个而不是另一个？
答案 0 :(得分：14)
将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”或URL到Web可访问对象（可能存储在S3中），然后队列使用者可以获取由引用的数据块。排队消息，并对其采取行动。
答案 1 :(得分：0)
通过经验获得了正确的用例。实际上大约2年前在AWS上部署了代码。使用SQS因为它正是我需要连接我的云应用程序的两个部分。事实上...... 256 KB就足够了;）。