Question

简单设置：

1个运行twemproxy的节点（vcache：22122）
运行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应该是＆＃34; auto eject＆＃34;它来自池，因此后续请求不会失败。

由应用程序层决定是否因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上打开的问题链接了解更多信息：Issue #427

Answer 1

我无法看到您的配置有任何问题。如您所知，重要的设置已经到位：

default:
  auto_eject_hosts: true
  server_failure_limit: 1

文档建议连接超时可能是个问题。

仅依赖于客户端超时会对客户端的代理连接具有超时时间的原始请求产生负面影响，但在代理到服务器连接时仍然未决和未完成。当客户重试原始请求时，这会进一步恶化。

您的PHP脚本是否关闭连接并在twemproxy首次尝试失败并将其从池中删除之前重试？也许在twemproxy lower 中添加timeout值比PHP中使用的连接超时解决了这个问题。

从你对Github的讨论来看，虽然听起来像支持健康检查，也许是自动弹射，但是在twemproxy中并不稳定。如果您正在构建旧包装，那么最好找一个稳定一段时间的包装。 mcrouter（interesting article）是否合适？

Answer 2

要使此功能正常运行，请合并此repo / branch

https://github.com/charsyam/twemproxy/tree/feature/heartbeat

进行此特定提交

https://github.com/charsyam/twemproxy/commit/4d49d2ecd9e1d60f18e665570e4ad1a2ba9b65b1

这是PR

https://github.com/twitter/twemproxy/pull/428

之后重新编译它

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

2 个答案: