tutorial labs commands aws redis

labs - redis vs mongodb



Redis Sentinel vs clustering (6)

Entiendo que redis sentinel es una forma de configurar HA (alta disponibilidad) entre múltiples instancias de redis. Como veo, hay una instancia de redis que atiende activamente las solicitudes del cliente en un momento dado. Hay dos servidores adicionales en espera (esperando que ocurra una falla, por lo que uno de ellos puede estar en acción nuevamente).

  • ¿Es desperdicio de recursos?
  • ¿Hay una mejor manera de usar el uso completo de los recursos disponibles?
  • ¿Redis clustering es una alternativa a Redis centinela?

Ya busqué la documentación de redis para sentinel y clustering , ¿alguien con experiencia puede explicar por favor?

ACTUALIZAR

OKAY. En mi escenario de implementación real, tengo dos servidores dedicados para redis. Tengo otro servidor que mi servidor Jboss está ejecutando. La aplicación que se ejecuta en Jboss está configurada para conectarse al servidor maestro redis (M).

Escenario de conmutación por error

Idealmente, creo que cuando falla el servidor de caché maestro (el proceso de Redis falla o la máquina falla) la aplicación en Jboss necesita conectarse al servidor de caché esclavo. ¿Cómo configuraría los servidores redis para lograr esto?

+--------+ +--------+ | Master |---------| Slave | | | | | +--------+ +--------+ Configuration: quorum = 1


Esta no es una respuesta directa a su pregunta, pero piense que es información útil para los novatos de Redis, como yo. También esta pregunta aparece como el primer enlace en google cuando se busca el "clúster Redis vs centinela".

Redis Sentinel es el nombre de la solución de alta disponibilidad de Redis ... No tiene nada que ver con Redis Cluster y está destinado a ser utilizado por personas que no necesitan Redis Cluster, sino simplemente una forma de realizar una conmutación por error automática cuando un maestro La instancia no funciona correctamente.

Tomado del borrador 1.3 del diseño de Redis Sentinel

No es obvio cuando es nuevo en Redis e implementa una solución de conmutación por error. Las documentaciones oficiales sobre sentinel y clustering no se comparan entre sí, por lo que es difícil elegir la forma correcta sin leer toneladas de documentaciones.


Esto es lo que entiendo después de golpearme la cabeza a través de la documentación.

Sentinel es un tipo de solución de espera activa en la que los esclavos se mantienen replicados y listos para ser promovidos en cualquier momento. Sin embargo, no admitirá ninguna escritura de múltiples nodos. Los esclavos se pueden configurar para operaciones de lectura. NO es cierto que Sentinel no proporcione HA, tiene todas las características de un clúster activo-pasivo típico (aunque ese no es un término correcto para usar aquí).

El clúster de Redis es más o menos una solución distribuida, que funciona sobre fragmentos. Cada porción de datos se distribuye entre nodos maestros y esclavos. Un factor de replicación mínimo de 2 asegura que tenga dos fragmentos activos disponibles entre el maestro y los esclavos. Si conoce el fragmentación en Mongo o Elasticsearch, será fácil ponerse al día.


La recomendación, en todas partes, es comenzar con un número impar de instancias, sin usar dos o un múltiplo de dos. Eso fue corregido, pero corrijamos algunos otros puntos.

Primero, decir que Sentinel proporciona conmutación por error sin HA es falso. Cuando tiene conmutación por error, tiene HA con el beneficio adicional de replicar el estado de la aplicación. La distinción es que puede tener HA en un sistema sin replicación (es HA pero no tolera fallas).

En segundo lugar, ejecutar un centinela en la misma máquina que su instancia de redis de destino no es una "mala configuración": si pierde su centinela, su instancia de redis o toda la máquina, los resultados son los mismos. Esa es probablemente la razón por la cual cada ejemplo de tales configuraciones muestra que ambas se ejecutan en la misma máquina.


Primero, hablemos centinela.

Sentinel gestiona la conmutación por error, no configura Redis para HA. Es una distinción importante. En segundo lugar, el diagrama que publicó es en realidad una configuración incorrecta: no desea ejecutar Sentinel en el mismo nodo que los nodos Redis que está administrando. Cuando pierdes a ese anfitrión, pierdes a ambos.

En cuanto a "¿Es desperdicio de recursos?" Depende de su caso de uso. No necesita tres nodos Redis en esa configuración, solo necesita dos. Tres aumenta su redundancia, pero no es obligatorio. Si necesita la redundancia agregada, entonces no es una pérdida de recursos. Si no necesita redundancia, simplemente ejecute una única instancia de Redis y califíquela, ya que ejecutar más sería "desperdiciado".

Otra razón para ejecutar dos esclavos sería dividir las lecturas. Una vez más, si lo necesita, no sería un desperdicio.

En cuanto a "¿Hay una mejor manera de usar el uso completo de los recursos disponibles?" no podemos responder eso, ya que depende demasiado de su escenario y código específicos. Dicho esto, si la cantidad de datos a almacenar es "pequeña" y la velocidad de comando no es excesivamente alta, recuerde que no necesita dedicar un host a Redis.

Ahora para "¿Redis clustering es una alternativa a Redis centinela?". Realmente depende completamente de su caso de uso. Redis Cluster no es una solución HA, es una solución de escritor múltiple / más grande que ram. Si su objetivo es solo HA, entonces probablemente no sea adecuado para usted. Redis Cluster viene con limitaciones, particularmente en torno a operaciones de teclas múltiples, por lo que no es necesariamente una operación sencilla de "solo usar clúster".

Si cree que tener tres hosts que ejecutan Redis (y tres centinelas en ejecución) es un desperdicio, es probable que tenga Cluster aún más, ya que requiere más recursos.

Las preguntas que ha formulado son probablemente demasiado amplias y basadas en opiniones para sobrevivir tal como están escritas. Si tiene un caso / problema específico que está resolviendo, actualícelo para que podamos brindarle asistencia e información específicas.

Actualización para detalles:

Para una gestión de conmutación por error adecuada en su escenario, iría con 3 centinelas, uno que se ejecuta en su servidor JBoss. Si tiene 3 nodos JBoss, vaya con uno en cada uno. Tendría un pod Redis (maestro + esclavo) en nodos separados, y dejaría que Sentinel gestionara la conmutación por error.

A partir de ahí, se trata de conectar JBoss / Jedis para usar Sentinel para su gestión de información y conexión. Como no los uso, aparece una búsqueda rápida de que Jedis tiene el soporte para ello, solo necesita configurarlo correctamente. Algunos ejemplos que encontré están en Buscando un ejemplo de Jedis con Sentinel y https://github.com/xetorthio/jedis/issues/725 que hablan de que JedisSentinelPool es la ruta para usar una piscina.

Cuando Sentinel ejecuta una conmutación por error, los clientes se desconectarán y Jedis (¿debería?) Manejar la reconexión preguntando a los Sentinels quién es el maestro actual.


Redis Sentinel realiza las réplicas de promoción de conmutación por error cuando ven que un maestro está inactivo. Por lo general, desea un número impar de nodos centinela. Para el ejemplo de un maestro y una réplica, se deben usar 3 centinelas para que haya un consenso sobre la decisión. Idealmente, el tercer centinela está en un tercer servidor, por lo que la decisión no está sesgada (dependiendo de la falla). Sentinel se encarga de cambiar la configuración de configuración maestra / réplica en sus nodos para que la promoción y la sincronización se realicen en el orden correcto y no sobrescriba los datos al traer un antiguo maestro fallido que ahora contiene datos más antiguos.

Una vez que haya configurado sus nodos centinela para realizar failovers, debe asegurarse de que está apuntando a la instancia correcta. Vea un ejemplo de configuración HAProxy para esto . HAProxy realiza comprobaciones de estado y señalará al nuevo maestro si se produce un error.

El agrupamiento le permitirá escalar horizontalmente y puede ayudar a manejar cargas altas. Se necesita un poco de trabajo para configurar y configurar por adelantado.

Hay una bifurcación de código abierto de Redis, "KeyDB" que ha eliminado la necesidad de nodos centinela con una opción de réplica activa. Esto permite que el nodo de réplica acepte lecturas y escrituras. Cuando se produce una conmutación por error, HAProxy detiene las lecturas / escrituras con el nodo fallido y solo usa el nodo activo restante que ya está sincronizado. La marca de tiempo permite que los nodos fallidos vuelvan a unirse automáticamente y se vuelvan a sincronizar sin perder datos cuando vuelvan a estar en línea. La configuración es simple y para un mayor tráfico no necesita una configuración inicial especial para dirigir las lecturas al nodo de réplica y leer / escribir en el maestro. Vea el ejemplo de replicación activa aquí . KeyDB también es multiproceso, lo que para algunas aplicaciones podría ser una alternativa al agrupamiento, pero realmente depende de cuáles sean sus necesidades.

También hay un ejemplo de configuración de agrupación manual y con la herramienta create-cluster . Estos son los mismos pasos si está utilizando Redis (reemplace ''keydb'' con ''redis'' en las instrucciones)


Redis puede operar en clúster particionado (con muchos maestros y esclavos de esos maestros) o en un modo de instancia única (maestro único con réplicas de esclavos).
El link aquí dice:

Cuando se usa Redis en modo de instancia única, en el que un solo servidor Redis administra la base de datos sin particionar, Redis Sentinel se usa para administrar su disponibilidad

También dice:

Un clúster de Redis, en el que los datos se dividen entre varias instancias primarias, administra la disponibilidad por sí mismo y no requiere componentes adicionales.

Por lo tanto, HA puede garantizarse en los 2 escenarios mencionados. Espero que esto aclare las dudas. Redis cluster y centinelas no son alternativas entre sí. Solo se utilizan para garantizar HA en diferentes casos de maestro particionado o no particionado.