Redis：Amazon EC2 vs Elasticache

Question

我想自己托管Redis服务器。我将EC2与Elasticache进行了比较。 我想知道EC2的缺点是什么。

一个EC2微型实例的成本与ELasticache微型实例一样多，但是更多的是400 MB的内存。为什么要使用Elasticache而不是在ec2 tiny isntance上设置自己的Redis服务器？

Answer 1

由于我很懒，我会选择Elasticcache而不是EC2，以便我可以避免管理Redis实例的一些操作方面。使用Redis on EC2，您负责主机和Redis实例的扩展，更新，监视和维护。如果您处理Redis的操作方面很好，那么它应该不是问题。很多人都在查看运行Redis实例的操作方面的成本。除非你对Redis经验丰富，否则我会考虑使用Elasticache。我一直在使用它，到目前为止对它非常满意。

现在，当您需要Elasticache不支持的Redis自定义配置时，EC2才有意义。

此外，̶如果需要连接到Redis的实例从外部的AWS环境，̶̶E̶l̶a̶s̶t̶i̶c̶a̶c̶h̶e̶将是一个问题，因为你不容使用Redis的-CLI连接到Redis的实例，它是在运行从̶E̶l̶a̶s̶t̶i̶c̶a̶c̶h̶e̶ ̶o̶u̶t̶s̶i̶d̶e̶.̶

<强>更新： Accessing ElastiCache Resources from Outside AWS

最后，如果您计划处于Redis的最前沿，那么运行自己的更有意义。但话说回来，你拥有了操作位，监控，修补等等。

Answer 2

tl; dr：Elasticache强制您使用redis的单个实例，这是次优的。

长版：

我意识到这是一篇旧文章（撰写本文时为2年），但我认为重要的是要注意我在这里看不到的一点。

在弹性缓存上，您的redis部署由Amazon管理。这意味着你仍然坚持使用他们选择运行你的redis。

Redis使用单个执行线程进行读/写。这确保了无锁定的一致性。就性能而言，它不是管理锁和锁存器的重要资产。然而，不幸的后果是if your EC2 has more than 1 vCPU they will go unused。具有多个vCPU的所有弹性缓存实例都是这种情况。

默认的elasticache实例大小为cache.r3.large，它有两个核心。

实际上，有许多具有多个vCPU的实例大小。这个问题有很多机会表现出来。

亚马逊似乎已经意识到了这个问题，但他们似乎对它有点不屑一顾。

使这与此问题特别相关的部分是，在您的EC2上（因为您正在管理自己的部署），您可以实施multi-tenancy。这意味着您有许多redis进程实例正在侦听不同的端口。通过根据记录密钥的散列选择在应用程序中读/写哪个端口，您可以利用所有vCPU。

作为旁注;与实例大小上的memcached elasticache部署相比，多核机器上的redis elasticache部署应始终处于执行状态。随着多租户，redis往往成为胜利者。

更新

Amazon现在为您的redis实例CPU EngineCPUUtilization提供单独的指标。您不再需要使用劣质乘法来计算CPU，但仍未实现多租户。

Answer 3

另一点是Elasticache是​​动态的，你可以减少/增加你动态使用的内存，甚至关闭缓存（并保存$$）如果你的性能指数是绿色的。

Answer 4

Elasticache的优缺点：

优点
 -AWS托管服务；因此只需在应用程序中使用Redis，而无需管理（将其留给AWS）
 -适用于内存数据库的灵活实例类型。
 -如果节点有任何问题，AWS会负责（故障转移，节点更换，维护等）
 -符合HIPAA的服务。
 -仅Redis->如果存在不允许BGSAVE的内存问题，它们具有自己的备份实现。
 -可以定期创建快照。
 -可以在水平和垂直方向轻松扩展（启用集群模式时最多可以有250个分片）。
 -配置端点永不更改，因此在发生故障转移时无需更改应用程序中的任何内容（除非您正在使用节点端点）

缺点：
 -由于该服务是AWS托管的，因此无法获得性能优化的范围（通过参数组），因为您没有获得OS级访问权限。
 -没有很多实例类型，例如x1等。
 -没有太多可定制的功能，例如：创建后便无法更改密码（Redis AUTH）。
 -可能需要定期维护，这可能与生产关键时间同时发生，因此需要多加担心。
 -并非所有维护事件都会收到通知，因此会产生不必要的干扰。
 -需要花费很多时间（取决于节点类型和节点数）。
 -可能会很贵。

自定义EC2安装的利与弊：

优点
 -额外的自由来优化和自定义
 -自行维护
 -使用任何资源

缺点
 -需要自定义逻辑以进行维护，扩展，从故障和备份中恢复等。
 -增加了运营费用。

列表很长，但是应该涵盖明显的差异。

Answer 5

t2.micro vs cache.t2.micro

t2.micro - 1GiB cache.t2.micro - 0.555GiB

但是在t2.micro你需要操作系统！他们中的大多数需要大约512MiB。

t2.micro可能只能在网络性能上获胜。您可以尝试运行基准测试并进行比较。