Recuperación ante desastres (DR) y solución multiactiva
Ya sea que utilice DCS como caché frontend o almacenamiento de datos backend, DCS siempre está listo para garantizar la confiabilidad de los datos y la disponibilidad del servicio. La siguiente figura muestra la evolución de las arquitecturas DR de DCS.

Para cumplir con los requisitos de confiabilidad de sus datos y servicios, puede optar por desplegar su instancia de DCS dentro de una única AZ o entre AZ.
HA de la AZ única dentro de una región
Despliegue de la AZ única significa desplegar una instancia dentro de una sala de equipos físicos. DCS proporciona HA de proceso/servicio, persistencia de datos y políticas de DR en standby activa para diferentes tipos de instancias de DCS.
Instancia de nodo único de DCS: cuando DCS detecta una falla de proceso, se inicia un nuevo proceso para garantizar el HA del servicio.

Principal/en espera, separación de lectura/escritura o instancia de DCS de clúster: De forma predeterminada, los datos se mantienen en el disco en el nodo principal y se sincronizan y persisten en el nodo en espera de manera incremental, lo que permite lograr la persistencia de datos y la espera activa.
La siguiente figura muestra la sincronización de datos y la persistencia de los procesos de los nodos principales y en espera, incluidos los procesos de las instancias de separación principales/en espera y de lectura/escritura y cada partición de instancias de clúster.

DR entre las AZ dentro de una región
Los nodos principales y en espera de una instancia de DCS (no se incluye el tipo de nodo único) se pueden desplegar en las AZ (en diferentes salas de equipos). Las fuentes de alimentación y las redes de diferentes AZ están aisladas físicamente. Cuando se produce una falla en la AZ donde se despliega el nodo principal, el nodo en espera se conecta al cliente y se hace cargo de las operaciones de lectura y escritura de datos.




Al crear una instancia de DCS principal/en espera, de clúster o de separación de lectura/escritura, seleccione una AZ en espera que sea diferente de la AZ principal como se muestra a continuación.


También puede desplegar su aplicación en todas las AZ para garantizar la fiabilidad de los datos y la disponibilidad del servicio en caso de interrupciones en el suministro eléctrico o en la red.
Multiactividades entre las regiones
Actualmente, Huawei Cloud DCS no admite multiactividad entre regiones porque Redis no tiene una solución madura de actividad-actividad. Actividad-actividad es diferente de recuperación ante desastres o HA principal/en espera.
No se puede lograr Redis activo-activo entre las nubes o las regiones porque los protocolos de serialización de REdis (RESP) personalizados no están unificados. Si se requiere activo-activo, se puede implementar mediante escritura dual en el extremo de la aplicación.

Notas:
- La solución de escritura dual no puede garantizar la coherencia de la caché (debido a problemas de red). Las aplicaciones deben tolerar la incoherencia de la caché (estableciendo el tiempo de vida para lograr una eventual consistencia). Si las aplicaciones requieren una fuerte coherencia de la caché, esta solución no es adecuada. Actualmente, no existe una solución en la industria para garantizar una sólida consistencia de la caché entre regiones.
- Se recomienda realizar operaciones en la caché L2 entre regiones en modo asincrónico.