amazon-web-services - 为什么我应该在AWS的ElastiCache上使用简单队列服务(SQS)

Question

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

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

Answer 1

将SQS与ElastiCache进行比较有点像将明信片与文件柜进行比较。
哪一个更好？”
这取决于您要完成的工作，在这两种情况下，除了它们都瞬时存储信息外，它们在功能上几乎没有重叠。
像ElastiCache这样的缓存是一个地方，当从权威来源(通常是数据库)中重复获取信息时(通常在资源或时间方面)比从中获取信息时，可以存储经常访问的信息以进行频繁检索。缓存将是。缓存更像是带有开放式后背的文件柜，可在需要存储新文件时自动将旧文件排入切碎机。这称为从缓存中逐出。由于其目的，通常不认为持久存储在高速缓存中的信息会被存储。节点发生故障，或数据被逐出，并且存储的内容不再存在。

“Also implicit is the fact that the cache can expire or evict values if they become too old or if the cache becomes full.”

— 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，然后队列使用者可以获取该对象所引用的数据块。将消息排队，然后对其采取行动。