¿Alguien tiene alguna idea de cómo GitHub se ocupa de la falla potencial o la falta de disponibilidad temporal de un servidor Redis al usar Resque?¿El comportamiento de falla de Redis y Resque de GitHub?
Hay otros que parecen haber reunido soluciones semi-complicadas como un holdover para redis-cluster usando zookeeper (ver https://github.com/ryanlecompte/redis_failover y Solutions for resque failover redis). Otros parecen tener una "conmutación por error de los pobres" que cambia el esclavo al maestro a primera vista de los problemas de conectividad sin coordinación entre los clientes redis (pero esto parece problemático en el escenario de indisponibilidad temporal).
La pregunta: ¿Alguna vez ha hablado Defunkt sobre cómo GitHub maneja la falla de Redis? ¿Existe una mejor práctica para la conmutación por error que no involucre al cuidador del zoológico?
La publicación original en resque establece que parte de la selección de Redis era la capacidad maestro-esclavo de redis, pero la publicación no describe cómo GitHub aprovecha esto ya que todos los trabajadores necesitan acceso de lectura y escritura a Redis (ver https://github.com/blog/542-introducing-resque).
es lo más parecido a una respuesta que he visto! Gracias por mencionarlo. Al final del día, todo lo que escribí desde la publicación original con Resque funcionó de manera tal que una falla de redis no importó. P.ej. Realizaba un seguimiento de las tareas específicas que ocurrirían una vez que utilizaba una entrada de base de datos separada para que los trabajos perdidos pudieran verificarse y volver a ejecutarse, también creaba mis aplicaciones de modo que todos los trabajos programados no tuvieran importancia si se perdía una programación del trabajo. Hubiera ayudado si esto estuviera más claramente documentado por resque pero c'est la vie. –