Para cargas de trabajo con un alto volumen de lecturas, Tair (Redis OSS-compatible) permite habilitar o deshabilitar dinámicamente la separación de lectura y escritura. Esta función ofrece una solución de alta disponibilidad y alto rendimiento para el acceso centralizado a datos frecuentes y lecturas con alta concurrencia. En una instancia con separación de lectura y escritura, un componente de proxy desarrollado por el equipo de Tair de Alibaba Cloud identifica y enruta automáticamente las solicitudes de lectura y escritura, además de gestionar los failovers. Esto simplifica la integración, ya que no es necesario modificar el código de la aplicación para administrar el enrutamiento de solicitudes o los failovers.
Separación de lectura y escritura en arquitectura estándar
Una instancia con separación de lectura y escritura que utiliza la arquitectura estándar consta de un nodo maestro, una o más réplicas de lectura, servidores proxy y un sistema de alta disponibilidad. Las siguientes figuras muestran las arquitecturas.
Figura 1. Cloud-native
Figura 2. Classic (descontinuada)
Componente | Cloud-native | Classic (descontinuada) |
Nodo maestro | Procesa las solicitudes de escritura y comparte la carga de lectura con las réplicas de lectura. | |
Réplicas de lectura | Procesan las solicitudes de lectura. Las réplicas de lectura tienen las siguientes funciones:
| Procesan las solicitudes de lectura. Las réplicas de lectura tienen las siguientes funciones:
|
Nodo de réplica | Cualquier réplica de lectura puede servir como nodo de réplica. Si el nodo maestro falla, el sistema de alta disponibilidad promueve la réplica de lectura con los datos más completos para convertirla en el nuevo nodo maestro. Después del cambio, se agrega inmediatamente una nueva réplica de lectura a la instancia. Dado que no se requiere un nodo de réplica dedicado, las instancias cloud-native con separación de lectura y escritura ofrecen el mismo rendimiento a un costo menor. | Un nodo en espera fría para la copia de seguridad de datos. No procesa tráfico. Si el nodo maestro falla, las solicitudes se redirigen a este nodo mediante failover. |
Servidor proxy | Cuando un cliente se conecta, el servidor proxy identifica automáticamente el tipo de solicitud y distribuye el tráfico a los diferentes nodos de datos por peso. Todos los nodos tienen pesos iguales y estos no son personalizables. Por ejemplo, las solicitudes de escritura se reenvían al nodo maestro, y las solicitudes de lectura se reenvían al nodo maestro y a las réplicas de lectura. Nota
| |
Sistema de alta disponibilidad |
| |
Cloud-native (recomendado) | Classic (descontinuada) |
Tanto la zona principal como la secundaria proporcionan servicios. La configuración mínima es la siguiente:
Las zonas principal y secundaria tienen endpoints separados. Ambos endpoints admiten operaciones de lectura y escritura. Las solicitudes de lectura de la zona principal se enrutan únicamente al nodo maestro o a las réplicas de lectura dentro de esa zona. Las solicitudes de lectura de la zona secundaria se enrutan solo a las réplicas de lectura en dicha zona. Esta arquitectura permite el acceso basado en proximidad. Todas las solicitudes de escritura se enrutan al nodo maestro en la zona principal. La siguiente figura muestra la arquitectura.  Nota Se recomienda configurar dos o más nodos tanto en la zona principal como en la secundaria:
| La zona secundaria contiene únicamente un nodo de réplica en espera fría para la copia de seguridad de datos y no procesa tráfico. Si el nodo maestro falla, las solicitudes se redirigen al nodo de réplica mediante failover. |
Funciones
-
Dinámica y fácil de usar
Es posible habilitar la separación de lectura y escritura para una instancia que utiliza la arquitectura estándar. El servidor proxy identifica y reenvía inteligentemente las solicitudes de lectura y escritura de los clientes. Tras habilitar esta función, se puede utilizar cualquier cliente compatible con Redis para conectarse a la instancia con separación de lectura y escritura y mejorar el rendimiento de lectura sin modificar la aplicación. Las instancias con separación de lectura y escritura habilitada son compatibles con los comandos del protocolo Redis, pero aplican algunas restricciones de comandos debido al proxy. Para obtener más información, consulte Command restrictions for read/write splitting instances.
-
Alta disponibilidad
Un sistema propietario de alta disponibilidad de Alibaba Cloud monitorea automáticamente el estado de todos los nodos de datos para garantizar la disponibilidad de la instancia. Si un nodo maestro deja de estar disponible, el sistema selecciona automáticamente un nuevo nodo maestro y reconstruye la topología de replicación. Si una réplica de lectura falla, el sistema de alta disponibilidad detecta automáticamente el error, lanza un nuevo nodo para completar la sincronización de datos y desconecta el nodo fallido.
Los servidores proxy monitorean el estado del servicio de cada réplica de lectura en tiempo real. Si una réplica de lectura deja de estar disponible, el proxy reduce automáticamente su peso de servicio. Si una réplica de lectura falla más de un número especificado de veces consecutivas, el proxy suspende el servicio al nodo no disponible. Continúa monitoreando el nodo y reanuda su servicio después de que el nodo se recupera.
-
Alto rendimiento
Se pueden escalar horizontalmente las réplicas de lectura para aumentar linealmente el rendimiento general de una instancia con separación de lectura y escritura. Las optimizaciones a nivel de código fuente en el proceso de replicación de Redis maximizan la estabilidad del sistema durante la replicación lineal y aprovechan al máximo los recursos físicos de cada réplica de lectura.
Casos de uso
Esta función es ideal para escenarios con un alto volumen de consultas de lectura por segundo (QPS). Si la aplicación tiene una carga intensiva de lecturas, es posible que una instancia con arquitectura estándar no cumpla con los requisitos de QPS. En este caso, se pueden desplegar varias réplicas de lectura para superar el cuello de botella de rendimiento de un solo nodo. Al habilitar la separación de lectura y escritura, el QPS de lectura de una instancia puede aumentar hasta nueve veces.
Debido al mecanismo de replicación asíncrona de Redis, puede producirse latencia en la replicación de datos durante períodos de alto volumen de escrituras. Si utiliza esta arquitectura, la aplicación debe poder tolerar cierto grado de desactualización de los datos.
Separación de lectura y escritura en arquitectura de clúster
En una arquitectura de clúster, solo se puede habilitar la separación de lectura y escritura para instancias cloud-native que se ejecutan en modo proxy. La siguiente figura muestra un ejemplo de arquitectura.
Descripción de componentes
Componente | Descripción |
Servidor proxy | Después de que un cliente se conecta a un servidor proxy, el proxy identifica automáticamente las solicitudes del cliente y las reenvía a los shards de datos correspondientes y sus nodos de lectura/escritura asociados. Por ejemplo, las solicitudes de escritura se reenvían al nodo maestro, y las solicitudes de lectura se balancean entre el nodo maestro y las réplicas de lectura. |
Shard de datos | Cada shard de datos consta de un nodo maestro y hasta cuatro réplicas de lectura.
|
Servicio de alta disponibilidad |
|
Si la instancia se despliega en una sola zona de disponibilidad, todos los nodos se ubican en la zona principal y la instancia proporciona únicamente un endpoint para dicha zona.
Si la instancia se despliega en una configuración de zona doble, se proporcionan endpoints separados para las zonas principal y secundaria. Ambos endpoints admiten operaciones de lectura y escritura. Las solicitudes de lectura de la zona principal se enrutan al nodo maestro o a las réplicas de lectura dentro de esa zona. Las solicitudes de lectura de la zona secundaria se enrutan solo a las réplicas de lectura en dicha zona para garantizar el acceso basado en proximidad. Todas las solicitudes de escritura se enrutan al nodo maestro en la zona principal. Si todas las réplicas de lectura en la zona secundaria dejan de estar disponibles, el sistema enruta las solicitudes de lectura de esa zona al nodo maestro para garantizar la continuidad del negocio.
Recomendaciones y notas de uso
Si una réplica de lectura falla, las solicitudes se reenvían a otros nodos. Si todas las réplicas de lectura dejan de estar disponibles, todas las solicitudes de lectura se reenvían al nodo maestro. Si fallan las réplicas de lectura, la carga en el nodo maestro aumenta, lo que puede prolongar su tiempo de respuesta. Por lo tanto, se recomienda utilizar varias réplicas de lectura para cargas de trabajo intensivas en lecturas.
Si una réplica de lectura falla, el sistema de alta disponibilidad suspende el servicio al nodo fallido y lanza una nueva réplica de lectura. Este proceso implica asignación de recursos, creación de instancias, sincronización de datos y carga del servicio. El tiempo requerido depende de la carga de trabajo y el volumen de datos. Tair (Redis OSS-compatible) no garantiza un objetivo de tiempo de recuperación para las réplicas de lectura.
Un despliegue con separación de lectura y escritura en zona doble requiere que la zona principal tenga al menos un nodo maestro y una réplica de lectura. Antes de habilitar la separación de lectura y escritura para una instancia de arquitectura estándar en zona doble que tiene un nodo maestro en la zona principal y un nodo de réplica en la zona secundaria, debe agregar un nodo de réplica a la zona principal para asegurar que contenga dos nodos. Posteriormente, podrá habilitar la separación de lectura y escritura.
Algunos escenarios, como un failover de alta disponibilidad del nodo maestro, desencadenan una sincronización completa de datos en una réplica de lectura. Durante una sincronización completa, la réplica de lectura no está disponible y devuelve el mensaje
-LOADING Redis is loading the dataset in memory\r\n.Algunos comandos de lectura tienen reglas especiales de reenvío en la arquitectura de separación de lectura y escritura. Por ejemplo, el comando
SCANse reenvía al nodo maestro para su ejecución, mientras que el proxy distribuye los comandosHSCAN,SSCANyZSCANuniformemente entre el nodo maestro y las réplicas de lectura basándose en un cálculo de módulo de slot. Para conocer el conjunto completo de reglas de reenvío, consulte Proxy routing rules.
Requisitos previos
Antes de empezar, asegúrese de que:
La instancia esté desplegada en modo cloud-native
La instancia sea una Redis Open-Source Edition o una instancia Tair (Enterprise Edition) optimizada para DRAM o memoria persistente
La instancia tenga al menos 1 GB de memoria
La instancia sea de alta disponibilidad
Procedimiento
Si no ha creado una instancia, puede habilitar la separación de lectura y escritura cuando create an instance.
Si ya cuenta con una instancia cloud-native, puede directamente enable read/write splitting.
Preguntas frecuentes
-
P: ¿Habilitar la separación de lectura y escritura para una instancia de arquitectura estándar aumenta su ancho de banda total?
R: Sí. Después de habilitar la separación de lectura y escritura, el ancho de banda total teórico de la instancia es el ancho de banda de la especificación de la instancia multiplicado por el número total de nodos (por ejemplo, 96 MB/s × 3 nodos = 288 MB/s). Los nodos proxy agregados reenvían la mayoría de las solicitudes de lectura a las réplicas de lectura, lo que reduce la presión de ancho de banda en el nodo maestro. Sin embargo, el ancho de banda real se ve afectado por factores como las solicitudes del negocio y los clientes. El ancho de banda real está sujeto a los resultados de las pruebas de estrés.
-
P: Después de habilitar la separación de lectura y escritura para una instancia de arquitectura estándar, ¿puedo cambiar su arquitectura a la arquitectura de clúster?
R: Sí. Primero debe disable read/write splitting y luego change the instance architecture.
-
P: ¿Cómo compruebo si la separación de lectura y escritura está habilitada?
R: Puede ir a la página Node Management de la instancia para comprobar si la opción read/write splitting está habilitada.
-
P: ¿Por qué las solicitudes de lectura no se enrutan a mis réplicas de lectura?
R: En una arquitectura de separación de lectura y escritura en zona doble, las zonas principal y secundaria tienen endpoints separados. Las solicitudes de lectura se enrutan únicamente al nodo maestro o a las réplicas de lectura dentro de la misma zona. Si utiliza solo el endpoint de la zona principal, ninguna solicitud de lectura se enrutará a las réplicas de lectura en la zona secundaria. Para habilitar el acceso basado en proximidad y el balanceo de carga, debe diferenciar explícitamente los endpoints de las zonas principal y secundaria en el código de su aplicación y enrutar las solicitudes de la zona secundaria a su endpoint específico.