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

Question

简单设置：

• 运行双代理的1个节点(vcache:22122)
• 两个运行memcached的节点(vcache-1，vcache-2)都在监听11211。

我有以下两个代理配置：

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

双代理节点可以解析所有主机名。作为测试的一部分，我下载了vcache-2。理论上，对于每一次与vcache:22122接口的尝试，双代理都会从池中与服务器联系，以方便尝试。但是，如果其中一个缓存节点被关闭，那么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期

Answer 1

我看不出你的配置有什么问题。如您所知，重要的设置已经到位：

default:
  auto_eject_hosts: true
  server_failure_limit: 1

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

仅依赖客户端超时会产生不利影响，即原始请求对客户端到代理连接有超时，但在代理到服务器连接上仍有挂起和未决。当客户端重试原始请求时，这种情况会进一步恶化。

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

不过，从你对Github的讨论来看，这听起来像是对健康检查的支持，也许是自动弹出，但在双代理中并不稳定。如果您是针对旧包构建的，您最好找到一个已经稳定了一段时间的包。mcrouter路由器 (带有趣的文章)合适吗？

Answer 2

若要使此功能工作，请与此回购/分支合并。

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

让这个特定的提交

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

这是公共关系

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

之后，重新编译它