我们正在从linode迁移到aws，并且正在看到会话未按预期持续存在的问题。
在linode上，我们有一个运行Twitter twemproxy的实例，它将处理添加和删除缓存池中的节点，并且会话按预期持续存在。如果一个节点被删除（中断），那么当然会重新生成一个会话，否则，twemproxy将知道如何从在线和已注册的缓存节点中检索会话数据。
但是在AWS上我们有一个Elasticache实例设置如下：
我们设置DNS以将'vcache'指向Elasticache端点，这样我们就不必在应用层管理任何缓存主机名。该应用程序只知道连接到vcache：22122
出于某种原因，会话ID正在不定期地重新生成，我们不确定原因。由于Elasticache是一个“黑盒子”接口，我们假设它将知道如何从特定的缓存节点访问密钥，就像使用twemproxy一样，但似乎并非如此。
我们是否遗漏了设置中的内容，或者我们错误地认为Elasticache是一个知道如何访问数据的代理，甚至是跨AZ节点？
答案 0 :(得分：1)
AWS Elasticache不会知道重定向到正确的节点，它不是真正的集群，而应该由客户端完成。 memcached的Elasticache将为您提供auto-discovery endpoint，这是您的所有客户需要知道的。使用该端点，您的客户端库将找到有关群集的详细信息：节点及其端点。但实际上您需要使用client library provided by AWS才能自动使用自动发现。
使用Elasticache的优点是它实际上会自动替换失败的节点，因此您不必担心这一点。当然还有所有的IT东西，补丁，升级等等。
答案 1 :(得分：0)
此问题最终与此帖有关：Twitter - twemproxy - memcached - Retry not working as expected
基本上我配置了twemproxy考虑两个服务器; vcache-1和vcache-2，但vcache-2尚未初始化，因此它不断按预期弹出。然而问题是，即使在重试尝试之后，twemproxy将vcache-2重新引入池中的请求也会中断。似乎即使使用应用程序发出重试来在缓存中设置数据twemproxy也无法弹出并移动到仍在工作的节点上。