nik*_*ikk 6 amazon-sqs amazon-web-services amazon-elasticache
SQS看起来很容易使用,但有一些消息大小限制,例如256 KB的消息大小(真的,非常小).另一方面,ElasticCache似乎更高端？我不确定这些假设是否正确 - 请纠正我.
我正在使用一种或另一种类型的消息传递(和/或缓存)系统在AWS使用上部署应用程序.在什么情况下我会选择一个而不是另一个？
Mic*_*bot 15
将SQS与ElastiCache进行比较有点像将明信片与文件柜进行比较.
哪一个更好？"
这取决于你想要完成什么,并且在这两种情况下,除了它们都暂时存储信息之外,它们在功能上几乎没有重叠.
像ElastiCache这样的缓存是一个可以存储频繁访问的信息以便在从其权威来源(通常是数据库)重复获取信息时(通常在资源或时间方面)比从中获取信息时更频繁检索的信息的地方缓存将是.缓存更像是一个带有开放式后盖的文件柜,可以在需要存储新文档时自动将旧文档丢入碎纸机.这被称为从缓存中逐出.由于其目的,通常不会考虑存储在高速缓存中的信息被持久存储.节点出现故障,或者数据被逐出,您存储的内容不再存在.
"另外隐含的事实是,如果缓存过长或缓存变满,缓存可能会过期或逐出值."
- http://aws.amazon.com/blogs/aws/amazon-elasticache-distributed-in-memory-caching/
没问题,因为缓存不是权威数据源......但是当数据存在时,您可以非常快速地访问它.如果您查找某些内容而缓存中没有它,则转到数据的权威来源,并可选择将其副本发送回缓存,以便下一个要求它的实体可以在缓存中找到它.
当你需要缓存中的某些东西时,你会特别要求那个东西.
另一方面,像简单队列服务(SQS)这样的队列更像是一张明信片 - 或者至少是队列消息的样子.您编写消息,将其发送到队列中,然后弹出另一端 - 通常是一次.消息的排序不能得到保证(尽管它们按顺序到达它们是常见的)并且保证消息"至少一次"传递(但是,通常,重复的消息很少 - 但仍然是一个巨大的,分布式的基础设施,所以重复交付是可能的).
当你需要队列中的某些东西时,它会向你发送下一条消息 - 你不会选择哪一条消息.
如果您需要缓存随机,快速和重复检索的信息,并且信息是一次性的和可重新调用的,那么当然ElastiCache是两者的选择.
如果您需要在独立运行或以不同速度运行的系统的两个部分之间发送消息,那么您正在寻找消息队列,例如SQS.通常,小的有效负载大小限制绰绰有余,因为不必在队列消息本身中发送数据块.相反,您发送对数据的引用,指针,来自事务表的"id"或URL到Web可访问对象(可能存储在S3中),然后队列使用者可以获取由引用的数据块.队列消息,并对其采取行动.
| 归档时间： |
|
| 查看次数： |
5159 次 |
| 最近记录： |