AWS - Elasticache - 会话 - 不规则持久性模式
AWS - Elasticache - Sessions - Irregular persistence patterns
我们正在从 linode 迁移到 aws，发现会话未按预期持续存在的问题。
在 linode 上，我们有一个 运行 Twitter 的 twemproxy 实例，它将处理缓存池中节点的添加和删除，并且会话会按预期持续存在。如果一个节点被删除（中断）那么当然会重新生成一个会话，否则，twemproxy 将知道如何从在线和注册的缓存节点检索会话数据。
但是在 AWS 上我们有一个 Elasticache 实例设置如下：
- 总共 3 个节点
- AZ1 中的 2 个节点
- AZ2 中的 1 个节点
- 开放安全组（在没有外部访问权限的私有子网中）
我们将 DNS 设置为 'vcache' 指向 Elasticache 端点，这样我们就不必在应用程序层管理任何缓存主机名。该应用程序只知道连接到 vcache:22122
出于某种原因，会话 ID 会被不规则地重新生成，我们不确定原因。由于 Elasticache 是一个 'black box' 接口，我们假设它知道如何从特定的缓存节点访问密钥，就像使用 twemproxy 一样，但事实似乎并非如此。
我们是不是在设置中遗漏了什么，或者我们是否错误地假设 Elasticache 是一个知道如何访问数据的代理，甚至跨 AZ 节点？
AWS Elasticache 不会知道重定向到正确的节点，它不是实际的集群，而这应该由客户端完成。 Elasticache for memcached 将为您提供 auto-discovery endpoint and that's all your client needs to know. Using that endpoint your client library will find out the details about the cluster: the nodes and their endpoints. But you actually need to use a client library provided by AWS 以便自动使用自动发现。
使用 Elasticache 的优势在于它实际上会自动替换故障节点，因此您不必为此担心。当然还有所有 IT 东西、补丁、升级等
问题最终与此相关post：Twitter - twemproxy - memcached - Retry not working as expected
基本上我配置twemproxy考虑两台服务器； vcache-1 和 vcache-2，但 vcache-2 尚未初始化，因此它会按预期不断被弹出。然而，问题是 twemproxy 将 vcache-2 重新引入池中的请求会中断，即使在重试之后也是如此。似乎即使应用程序发出重试以在缓存中设置数据，twemproxy 也无法弹出并移动到仍在工作的节点上。
我们正在从 linode 迁移到 aws，发现会话未按预期持续存在的问题。
在 linode 上，我们有一个 运行 Twitter 的 twemproxy 实例，它将处理缓存池中节点的添加和删除，并且会话会按预期持续存在。如果一个节点被删除（中断）那么当然会重新生成一个会话，否则，twemproxy 将知道如何从在线和注册的缓存节点检索会话数据。
但是在 AWS 上我们有一个 Elasticache 实例设置如下：
- 总共 3 个节点
- AZ1 中的 2 个节点
- AZ2 中的 1 个节点
- 开放安全组（在没有外部访问权限的私有子网中）
我们将 DNS 设置为 'vcache' 指向 Elasticache 端点，这样我们就不必在应用程序层管理任何缓存主机名。该应用程序只知道连接到 vcache:22122
出于某种原因，会话 ID 会被不规则地重新生成，我们不确定原因。由于 Elasticache 是一个 'black box' 接口，我们假设它知道如何从特定的缓存节点访问密钥，就像使用 twemproxy 一样，但事实似乎并非如此。
我们是不是在设置中遗漏了什么，或者我们是否错误地假设 Elasticache 是一个知道如何访问数据的代理，甚至跨 AZ 节点？
AWS Elasticache 不会知道重定向到正确的节点，它不是实际的集群，而这应该由客户端完成。 Elasticache for memcached 将为您提供 auto-discovery endpoint and that's all your client needs to know. Using that endpoint your client library will find out the details about the cluster: the nodes and their endpoints. But you actually need to use a client library provided by AWS 以便自动使用自动发现。
使用 Elasticache 的优势在于它实际上会自动替换故障节点，因此您不必为此担心。当然还有所有 IT 东西、补丁、升级等
问题最终与此相关post：Twitter - twemproxy - memcached - Retry not working as expected
基本上我配置twemproxy考虑两台服务器； vcache-1 和 vcache-2，但 vcache-2 尚未初始化，因此它会按预期不断被弹出。然而，问题是 twemproxy 将 vcache-2 重新引入池中的请求会中断，即使在重试之后也是如此。似乎即使应用程序发出重试以在缓存中设置数据，twemproxy 也无法弹出并移动到仍在工作的节点上。