Twitter - twemproxy - memcached - Повторная попытка не работает должным образом

Простая настройка:

  • 1 node запуск 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 node может разрешить все имена хостов. В рамках тестирования я снял vcache-2. Теоретически для каждой попытки взаимодействия с vcache: 22122, twemproxy свяжется с сервером из пула, чтобы облегчить попытку. Однако, если один из узлов кэша отключен, тогда twemproxy должен "автоматически извлечь" его из пула, поэтому последующие запросы не будут терпеть неудачу.

До уровня приложения зависит от того, был ли неудачный интерфейс попыткой с vcache: 22122 был вызван проблемой инфраструктуры, и если да, повторите попытку. Однако я нахожу, что при повторном запуске используется тот же неудачный сервер, поэтому вместо последующих попыток, передаваемых в известный хороший кеш node (в данном случае vcache-1), они все еще передаются в выгруженный кеш node (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 script закрытием соединения и повторной попыткой, прежде чем twemproxy не выполнил свою первую попытку и удалил сервер из пула? Возможно, добавление значения timeout в twemproxy ниже таймаута соединения, используемого в PHP, решает проблему.

Из вашего обсуждения на Github, хотя это звучит как поддержка healthcheck и, возможно, автоматический выброс, нестабильны в twemproxy. Если вы строите против старых пакетов, вам может быть лучше найти пакет, который был стабильным в течение некоторого времени. mcrouter (с интересная статья) подходит?