Twitter - twemproxy - memcached - 重试未按预期工作

2022-08-30 16:45:11

设置简单:

  • 1 个节点运行 twemproxy (vcache:22122)
  • 2 个运行 memcached (vcache-1, vcache-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 的接口尝试失败是否是由于基础结构问题引起的,如果是,请重试。但是,我发现在重试时,正在使用相同的故障服务器,因此不会将后续尝试传递到已知良好的缓存节点(在本例中为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 上打开的问题的链接以获取更多信息:问题 #427


答案 1

我看不出您的配置有任何问题。如您所知,重要设置已准备就绪:

default:
  auto_eject_hosts: true
  server_failure_limit: 1

文档表明连接超时可能是一个问题。

仅依赖于客户端超时会产生不利影响,因为原始请求在客户端到代理连接上具有超时,但在代理到服务器的连接上仍处于挂起和未完成状态。当客户端重试原始请求时,这种情况会进一步加剧。

您的 PHP 脚本是否在 twemproxy 第一次尝试失败并从池中删除服务器之前关闭连接并重试?也许在 twemproxy 中添加一个低于 PHP 中使用的连接超时的值可以解决这个问题。timeout

从你在Github上的讨论来看,虽然听起来像是对健康检查的支持,也许还有自动弹出,但在twemproxy中并不稳定。如果你是针对旧包构建的,你最好找到一个已经稳定了一段时间的包。mcrouter(带有有趣的文章)合适吗?


答案 2

推荐