memcache和elasticache自动缩放

Question

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

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

对于后台，我正在查看AWS Opsworks并想知道是否使用Elasticache或memcached层。

Answer 1

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

现在问你的问题......

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

当群集更改时，您的密钥是否重新映射实际取决于您使用memcached客户端的方式 - 而不是AWS Elasticache服务本身。

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

如果你绝对必须拥有Auto Scaling并且绝对必须避免密钥重映射，那么就可以解决这个问题。

1. 请勿使用自动发现。相反，将客户端配置为始终使用最大数量的节点 - 无论正在运行多少节点。 memcached Elasticache集群中节点的名称是可预测的。例如，如果您的自动扩展策略允许最多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并安排在非高峰流量时间内进行缩放事件。