Twitter - twemproxy - memcached - nie ponowić próbę działa zgodnie z oczekiwaniami

Question

prosta konfiguracja:

• 1 węzeł działa twemproxy (VCache: 22122)
• 2 węzły działające memcached (sterownik Vcache-1 VCache-2) zarówno słuchanie na 11211

mam następujący twemproxy config:

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 węzeł może rozwiąż wszystkie hosty. W ramach testów zdjąłem vcache-2. W teorii przy każdej próbie połączenia się z vcache: 22122, twemproxy skontaktuje się z serwerem z puli, aby ułatwić próbę. Jeśli jednak jeden z węzłów pamięci podręcznej jest wyłączony, to twemproxy ma "automatycznie wyrzucać" go z puli, więc kolejne żądania nie zawiodą.

To od warstwy aplikacji zależy, czy nieudana próba połączenia z vcache: 22122 była spowodowana problemem infrastruktury, a jeśli tak, spróbuj ponownie. Jednak widzę, że przy ponownym użyciu, używany jest ten sam serwer, który się nie udał, więc zamiast kolejnych prób przekazanych do znanego dobrego węzła pamięci podręcznej (w tym przypadku vcache-1), nadal są one przekazywane do wyrzuconego węzła pamięci podręcznej (vcache) -2).

Oto fragment kodu php, który próbuje się powtórzenie:

.... 

// $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; 

- Update -

Link do kwestia otwarta Github o więcej informacji: Issue #427

Answer 1

mogę” • Widzisz coś nie tak z twoją konfiguracją. Jak wiesz, ważne ustawienia są ustawione:

default: 
    auto_eject_hosts: true 
    server_failure_limit: 1 

Dokumentacja sugeruje, że problem z przekroczeniem limitu czasu połączenia może być problemem.

Opierając się tylko na limity czasu po stronie klienta ma niekorzystnego wpływu pierwotnego wniosku mającego Upłynął limit czasu na połączenie klienta z serwera proxy, ale nadal w toku i znakomita na proxy do połączenia z serwerem. To dodatkowo się zaostrza, gdy klient ponownie próbuje oryginalnego żądania.

Czy twój skrypt PHP zamyka połączenie i ponawia próbę, zanim twemproxy nie podjął pierwszej próby i usunął serwer z puli? Być może dodanie wartości timeout w twemproxy niższej niż czasu oczekiwania połączenia używanego w PHP rozwiązuje problem.

Z twojej dyskusji na Githubie chociaż to brzmi jak wsparcie dla zdrowia, i być może auto wyrzucanie, nie są stabilne w twemproxy. Jeśli budujesz na starych pakietach, może lepiej znaleźć pakiet, który był stabilny przez jakiś czas. Czy mcrouter (z interesting article) jest odpowiedni?

Answer 2

Aby funkcja ta mogła działać należy łączyć z tym repo/oddziału

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

mieć ten specyficzny popełnić

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

oto PR

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

po tym przekompilowaniu go