设置简单:
我有以下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进行接口(interface)连接时，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以获得更多信息:Issue #427
最佳答案
我看不到您的配置有任何问题。如您所知，重要的设置已经到位:
default:
auto_eject_hosts: true
server_failure_limit: 1
该文档表明连接超时可能是一个问题。
在twemproxy首次尝试失败并从池中删除服务器之前，您的PHP脚本是否关闭连接并重试？也许在twemproxy中添加比php中使用的连接超时低的
timeout值可以解决此问题。从您在Github上的讨论来看，这听起来像是对健康检查的支持，甚至自动弹出，但在tempemproxy中并不稳定。如果要针对旧软件包进行构建，则最好找到一个稳定了一段时间的软件包。 mcrouter(带有interesting article)适合吗？
关于php - Twitter-twemproxy-memcached-重试未按预期工作，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/33487641/