La arquitectura estándar de Tair (compatible con Redis OSS) funciona sin modo clúster. Todos los datos se almacenan en un solo shard, lo que simplifica su operación, reduce costos y garantiza compatibilidad total con el protocolo Redis. A diferencia de la arquitectura de clúster, la arquitectura estándar no permite ajustar la cantidad de shards y ofrece tipos de instancia de alta disponibilidad (con varias réplicas) y de nodo único (con una sola réplica).
y de nodo único (con una sola réplica)
Tipos de arquitectura
Hay dos modos de despliegue disponibles: nativo de la nube y classic.
Arquitectura estándar nativa de la nube
Una instancia nativa de la nube admite un nodo maestro y hasta 9 replica nodes. El nodo maestro gestiona todas las cargas de trabajo de lectura y escritura. Los nodos réplica permanecen en espera activa.
Cuando se desencadena un failover entre varias zonas, el sistema intenta primero cambiar dentro de la misma zona para evitar que su aplicación acceda a recursos entre zonas distintas.
Arquitectura estándar clásica
Una instancia clásica admite un nodo maestro y un nodo réplica. En un despliegue multizona, el nodo réplica se ubica en la zona secundaria.
Funcionamiento
La arquitectura estándar utiliza un modelo maestro-réplica. El nodo maestro gestiona las cargas de trabajo diarias. Los nodos réplica permanecen en espera activa.
Si el nodo maestro falla, el sistema propietario de alta disponibilidad (HA) detecta el error y ejecuta un failover:
El sistema HA detecta el fallo del nodo maestro (error de E/S de disco, fallo de CPU o similar).
Un nodo réplica se promueve como nuevo nodo maestro.
Todo el proceso de failover se completa en menos de 30 segundos.
Arquitectura estándar frente a arquitectura de clúster
|
Capacidad |
Arquitectura estándar |
Arquitectura de clúster |
|
Distribución de datos |
Shard único |
Varios shards |
|
Ajuste de cantidad de shards |
No compatible |
Compatible |
|
Réplicas de lectura |
Hasta 9 (nativo de la nube) |
Por shard |
|
División de lectura/escritura |
Compatible |
Compatible |
|
Compatibilidad con el protocolo Redis |
Total |
Parcial (comandos de varias claves restringidos) |
|
QPS máximo recomendado |
100,000 |
Más de 200,000 |
|
Caso de uso típico |
Cargas de trabajo estables de instancia única |
Cargas de trabajo de alto throughput o gran escala |
Funciones
Confiabilidad
Confiabilidad del servicio: Los nodos maestro y réplica se ejecutan en hosts físicos separados. Si el nodo maestro falla, el sistema HA propietario ejecuta un failover automáticamente.
Confiabilidad de los datos: La persistencia de datos está habilitada de forma predeterminada; todos los datos se escriben en disco. Se admiten copias de seguridad y restauración: clone o revierta una instancia from un conjunto de copias de seguridad para recuperarse de operaciones accidentales. Las instancias ubicadas en zonas con capacidades de recuperación ante desastres (por ejemplo, Hangzhou Zone H y Zone I) son compatibles con la recuperación ante desastres entre zonas.
Compatibilidad con el protocolo Redis
La arquitectura estándar es totalmente compatible con el protocolo Redis. Migre sus cargas de trabajo from una base de datos Redis autogestionada a una instancia estándar sin interrumpir el servicio, mediante Alibaba Cloud Data Transmission Service (DTS) para la migración incremental de datos.
Mejoras propietarias en la replicación
El mecanismo de replicación maestro-réplica de Alibaba Cloud resuelve varias limitaciones de la replicación nativa de Redis:
|
Limitación de Redis nativo |
Cómo lo resuelve Tair |
|
La sincronización completa requiere un fork, lo que causa latencia de milisegundos a segundos |
Replicación sin bloqueo: se resuelve el problema del fork y se elimina la latencia inducida por la sincronización |
|
Un fallo en PSYNC desencadena una sincronización completa de Redis Database (RDB), que consume E/S de disco y CPU |
Los registros escritos con anticipación (WAL) replican los datos entre nodos; las interrupciones en la replicación tienen un impacto mínimo en el rendimiento |
|
Los procesos secundarios que realizan copy-on-write (COW) consumen memoria del nodo maestro, con riesgo de fallos por falta de memoria |
Se elimina la presión sobre la memoria causada por COW |
|
La transferencia de archivos RDB de nivel GB provoca picos de tráfico saliente y aumentos en E/S secuencial |
La replicación basada en WAL evita transferencias de archivos grandes |
Cuándo utilizar la arquitectura estándar
QPS inferior a 100,000 en una sola instancia
Redis nativo utiliza un modelo de subproceso único. La arquitectura estándar se adapta a la mayoría de las cargas de trabajo que no superan las 100,000 consultas por segundo (QPS). Si sus requisitos de QPS aumentan, habilite la división de lectura/escritura o cambie a la arquitectura de clúster.
Se requiere compatibilidad total con el protocolo Redis
La arquitectura estándar admite el protocolo Redis completo, incluidos los comandos de varias claves restringidos en el modo clúster. Migre from una base de datos Redis autogestionada o Redis Sentinel sin modificar el código de la aplicación.
Uso de Redis como almacenamiento persistente
La persistencia de datos, las copias de seguridad y la restauración a un punto específico en el tiempo vienen integradas. Utilice las copias de seguridad para clonar una instancia o revertirla tras cambios accidentales en los datos.
Carga de trabajo intensiva en lecturas con pocos comandos de ordenamiento o cómputo intensivo
Habilite la división de lectura/escritura para escalar el throughput de lectura. Para cargas de trabajo de ordenamiento o cómputo intensivas en CPU a gran escala, utilice la arquitectura de clúster.
Preguntas frecuentes
Estoy ejecutando Redis en modo Sentinel. ¿Qué arquitectura debo elegir al migrar a la nube?
Elija la arquitectura estándar de alta disponibilidad y luego habilite Sentinel-compatible mode en la instancia. Esto le permite conectarse a Tair de la misma manera que a Redis Sentinel, sin necesidad de modificar el código de la aplicación.
Mi instancia tiene 8 GB de memoria con la arquitectura estándar. ¿Cómo puedo mejorar el rendimiento sin aumentar la memoria?
Hay dos opciones disponibles según su cuello de botella:
El cuello de botella son las conexiones o el ancho de banda: Habilite read/write splitting. Esto no requiere cambios en el código ni modificaciones en el endpoint, y se puede deshabilitar en cualquier momento. La instancia enruta automáticamente las solicitudes de lectura y escritura a los nodos correspondientes.
El uso de CPU es consistentemente alto: Actualice a una instancia de clúster. Agregar shards distribuye la carga de CPU entre varios nodos. Antes de actualizar, compruebe la compatibilidad de comandos entre las arquitecturas estándar y de clúster; consulte Limits on commands supported by cluster instances and read/write splitting instances.
A continuación tabla compara el rendimiento de una instancia de Redis Open-Source Edition de 8 GB en las distintas arquitecturas:
|
Arquitectura |
Memoria (GB) |
Núcleos de CPU |
Ancho de banda (Mbit/s) |
Conexiones máximas |
Valor de referencia de QPS |
|
Arquitectura estándar (nodos maestro y réplica) |
8 |
2 |
96 |
20,000 |
100,000 |
|
Arquitectura estándar (división de lectura/escritura habilitada, un nodo maestro, una réplica de lectura) |
8 |
4 (2 × 2) |
192 (96 × 2) |
40,000 (20,000 × 2) |
200,000 |
|
Arquitectura de clúster (2 shards) |
8 (4 GB × 2 shards) |
4 (2 × 2) |
192 (96 × 2) |
40,000 (20,000 × 2) |
200,000 |