我想自己托管一个 Redis 服务器。我将 EC2 与 Elasticache 进行了比较。 我想知道EC2的缺点是什么。
一个 EC2 微型实例的成本与 Elasticache 微型实例一样高，但内存要多 400 mb。为什么要使用 Elasticache 而不是在 ec2 tiny 实例上设置自己的 Redis 服务器？
最佳答案
tl;dr:Elasticache 强制您使用单个 redis 实例，这是次优的。
长版:
我意识到这是一篇旧帖子(撰写本文时已 2 年)，但我认为重要的是要注意我在这里看不到的一点。
在 elasticache 上，您的 redis 部署由 Amazon 管理。这意味着你被他们选择运行你的 redis 所困。
Redis 使用单线程执行读/写。这确保了没有锁定的一致性。就性能而言，不管理锁和闩锁是一项重要 Assets 。然而，不幸的结果是 if your EC2 has more than 1 vCPU they will go unused .具有多个 vCPU 的所有 elasticache 实例都是这种情况。
默认的elasticache实例大小是cache.r3.large，它有两个核心。
事实上，具有多个 vCPU 的实例大小很多。这个问题有很多机会表现出来。
亚马逊似乎已经意识到了这个问题，但他们似乎有点不屑一顾。
使这与这个问题特别相关的部分是，在您的 EC2 上(因为您正在管理自己的部署)您能够实现 multi-tenancy .这意味着您有许多在不同端口上监听的 redis 进程实例。通过根据记录 key 的哈希值选择在应用程序中读取/写入哪个端口，您可以利用所有 vCPU。
作为旁注；与实例大小上的 memcached elasticache 部署相比，多核机器上的 redis elasticache 部署应始终表现不佳。对于 Multi-Tenancy ，redis 往往是赢家。
更新:
Amazon 现在为您的 redis 实例 CPU EngineCPUUtilization 提供单独的指标。您不再需要用伪劣的乘法来计算 CPU，但仍然没有实现 Multi-Tenancy 。
关于amazon-ec2 - Redis:Amazon EC2 与 Elasticache，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21175941/