Voy a iniciar una serie de posts sobre Redis. Al igual que hicimos con Kafka y su ecosistema (básicamente Zookeeper) veremos:

  1. Introducción a Redis y Redis-Sentinel
  2. Instalación y configuración de Redis y Redis-Sentinel
  3. Monitorización de Redis con el PRTG
  4. Operaciones habituales con Redis

Redis es un motor de base de datos en memoria, basado en el almacenamiento en tablas de hashes (clave/valor) pero que opcionalmente puede ser usada como una base de datos persistente. Si bien las claves se almacenan como hashes los valores están tipados, y no sólo restringidos a cadenas de texto, sino que también soporta listas, conjuntos o hashes. En esta entrada se describe una de las arquitecturas típicas más usadas comunmente. Para más información sobre el motor se puede consultar la web de documentación de redis.
En esta arquitectura de Redis en modo clúster funciona en modo master(1)-slave(n), es decir, tenemos un único master en cada momento mientras que podemos tener n slaves. Para realizar el control de dónde deben realizarse las escrituras (conocer en cada momento quien es el master), balancear las lecturas, y, en definitiva, para el control de clúster, necesitamos una capa adicional que se encargue de ello. Al igual que en Kafka usamos Zookeeper para estas tareas, en redis se usa Sentinel. Sentinel tiene básicamente las mismas funciones (y funciona de forma muy similar) a Zookeeper, es decir, controla en todo momento el estado de todos los nodos, la réplica entre ellos, etc, y en caso de caída de un nodo, se realiza un proceso de quorum para decidir qué nodo será el siguiente master.
Los datos se guardan en bases de datos enumeradas. Hay un número finitio de bases de datos que se define en los ficheros de configuración. La réplica entre los master y los slave es asíncrona, por lo tanto, es importante tener en cuenta el tipo de datos que se almacenan, ya que se puede producir pérdida de datos en caso de caída del nodo máster. La conexión a las diferentes bases de datos se realiza mediante un driver cliente (hay diversos drivers para muchos lenguajes de programación). El uso típico de este tipo de bases de datos es muy variado (puede ser usada para guardar información de datos de sesión hasta de cache centralizada previo serialización de los datos a cachear). En la empresa donde trabajo uno de los usos que se le da es el almacenar los datos de bloqueos de alojamientos. Al ser una base de datos en memoria la latencia de acceso es muy baja, sobre todo si se compara con la latencia de acceso a una base de datos relacional.

Arquitectura

El funcionamiento es el típico en los sistemas clúster. Primero, debemos tener una URL a la que acceder (por ejemplo redis.acme.es, aunque también serviría una IP) y el cliente inicialmente se conecta al Sentinel para preguntarle los datos sobre la configuración del clúster. Una vez conocemos la arquitectura podemos dirigirnos a un nodo u otro para escribir o leer. Es importante tener en cuenta que en cada servidor podemos tener más de una instancia de redis, por eso, una opción usada habitualmente es la de renombrar cada una de las instancias de forma diferente y usar un puerto diferente. Por ejemplo, si decidimos usar el puerto por defecto, podremos tener una instancia de redis y redis-sentinel con la siguiente nomenclatura:

  • REDIS: redis_{#puerto}.
  • SENTINEL: sentinel_{#puerto}.

Por ejemplo redis_6379 y sentinel_26379. Por defecto, se puede usar el puerto de redis + 20000 para la instancia de sentinel.De esta forma, si se añade otra instancia para una segunda funcionalidad podríamos llamarlas así.

  • REDIS: redis_6380.
  • SENTINEL: sentinel_26380.

De esta forma la arquitectura nos quedaría de la siguiente forma.

redis_grouped

En realidad lo que tendremos se parece más a esto:

redis_ungrouped

En este escenario, y suponiendo que el redis1.zeent.com es el nodo master. Todos los clientes se conectarían a él para conocer el estado del clúster. En realidad la conexión se realiza al sentinel de este nodo. La instancia sentinel_26379 nos indicaría qué nodo es el master en el clúster, y si la operación es de escritura lo haríamos en el. En caso contrario la lectura se podría hacer de cualquier otro nodo. En realidad no se necesita que cada conexión controlemos qué nodo es el master para conocer donde debemos escribir, sino que el driver cliente hace todas estas peticiones al inicio de la conexión y las guarda para todas las peticiones, y tiene la capacidad de adaptarse a los cambios a medida que estos se producen en el clúster.

En la siguiente entrada veremos como configurar este mismo clúster que hemos descrito a modo de ejemplo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s