amazon-ec2 - Redis：Amazon EC2 与 Elasticache

Question

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

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

Answer 1

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

长版：

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

在 elasticache 上，您的 redis 部署由 Amazon 管理。这意味着你被他们选择运行你的 redis 所困。

Redis 使用单线程执行读/写。这确保了没有锁定的一致性。就性能而言，不管理锁和闩锁是一项重要资产。但是，不幸的结果是，如果您的 EC2 有超过 1 个 vCPU，它们将处于未使用状态。具有多个 vCPU 的所有 elasticache 实例都是这种情况。

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

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

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

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

作为旁注；与实例大小上的 memcached elasticache 部署相比，多核机器上的 redis elasticache 部署应始终表现不佳。对于多租户，redis 往往是赢家。

更新：

Amazon 现在为您的 redis 实例 CPU EngineCPUUtilization 提供单独的指标。你不再需要用伪劣的乘法来计算你的 CPU，但是多租户仍然没有实现。

Answer 2

由于我很懒，我会选择 Elasticcache 而不是 EC2，这样我就可以避免管理 Redis 实例的一些操作方面的问题。使用 EC2 上的 Redis，您负责主机和 Redis 实例的扩展、更新、监控和维护。如果您可以很好地处理 Redis 的操作方面，那么这应该不是问题。很多人都在关注运行 Redis 实例的运营成本。除非你熟悉 Redis，否则我会考虑 Elasticache。我一直在使用它，并且到目前为止对它非常满意。

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

A̶d̶d̶i̶t̶i̶o̶n̶a̶l̶l̶y̶,̶ ̶i̶f̶ ̶y̶o̶u̶ ̶n̶e̶e̶d̶ ̶t̶o̶ ̶c̶o̶n̶n̶e̶c̶t̶ ̶t̶o̶ ̶y̶o̶u̶r̶ ̶R̶e̶d̶i̶s̶ ̶i̶n̶s̶t̶a̶n̶c̶e̶ ̶f̶r̶o̶m̶ ̶o̶u̶t̶s̶i̶d̶e̶ ̶o̶f̶ ̶t̶h̶e̶ ̶A̶W̶S̶ ̶e̶n̶v̶i̶r̶o̶n̶m̶e̶n̶t̶,̶ ̶E̶l̶a̶s̶t̶i̶c̶a̶c̶h̶e̶ ̶w̶i̶l̶l̶ ̶b̶e̶ ̶a̶ ̶p̶r̶o̶b̶l̶e̶m̶ ̶a̶s̶ ̶y̶o̶u̶ ̶c̶a̶n̶'̶t̶ ̶u̶s̶e̶ ̶t̶h̶e̶ ̶r̶e̶d̶i̶s̶-̶c̶l̶i̶ ̶t̶o̶ ̶c̶o̶n̶n̶e̶c̶t̶ ̶t̶o̶ ̶a̶ ̶R̶e̶d̶i̶s̶ ̶i̶n̶s̶t̶a̶n̶c̶e̶ ̶t̶h̶a̶t̶ ̶i̶s̶ ̶r̶u̶n̶n̶i̶n̶g̶ ̶i̶n̶ ̶E̶l̶a̶s̶t̶i̶c̶a̶c̶h̶e̶ ̶f̶r̶o̶m̶ ̶o̶u̶t̶s̶i̶d̶e̶.̶

更新：从外部 AWS 访问 ElastiCache 资源

最后，如果您打算走在 Redis 的最前沿，那么自己运行会更有意义。但话又说回来，您拥有操作位、监控、修补等。

Answer 3

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

Answer 4

弹性疼痛的优点和缺点：

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

缺点：
- 由于该服务是 AWS 托管的，因此性能优化的空间非常小（通过参数组），因为您没有获得操作系统级别的访问权限。
- 没有很多实例类型，例如 x1 等。
- 没有太多自定义可用 例如：一旦创建，您就无法更改密码 (Redis AUTH)。
- 可能需要定期维护，这可能与生产关键时间同时发生，因此需要担心额外的事情。
- 并非所有维护事件都会收到通知，因此不必要的干扰。
- 启动需要很长时间（取决于节点类型和节点数）。
- 可能被证明是昂贵的。

自定义 EC2 安装的优缺点：

优点
- 优化和定制的额外自由
- 您自己的时间维护
- 使用任何资源

缺点
- 需要自定义逻辑来进行维护、扩展、故障恢复和备份等
- 增加运营开销。

清单很长，但这些应该涵盖显着差异。

Answer 5

t2.micro 与 cache.t2.micro

t2.micro - 1GiB 缓存.t2.micro - 0.555GiB

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

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