1. Introducción a la teoría CAP
CAP es la teoría básica de las aplicaciones distribuidas y analiza cómo la distribución resuelve los problemas de coherencia, disponibilidad y partición de la red.
C (Consistencia): La coherencia requiere que todos los nodos mantengan datos coherentes al mismo tiempo.
A (Disponibilidad): La disponibilidad requiere que la aplicación en sí esté disponible cuando ocurre una excepción en algunos nodos.
P (tolerancia de partición): tolerancia a fallas de partición de red. Las aplicaciones distribuidas tendrán múltiples nodos. Se requiere comunicación de red entre los nodos y puede ocurrir una interrupción o tiempo de espera de la red.
2. ¿Puede la PAC elegir dos de tres?
El mayor malentendido de la teoría CAP es que los tres factores tienen el mismo estatus. De hecho, este no es el caso. En un sistema distribuido, P (partición de red) es inevitable, por lo que solo se puede sopesar entre AP. Por lo tanto, en aplicaciones prácticas, la mayoría de ellos soportan CP o AP. CP busca la coherencia a expensas de la disponibilidad, como zk. AP busca la disponibilidad a expensas de la coherencia, como la replicación maestro-esclavo.
¿Por qué se requiere P? Porque para garantizar una alta disponibilidad, es necesaria la redundancia y las aplicaciones de una sola máquina no pueden hablar de A y P. La redundancia traerá problemas de partición, por lo que P seguramente existirá y P no se puede intercambiar por sacrificar A o C.
3. ¿Existe una fuerte coherencia?
3.1 La comunicación del nodo lleva tiempo
A menudo decimos que la CP es la búsqueda de una fuerte coherencia, pero ¿existe realmente una fuerte coherencia? Mientras haya P (partición de red), habrá comunicación entre los nodos, suponiendo que la comunicación entre los nodos sea normal, la comunicación llevará tiempo. Aunque la velocidad de procesamiento en el mundo de la informática está en el nivel de milisegundos, microsegundos o nanosegundos, no importa qué tan rápido sea el procesamiento, este tiempo sigue siendo un número distinto de cero.
3.2 La única constante es el cambio
El mundo de la información siempre está cambiando, e incluso si la comunicación es normal en un momento, puede cambiar al momento siguiente. Por ejemplo, el consumidor obtiene la lista disponible de proveedores de servicios del centro de registro de CP y selecciona una dirección a través de la carga para iniciar la llamada. En este momento, todavía existe la posibilidad de que el nodo correspondiente a esta dirección haya muerto. Por lo tanto, la información que ve ahora puede quedar desactualizada en el próximo momento.
4. Teoría PACELC
Según la discusión anterior, de hecho, no existe una consistencia fuerte completa, es decir, habrá un retraso en la sincronización entre los nodos, por lo que existe la teoría PACELC. PAC sigue siendo el CAP mencionado anteriormente, E es otra cosa, L es retraso de latencia y C sigue siendo consistencia. Una comprensión simple es que cuando ocurre una anomalía en la partición de la red, se debe hacer una compensación entre A y C. Cuando no ocurre una anomalía en la partición de la red, se debe hacer una compensación entre L y C.
5. Casos típicos
5.1 replicación maestro-esclavo de mysql
La replicación maestro-esclavo de MySQL brinda alta disponibilidad, pero incluso cuando la comunicación de red es normal, todavía hay un retraso en la sincronización maestro-esclavo, por lo que en este momento debe sopesar si el retraso es aceptable, si no, puede leer directamente el biblioteca principal. Por supuesto, cuando ocurre una excepción en la sincronización maestro-esclavo, no afecta la lectura de datos de la biblioteca esclava, es decir, la biblioteca esclava está disponible.
Cerradura distribuida 5.2 zk
Los bloqueos distribuidos se pueden implementar utilizando nodos temporales de zk. zk y el cliente mantienen conexiones activas a través de latidos. Si la conexión falla, los nodos temporales se eliminan automáticamente para liberar el bloqueo. Sin embargo, hay muchas situaciones al mantener esta conexión. Si la red se agota o la aplicación se congela, entonces dos procesos adquirirán el bloqueo, lo que provocará que el bloqueo distribuido deje de ser válido. El bloqueo distribuido de Redis también tiene problemas similares, por lo que es necesario Para usar cerraduras distribuidas, tenga cuidado.
nota:
Al crear aplicaciones distribuidas, debe observar el panorama general y comenzar con los detalles. Por lo general, solo cumpliendo las condiciones de AP y controlando C de acuerdo con la situación real se puede construir una aplicación sólida.