简单设置:
- 1 个节点运行 twemproxy (vcache:22122)
- 运行 memcached (vcache-1, vcache-2) 的 2 个节点都在监听 11211
我有以下 twemproxy 配置:
default:
auto_eject_hosts: true
distribution: ketama
hash: fnv1a_64
listen: 0.0.0.0:22122
server_failure_limit: 1
server_retry_timeout: 600000 # 600sec, 10m
timeout: 100
servers:
- vcache-1:11211:1
- vcache-2:11211:1
twemproxy 节点可以解析所有主机名。作为测试的一部分，我删除了 vcache-2。理论上，每次尝试与 vcache:22122 交互时，twemproxy 都会联系池中的服务器以促进尝试。但是，如果其中一个缓存节点出现故障，则 twemproxy 应该从池中“自动弹出”它，因此后续请求不会失败。
由应用层来确定使用 vcache:22122 的接口(interface)尝试失败是否是由于基础架构问题，如果是，请重试。但是我发现在重试时，正在使用相同的失败服务器，因此后续尝试不会传递给已知良好的缓存节点(在本例中为 vcache-1)，它们仍被传递给弹出的缓存节点(vcache -2)。
这是尝试重试的 php 代码片段:
....
// $this is a Memcached object with vcache:22122 in the server list
$retryCount = 0;
do {
$status = $this->set($key, $value, $expiry);
if (Memcached::RES_SUCCESS === $this->getResultCode()) {
return true;
}
} while (++$retryCount < 3);
return false;
-- 更新--
在 Github 上打开的问题链接以获取更多信息:Issue #427
最佳答案
我看不出您的配置有什么问题。如您所知，重要设置已到位:
default:
auto_eject_hosts: true
server_failure_limit: 1
文档表明连接超时可能是一个问题。
Relying only on client-side timeouts has the adverse effect of the original request having timedout on the client to proxy connection, but still pending and outstanding on the proxy to server connection. This further gets exacerbated when client retries the original request.
您的 PHP 脚本是否在 twemproxy 首次尝试失败并将服务器从池中删除之前关闭连接并重试？也许在 twemproxy 中添加 低于 的 timeout 值比 PHP 中使用的连接超时值可以解决问题。
从您在 Github 上的讨论来看，虽然这听起来像是对健康检查的支持，也许还有自动弹出，但在 twemproxy 中并不稳定。如果您正在构建旧软件包，您可能会更好地找到一个已经稳定一段时间的软件包。是 mcrouter (与 interesting article )合适吗？
关于php - Twitter - twemproxy - memcached - 重试未按预期工作，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33487641/