SQS似乎非常易于使用，但是具有一些消息大小限制，例如256 KB消息大小（确实很小）。另一方面，ElasticCache似乎更高端？我不确定这个假设是否正确-请纠正我。
我正在通过使用一种或另一种类型的消息传递（和/或缓存）系统在AWS上部署应用程序。在什么情况下我会选择一个？
将SQS与ElastiCache进行比较有点像将明信片与文件柜进行比较。
哪一个更好？”
这取决于您要完成的工作，在这两种情况下，除了它们都瞬时存储信息外，它们在功能上几乎没有重叠。
像ElastiCache这样的缓存是一个地方，当从权威来源（通常是数据库）中重复获取信息时（通常在资源或时间方面）比从中获取信息时，可以存储经常访问的信息以进行频繁检索。缓存将。高速缓存更像是带有开放式背盖的文件柜，可在需要存储新文件时自动将旧文件排入切碎机。这称为从缓存中逐出。由于其目的，通常不认为持久存储在高速缓存中的信息被存储。节点发生故障，或者数据被逐出，并且存储的内容不再存在。
“同样隐含的事实是，如果缓存太旧或缓存已满，则缓存可能过期或逐出值。”
— http://aws.amazon.com/blogs/aws/amazon-elasticache-distributed-in-memory-caching/
没问题，因为缓存不是权威数据源...但是当数据在那里时，您可以非常快速地访问它。如果您查找某些内容而高速缓存中没有，则转到数据的权威来源，还可以选择将其副本发送回高速缓存，以便下一个要查询的实体可以在高速缓存中找到它。 。
当您想要从缓存中获取某些东西时，就去找那个东西。
另一方面，像简单队列服务（SQS）这样的队列更像明信片-至少，这就是队列消息的样子。您编写消息，将其发送到队列中，然后弹出另一端-通常一次。不能保证消息的顺序（尽管它们按顺序到达的共同点），并且保证消息“至少一次”传递（尽管同样，重复的消息很少见，但它仍然是大量的，分散的）基础架构，因此可以重复交付）。
当您要从队列中获取某些内容时，它会向您发送一行中的下一条消息-您无需选择哪个。
如果您需要缓存信息以进行随机，快速和重复的检索，并且该信息是一次性的且可重新创建的，那么当然要选择ElastiCache。
如果需要在独立运行或以不同速度运行的系统的两个部分之间发送消息，那么您正在寻找消息队列，例如SQS。通常，较小的有效负载大小限制已绰绰有余，因为不必在队列消息本身中发送数据块。取而代之的是，您发送对数据的引用，指针，来自事务表的“ id”或指向可通过Web访问的对象（可能存储在S3中）的URL，然后队列使用者就可以获取由对象引用的数据块。将消息排队，然后对其采取行动。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句