memcache和弹力缓存自动标度

Question

据我所知，如果您使用memcached节点实现自动标注，并使用某种动态触发器将这些新节点包含在应用程序中，那么在更改散列算法以分配碎片时，基本上会使缓存失效。因此，如果是这样的话，那么基于加载的memcached自动标注不是一个好主意。这是正确的吗？

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

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

Answer 1

请注意，“自动发现”并不像问题中所述的那样基于单个IP。IP可以随着时间的推移而改变。当您查询配置终结点时，Elasticache会将请求路由到群集中的健康节点。

现在说说你的问题..。

自动缩放是否“是一个好主意”可能在一定程度上取决于您的应用程序是否能够容忍键重映射。

当集群发生变化时，您的键是否重新映射取决于您如何使用memcached客户机--而不是AWS Elasticache服务本身。

对于memcached客户端库，我相信您的假设是正确的。如果您从集群中添加或删除节点，并且使用的是自动发现客户端，则这些键将重新映射。

如果您绝对必须有自动缩放和绝对必须避免键重映射，有一个工作。

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为解决此问题而开发的last.fm。

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

事情开始变得复杂起来。

相反，我在实践中所做的是手动处理缩放Elasticache，并安排在非高峰流量时间内发生的缩放事件。