memcache 和 elasticache 自动缩放

Question

据我所知，如果您使用 memcached 节点实现自动缩放并使用某种动态触发器将这些新节点包含在您的应用程序中，那么当您更改哈希算法以分配分片时，您实际上会使缓存无效。因此，如果是这种情况，那么对 memcached 进行基于负载的自动缩放就不是一个好主意。这是正确的吗？

具有自动发现功能的 AWS Elasticache 是否具有某种智能来阻止这种情况的发生，因为它还支持添加节点并通过单个 IP 进行连接？据我所知，答案是否定的，因为它本质上只是根据发现记录中的服务器列表动态更改配置，因此会遇到同样的问题，但希望比我更了解的人可以说任何一种方式。

作为背景，我正在研究 AWS Opsworks，想知道是使用 Elasticache 还是使用 memcached 层。

Answer 1

请注意，自动发现不是基于问题中所述的单个 IP。 IP 可以随时间变化。当您查询配置端点时，Elasticache 会将请求路由到集群中健康的节点。

现在回答你的问题...

自动缩放是否“是个好主意”可能部分取决于您的应用是否可以容忍键重新映射。

当集群发生变化时你的密钥是否重新映射实际上取决于你如何使用你的 memcached 客户端——而不是 AWS Elasticache 服务本身。

对于我见过的 memcached 客户端库，我相信您的假设是正确的。如果您在集群中添加或删除节点并且您使用的是 Auto Discovery 客户端，则密钥将重新映射。

如果您绝对必须拥有 Auto Scaling 并且绝对必须避免密钥重新映射，则有一种解决方法。

1. 不要使用自动发现。相反，将您的客户端配置为始终使用最大数量的节点——无论有多少正在运行。您的 memcached Elasticache 集群中的节点名称是可预测的。例如，如果您的 Auto Scaling 策略最多允许 5 个节点，但您通常使用 2 个节点运行，请继续告诉您的缓存客户端节点是 mc.xxxxxx.0001.use1.cache.amazonaws.com、mc .xxxxxx.0002.use1.cache.amazonaws.com、mc.xxxxxx.0003.use1.cache.amazonaws.com、mc.xxxxxx.0004.use1.cache.amazonaws.com、mc.xxxxxx.0005.use1.cache .amazonaws.com
2. 使用支持最小化密钥重新映射的节点定位算法的客户端，例如 last.fm 开发的 Ketama Node Locater 来解决此问题。

这种方法的缺点是： 1. 在正常运行期间，您的缓存客户端会不断执行死节点检查以检查不存在的节点。 2. 在扩展事件之后，在您的正常运行配置中使用的节点仍将托管大部分密钥，除非您做更多的工作。例如，您可以键入分片并根据当前节点的数量确定分片的数量。

这开始变得复杂了。

我在实践中所做的是手动处理 Elasticache 扩展并将扩展事件安排在非高峰流量时间发生。