¿Qué debería hacer una solución de clúster de Redis?
En primer lugar, ya sea que utilicemos nuestro propio host físico o un host de servicio en la nube, los recursos de memoria a menudo son limitados y la expansión hacia arriba no es una buena manera. Necesitamos expandirnos horizontalmente hacia afuera, lo que requiere mucho. de Un host proporciona servicios, es decir, varias instancias distribuidas de Redis se ejecutan en serie.
En segundo lugar, el costo actual de los recursos de hardware se reduce y los hosts con CPU de múltiples núcleos y docenas de GB de RAM son muy comunes para Redis, cuyo proceso principal es el trabajo de un solo subproceso, ejecutando solo un. una sola instancia es un poco derrochador. Al mismo tiempo, administrar una memoria enorme no es tan eficiente como administrar una memoria relativamente pequeña. Por lo tanto, en la práctica, es común ejecutar varias instancias de Redis simultáneamente en una sola máquina.
Programa
1. Programa de clúster oficial de Redis Redis Cluster
Redis Cluster es una tecnología de fragmentación de servidores, lanzada oficialmente desde la versión 3.0.
Redis
La fragmentación del clúster adopta el concepto de ranura, dividiendo un servidor en 16384 ranuras, que es diferente al anterior mencionado anteriormente
La idea de La fragmentación es algo similar. Para cada par clave-valor que ingresa a Redis, se compara con el valor clave y se asigna a una de las 16384 ranuras. El algoritmo hash utilizado también es relativamente simple
, es decir, el modo CRC16 se adopta después de 16384.
Cada nodo del cluster Redis se encarga de compartir parte de los 16384 slots, es decir, cada
slot corresponde a un nodo responsable del procesamiento. Al agregar o reducir nodos dinámicamente, es necesario reasignar 16384 ranuras y migrar los valores clave en las ranuras. Por supuesto, en la implementación actual, este proceso
sigue siendo semiautomático y requiere intervención manual.
En el clúster de Redis, es necesario garantizar que los nodos correspondientes a las 16384 ranuras puedan funcionar normalmente. Si un nodo falla, la ranura de la que es responsable también fallará y no todo el clúster. trabajar. .
Para
mejorar la accesibilidad del clúster, la solución recomendada oficialmente es configurar el nodo como una estructura maestro-esclavo, es decir, un nodo maestro y n nodos esclavos. . En este momento, si el nodo maestro falla
, el clúster de Redis seleccionará un nodo maestro en ascenso entre los nodos esclavos de acuerdo con el algoritmo de elección y todo el clúster continuará brindando servicios al mundo exterior. Esto es muy similar al escenario de aplicación de Redis
Sharding, es decir, los nodos del servidor forman una estructura maestro-esclavo a través del bastidor de monitoreo Sentinel, excepto que Redis Cluster proporciona tolerancia a fallas de conmutación por error.
Redis
La razón por la que el clúster puede identificar nuevos nodos, determinar fallas y realizar conmutación por error es porque cada nodo del clúster se comunica con otros nodos. Este es el llamado clúster <. /p>
Autobús. Utilizan un número de puerto especial, que es el número de puerto del servicio externo más 10000. Por ejemplo, si el número de puerto de un nodo es 6379, entonces se comunica con otros nodos a través del número de puerto
16379. Los nodos se comunican entre sí mediante un protocolo binario especial.
Para el cliente, todo el clúster se ve como un todo y el cliente puede conectarse a cualquier nodo
y operar en él como si fuera una instancia de Redis. Cuando el cliente opera con una clave que no está asignada al nodo, Redis devolverá una instrucción de redirección que apunta al nodo correcto, que es un poco como un salto de redirección 302 en una página del navegador.
El clúster de Redis se lanzó oficialmente después de que Redis 3.0 se lanzara tarde. No hay muchos casos exitosos que se hayan verificado en entornos de producción a gran escala, por lo que lleva tiempo realizar pruebas.
2. Redis Sharding Cluster
Redis 3 lanzó oficialmente la tecnología de clúster oficial, resolviendo el problema de que varias instancias de Redis funcionen juntas. Se puede decir que Redis Cluster es la encarnación de la tecnología de fragmentación del lado del servidor, es decir, los valores clave se asignan razonablemente a cada fragmento de instancia de acuerdo con un determinado algoritmo. Al mismo tiempo, cada nodo de instancia coordina la comunicación para proporcionar servicios consistentes. al mundo exterior.
Los servicios de varias instancias de Redis son más complejos que las instancias únicas de Redis e implican dificultades técnicas como posicionamiento, colaboración, tolerancia a fallas y expansión de capacidad. Aquí, presentamos una tecnología de cliente ligero Redis Sharding.
Redis
Se puede decir que la fragmentación es un método comúnmente utilizado en la industria para agrupar múltiples instancias de Redis antes de la aparición de Redis
Cluster. La idea principal es utilizar un algoritmo hash para codificar las claves de los datos de Redis y asignar claves específicas a nodos de Redis específicos a través de la función hash. La arquitectura de fragmentación se muestra en la figura:
Afortunadamente, el controlador del cliente Java Redis jedis admite la función de fragmentación de Redis, a saber: ShardedJedis y ShardedJedis,
fragmentación de Redis de Jedis La implementación del fragmento tiene las siguientes características:
Utiliza un algoritmo hash consistente
(consistent
hash), es decir, aplica un hash tanto a la clave como a las columnas del nombre del nodo y luego las asigna. unirlos, utilizando el algoritmo MURMUR_HASH. Utilice hash consistente en lugar de clases simples
La razón principal para el mapeo modal como el hash es que cuando se agregan o restan nodos, no habrá repetición debido a la recoincidencia. El hash consistente solo afecta las asignaciones de claves de los nodos adyacentes y el impacto es pequeño.
2.
Para evitar la presión de asignación de nodos causada por un hash consistente que solo afecta a los nodos adyacentes, a ShardedJedis se le asignará un nombre predeterminado) para hash virtual
160 nodos virtuales. Dependiendo del peso, también se pueden virtualizar múltiplos de 160 nodos virtuales. El uso de la coincidencia de mapas de nodos virtuales permite mover y redistribuir las claves de manera más uniforme entre los nodos de Redis al agregar o restar nodos de Redis
en lugar de afectar solo a los nodos adyacentes.
3.ShardedJedis admite el modo keyTagPattern, que puede extraer parte de la keyTag para fragmentarla, por lo que al nombrar la clave apropiadamente, se puede colocar un grupo de claves relacionadas en los mismos nodos de Redis, esto es importante para Evite el acceso a datos relacionados entre nodos.
La fragmentación de Redis utiliza fragmentación del lado del cliente, mientras que Redis del lado del servidor sigue siendo un nodo de instancia de Redis relativamente independiente y no habrá cambios. Al mismo tiempo, no necesitamos agregar componentes de procesamiento intermedio adicionales. Este es un método de agrupación de instancias múltiples de Redis muy liviano y flexible.
Por supuesto, este enfoque liviano y flexible para la fragmentación de Redis inevitablemente afectará otras funciones del clúster. Por ejemplo, durante la expansión, cuando desee agregar nodos de Redis, aunque se utilice un hash coherente, no se perderá la coincidencia de claves. En este caso, se requiere la migración de valores clave.
Como fragmento de cliente liviano, no es práctico manejar las migraciones de valores clave de Redis, lo que requiere que la capa de aplicación permita la pérdida de datos en Redis o recargue datos desde la base de datos backend. Sin embargo, a veces, acceder directamente a la capa de caché y acceder a la capa de base de datos ejercerá mucha presión sobre el acceso al sistema.
¿Existen otras formas de mejorar esta situación?
Redis
El autor ofrece un método más conveniente: fragmentación previa, es decir, implementar tantas instancias de Redis como sea posible de acuerdo con la escala del sistema por adelantado. Estas instancias ocupan el sistema. Los recursos son muy pequeños y una máquina física se puede implementar en varios departamentos. Cuando se requiere expansión, seleccione una instancia como nodo maestro y use el nodo Redis recién agregado como nodo esclavo para la replicación de datos. Después de sincronizar los datos, modifique la configuración de fragmentación
para que los fragmentos que apuntan a la instancia original apunten al nodo Redis expandido en la nueva máquina. Al mismo tiempo, ajuste el nuevo nodo Redis como maestro. El nodo y la instancia original ya no se pueden utilizar.
La fragmentación previa
se refiere a asignar suficientes fragmentos por adelantado para que, al escalar, solo las instancias de Redis originales que pertenecen a un fragmento específico se reemplacen con un nuevo Redis con mayor capacidad. Solo un ejemplo . Los fragmentos involucrados en la fragmentación no cambiarán, por lo que
los valores clave no se transferirán de una región a otra, pero los valores clave que pertenecen al mismo fragmento solo se sincronizarán desde la instancia de Redis original a la instancia de New Redis.
La causa del problema de pérdida de valor clave no es solo la adición de nodos de Redis.
La eliminación, el mayor obstáculo proviene del tiempo de inactividad repentino del nodo de Redis. Como se menciona en el artículo "Persistencia de Redis", para no afectar el rendimiento de Redis, intente no habilitar las funciones de guardado de archivos AOF y RDB. Puede configurar el modo principal y el modo de copia de seguridad de Redis. los datos no se perderán y la copia de seguridad de Redis permanece respaldada.
De esta manera, nuestro patrón arquitectónico se convierte
Un segmento de nodo de Redis que contiene un Redis primario y un Redis de respaldo. Cuando el Redis principal deja de funcionar, el Redis de respaldo toma el control y se convierte en el Redis principal para continuar brindando servicios. Primario
El **** de respaldo funciona con los nodos de Redis para garantizar una alta disponibilidad de los nodos a través de la conmutación por error automática. La arquitectura de fragmentación luego evolucionó a:
Redis Sentinel proporciona capacidades de monitoreo y conmutación por error de Redis en modo activo/en espera para lograr una alta disponibilidad del sistema.
Con un gran volumen de acceso, incluso si se utiliza Sharding, un solo nodo seguirá soportando mucha presión de acceso. En este momento, debemos descomponerlo aún más. Por lo general, las operaciones de lectura y escritura de las aplicaciones que acceden a Redis son muy diferentes. La lectura suele ser un múltiplo de la escritura. En este momento, podemos separar la lectura y la escritura y proporcionar más instancias para la lectura.
Puede utilizar el modelo maestro-esclavo para lograr la separación de lectura y escritura. La estación maestra es responsable de la escritura y la estación esclava es responsable de solo lectura. Al mismo tiempo, una estación maestra puede hacerlo. conecte varias estaciones esclavas. El monitoreo Sentinel también garantiza el monitoreo automático de fallas de nodos.
3. Utilice middleware proxy para implementar clústeres de Redis a gran escala.
Lo anterior presenta los dos métodos de fragmentación de Redis y clúster de Redis basados en fragmentación del lado del cliente y fragmentación del lado del servidor. Los servidores Redis están agrupados. La ventaja de la tecnología de fragmentación es que las instancias de Redis del lado del servidor son independientes entre sí y no están relacionadas entre sí. Cada instancia de Redis se ejecuta como un único servidor, lo que facilita la expansión lineal y el sistema es muy flexible. Sus deficiencias son:
El procesamiento de fragmentación se encuentra en el lado del cliente, lo que traerá desafíos para la operación y el mantenimiento a medida que se expanda la escala.
Cuando cambia la topología del clúster de instancias de Redis del lado del servidor, es necesario actualizar y ajustar cada cliente.
No se puede garantizar la conexión y, cuando se amplía la escala de la aplicación, el desperdicio de recursos restringirá la optimización.
La ventaja del clúster de Redis fragmentado del lado del servidor es que el cliente no necesita conocer los cambios en la topología del clúster de Redis del lado del servidor y el cliente puede utilizar el clúster de Redis como un único servidor Redis. simplificando así la operación y el mantenimiento se vuelve más fácil.
Sin embargo, la versión oficial del clúster Redis no se ha lanzado en mucho tiempo y lleva tiempo probar la estabilidad y el rendimiento del sistema, especialmente en aplicaciones a gran escala.
¿Podemos combinar lo mejor de ambos mundos? Es decir, ¿no solo puede hacer que las instancias del lado del servidor sean independientes entre sí y admitir la expansión lineal, sino también centralizar la fragmentación para facilitar la administración unificada? El middleware proxy Redis twemproxy presentado en este artículo es una tecnología de fragmentación de middleware.
Twemproxy se ubica entre el cliente y el servidor, recibe la solicitud del cliente, realiza algún procesamiento (como fragmentación) y luego reenvía la solicitud al servidor Redis real en el backend. En otras palabras, el cliente no accede directamente al servidor Redis, sino indirectamente a través del middleware proxy twemproxy.
En referencia a la arquitectura Redis Sharding, la arquitectura del clúster Redis con middleware proxy agregado es la siguiente:
El procesamiento interno del middleware twemproxy no tiene estado y puede agruparse fácilmente, por lo que evitando tensiones o fallos en un solo punto.
twemproxy, también conocido como cascanueces, se originó a partir de la práctica de desarrollo del clúster redis/memcached en el sistema Twitter. Después de ejecutarse bien, el código se dedicó a la comunidad de código abierto. Es liviano y eficiente, desarrollado en lenguaje C. La URL del proyecto es: GitHub - twitter/twemproxy: un proxy rápido y liviano para memcached y redis
El backend de twemproxy no solo admite redis, sino también memcached <. /p>
El backend de twemproxy no solo admite redis, sino que también admite memcached, que está determinado por el entorno específico del sistema de Twitter.
Debido al uso de middleware, twemproxy puede disfrutar plenamente de la conexión con el sistema back-end, reduciendo así la cantidad de veces que el cliente establece una conexión directamente con el servidor back-end. Al mismo tiempo, también proporciona funcionalidad de fragmentación para admitir la expansión horizontal de clústeres de servidores back-end. La gestión unificada de operación y mantenimiento también aporta comodidad.
Por supuesto, debido al uso de un proxy de middleware, habrá una pérdida de rendimiento en comparación con la forma en que el cliente se conecta directamente al servidor, y los resultados de la prueba son aproximadamente un 20% más bajos.