Einfache Einrichtung:

1 Knoten, auf dem Twemproxy ausgeführt wird (vcache: 22122) 2 Knoten, auf denen memcached ausgeführt wird (vcache-1, vcache-2), die beide 11211 abhören

Ich habe die folgende Twemproxy-Konfiguration:

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

Der Twemproxy-Knoten kann alle Hostnamen auflösen. Im Rahmen der Tests habe ich vcache-2 heruntergefahren. Theoretisch kontaktiert twemproxy bei jedem Versuch, eine Schnittstelle zu vcache: 22122 herzustellen, einen Server aus dem Pool, um den Versuch zu vereinfachen. Wenn jedoch einer der Cache-Knoten inaktiv ist, soll Twemproxy ihn automatisch aus dem Pool entfernen, damit nachfolgende Anforderungen nicht fehlschlagen.

Es liegt an der App-Schicht, zu bestimmen, ob ein fehlgeschlagener Schnittstellenversuch mit vcache: 22122 auf ein Infrastrukturproblem zurückzuführen ist. Versuchen Sie es in diesem Fall erneut. Ich stelle jedoch fest, dass bei dem erneuten Versuch derselbe ausgefallene Server verwendet wird. Anstatt nachfolgende Versuche an einen als funktionierend bekannten Cache-Knoten (in diesem Fall vcache-1) weiterzuleiten, werden diese weiterhin an den ausgeworfenen Cache-Knoten (vcache) weitergeleitet -2).

Hier ist das PHP-Code-Snippet, das den Wiederholungsversuch versucht:

....

// $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 to Issue auf Github für weitere Informationen geöffnet:Issue # 427