Consistencia de datos: conceptos centrales y estrategias de implementación

En la era de la información actual, los datos se han convertido en uno de los activos principales de las empresas. Sin embargo, a medida que la cantidad de datos continúa creciendo y los escenarios de aplicación continúan expandiéndose, cómo garantizar la coherencia de los datos se ha convertido en un desafío importante. La coherencia de los datos no solo está relacionada con la exactitud y confiabilidad del sistema, sino que también afecta directamente la experiencia del usuario y los resultados comerciales de la empresa. Por lo tanto, es muy necesario que todos los que participan en trabajos relacionados con datos tengan una comprensión profunda de los conceptos centrales de coherencia de datos y dominen diversas estrategias de implementación.

En este artículo, primero presentaremos los conceptos básicos de coherencia de datos, incluida la coherencia fuerte, la coherencia débil, la coherencia final, etc., y explicaremos su significado y diferencia a través de ejemplos específicos. Luego, profundizaremos en varias teorías distribuidas, incluidas la teoría CAP, ACID y BASE.

Espero que este artículo pueda ayudar a los lectores a comprender mejor la importancia de la coherencia de los datos y cómo lograr y garantizar de forma eficaz la coherencia de los datos en el trabajo real.

---

---

1. Introducción a la coherencia de los datos.

1.1 Concepto de coherencia de datos

La coherencia de los datos significa que los datos pueden alcanzar el estado esperado después de una serie de operaciones. En una base de datos, la coherencia generalmente significa que los datos satisfacen ciertas restricciones, como restricciones de clave externa y restricciones únicas en bases de datos relacionales.

En los sistemas distribuidos, la cuestión de la coherencia de los datos es más compleja. Debido a que los datos pueden copiarse en varios nodos, cuando los datos cambian en un determinado nodo, es necesario garantizar que este cambio pueda ser visto por todos los demás nodos, lo que constituye un problema de coherencia de los datos en los sistemas distribuidos.

1.2 El papel de la coherencia de los datos

Mantener la coherencia de los datos en sistemas distribuidos es una cuestión importante por las siguientes razones:

1. Precisión de los datos: la coherencia de los datos es la base para garantizar la precisión de los datos. Si los datos en un sistema distribuido son inconsistentes, puede hacer que los usuarios vean datos incorrectos o tomen decisiones incorrectas basadas en datos incorrectos.
2. Disponibilidad del sistema: si los datos en el sistema distribuido son inconsistentes, es posible que algunas operaciones no se realicen, lo que afecta la disponibilidad del sistema. Por ejemplo, si una operación requiere leer y escribir datos que no están en el mismo estado, es posible que no se ejecute correctamente.
3. Continuidad del negocio: en algunos escenarios comerciales, la coherencia de los datos es imprescindible. Por ejemplo, en los sistemas de comercio electrónico, la coherencia del inventario es la base para garantizar el correcto procesamiento de los pedidos.

Por lo tanto, cómo mantener la coherencia de los datos en sistemas distribuidos es una cuestión importante en el diseño de sistemas distribuidos.

---

2. Modelo de coherencia de datos

El modelo de coherencia de datos es un concepto importante en los sistemas distribuidos, que determina cómo los datos permanecen coherentes en varios nodos. Los diferentes modelos de consistencia tienen diferentes características y escenarios aplicables, que incluyen consistencia fuerte, consistencia lineal, consistencia causal, consistencia de sesión, consistencia eventual, consistencia de lectura monótona, consistencia de escritura monótona, consistencia de escritura y consistencia de escritura.Seguir la consistencia de lectura, etc. Comprender estos modelos de coherencia puede ayudarnos a diseñar y comprender mejor los sistemas distribuidos.

2.1 Modelo de consistencia fuerte

Strong Consistency es un modelo de coherencia de datos que requiere que el sistema muestre la misma vista de datos a todos los operadores en cualquier momento. Específicamente, una vez que se haya actualizado un elemento de datos, cualquier operación de lectura posterior devolverá este nuevo valor. Esto significa que si existen varias réplicas, todas las réplicas deben actualizarse simultáneamente durante una operación de actualización.

La ventaja de una fuerte coherencia es que proporciona un modelo de programación muy intuitivo y simple, porque todos los operadores ven la misma vista de datos y no necesitan lidiar con inconsistencias de datos. Esto es muy importante en algunos escenarios que requieren una coherencia estricta de los datos (como las transferencias bancarias).

Sin embargo, la desventaja de una fuerte coherencia es que generalmente requiere un gran costo de rendimiento para implementarla en un entorno distribuido. Porque al realizar una operación de actualización, debe esperar a que se actualicen todas las réplicas, lo que provocará una disminución en el rendimiento del sistema y el tiempo de respuesta. Además, si una copia no se puede actualizar a tiempo debido a problemas o fallas en la red, todo el sistema puede bloquearse, afectando la disponibilidad del sistema.

El modelo de coherencia fuerte incluye coherencia lineal y coherencia secuencial. La primera tiene restricciones de seguridad más estrictas y es la mejor coherencia que se puede garantizar en un sistema distribuido.

2.2 Modelo de consistencia lineal

La linealización es un modelo de consistencia fuerte, también conocido como consistencia atómica. Requiere que para cualquier nodo, cualquier operación tenga un orden fijo globalmente y que todos los nodos observen todas las operaciones en este orden.

En concreto, la consistencia lineal tiene las siguientes características:

1. El orden de las operaciones es coherente con el orden en que realmente ocurren: si una operación se completa antes que otra, cualquier observador verá primero los resultados de la primera operación.

2. Los resultados de la operación son visibles inmediatamente para todos los nodos: una vez que se completa una operación, cualquier operación de lectura posterior devolverá este nuevo valor.

La coherencia lineal proporciona un modelo de programación muy intuitivo y sencillo porque todos los operadores ven la misma vista de los datos y no necesitan lidiar con inconsistencias de datos. Sin embargo, lograr una coherencia lineal requiere un gran costo de rendimiento, porque al realizar una operación de actualización, debe esperar a que se actualicen todas las réplicas, lo que conducirá a una disminución en el rendimiento del sistema y el tiempo de respuesta.

Por ejemplo, supongamos que tenemos dos nodos: el nodo A primero realiza la operación de escritura A (escribir datos x = 1) y luego el nodo B realiza la operación de lectura B.

• En el modelo de consistencia lineal, siempre que el nodo B realiza la operación de lectura B, debe leer los datos x = 1.

La implementación de modelos de coherencia lineal generalmente se basa en tecnologías de procesamiento de transacciones distribuidas, como la confirmación de dos fases (2PC), la confirmación de tres fases (3PC), etc. Además, los algoritmos de consenso como Paxos y Raft también pueden lograr una coherencia lineal.

2.3 Modelo de consistencia de secuencia

La coherencia secuencial es un tipo de modelo de coherencia fuerte. La coherencia de la secuencia requiere que el orden de las operaciones vistas por todos los nodos sea coherente, incluso si este orden no necesita ser coherente con el orden de ocurrencia real. Esto significa que todas las operaciones de lectura verán los resultados de las últimas operaciones de escritura, siempre que esas escrituras se completen antes de la operación de lectura. Por lo tanto, la coherencia de la secuencia cumple con la definición de coherencia fuerte, es decir, el sistema muestra la misma vista de datos a todos los operadores en cualquier momento.

Específicamente, la coherencia de secuencia tiene las siguientes características:

1. Orden global: todas las operaciones están en un orden global y todos los nodos observan todas las operaciones en este orden.
2. Orden de lectura y escritura: si una operación de escritura se completa antes que una operación de lectura, entonces la operación de lectura debe devolver el resultado de la operación de escritura.

La coherencia de secuencia proporciona un modelo de programación relativamente simple porque todos los operadores ven el mismo orden de operaciones. Sin embargo, lograr la coherencia de la secuencia tiene un costo de rendimiento porque es necesario mantener el orden global de las operaciones.

Ahora supongamos que tenemos dos operaciones: la operación A es escribir datos y la operación B es leer datos.

En el modelo de consistencia lineal, si la operación A se completa antes que la operación B, entonces la operación B debe poder leer los datos escritos por la operación A, independientemente del nodo en el que ocurrieron las dos operaciones. Esto requiere que el sistema mantenga una secuencia consistente de operaciones a nivel global.

Por ejemplo, supongamos que tenemos dos nodos: el nodo A primero realiza la operación de escritura A (escribir datos x = 1) y luego el nodo B realiza la operación de lectura B.

• En el modelo de consistencia secuencial, solo se requiere que el orden de las operaciones vistas por todos los nodos sea consistente, pero no requiere que este orden sea consistente con el orden de ocurrencia real. Esto significa que si el nodo A realiza primero una operación de escritura A y luego el nodo B realiza una operación de lectura B, es posible que el nodo B no pueda leer los datos x = 1, porque desde la perspectiva del nodo B, la operación de lectura B puede estar realizando una operación de escritura A sucedió antes.

Por lo tanto, los modelos de consistencia lineal brindan garantías de consistencia más sólidas que los modelos de consistencia secuencial.

La implementación del modelo de coherencia de secuencia generalmente se basa en tecnologías como bloqueos distribuidos o marcas de tiempo para garantizar que el orden de las operaciones vistas por todos los nodos sea coherente.

2.4 Modelo de consistencia débil

La coherencia débil es un modelo de coherencia de datos que no requiere que el sistema muestre la misma vista de datos a todos los operadores en ningún momento. Específicamente, una vez que se ha actualizado un elemento de datos, las operaciones de lectura posteriores pueden devolver datos más antiguos durante un período de tiempo hasta que se hayan actualizado todas las réplicas.

La ventaja de una coherencia débil es que puede proporcionar un mayor rendimiento y disponibilidad en un entorno distribuido. Porque al realizar una operación de actualización, no es necesario esperar a que se actualicen todas las réplicas y los resultados se pueden devolver inmediatamente, lo que puede mejorar el rendimiento y el tiempo de respuesta del sistema. Además, incluso si una copia no se puede actualizar a tiempo debido a problemas o fallas en la red, no afectará la disponibilidad del sistema.

Sin embargo, la desventaja de una coherencia débil es que el modelo de programación es más complejo y la aplicación necesita lidiar con la inconsistencia de los datos por sí sola. Por ejemplo, si un operador lee el valor anterior de un elemento de datos, es posible que deba esperar un período de tiempo o adoptar alguna estrategia (como volver a intentarlo) para obtener el nuevo valor. Esto puede causar problemas en algunos escenarios que requieren una alta coherencia de los datos (como las actualizaciones del círculo de amigos en las redes sociales).

El modelo de consistencia débil no tiene un algoritmo de implementación específico, es más un principio de diseño del sistema, es decir, el sistema permite que los datos sean inconsistentes durante un período de tiempo. En los sistemas reales, la coherencia débil generalmente se logra mediante algunas estrategias de replicación (como la coherencia eventual).

. El modelo de consistencia débil es un concepto amplio que incluye una variedad de modelos de consistencia específicos, incluidos modelos de consistencia causal y modelos de consistencia eventual.

2.5 Modelo de consistencia causal

La coherencia causal es un modelo de coherencia de datos que es más débil que la coherencia de secuencia pero más fuerte que la coherencia débil. En el modelo de consistencia causal, sólo las operaciones causalmente relevantes deben permanecer en orden, y las operaciones causalmente irrelevantes pueden estar en cualquier orden.

Específicamente, si una operación A afecta a otra operación B (por ejemplo, la operación A es una operación de escritura, la operación B es una operación de lectura y los datos escritos por A se leen), entonces decimos que A y B están causalmente relacionados. En el modelo de coherencia causal, todos los operadores ven el orden correcto de las operaciones relacionadas causalmente. Sin embargo, para operaciones no relacionadas causalmente, diferentes operadores pueden ver secuencias diferentes.

La ventaja de la coherencia causal es que puede proporcionar un rendimiento más alto que la coherencia de secuencia y, al mismo tiempo, mantener la garantía de coherencia de la causalidad. Porque al realizar una operación de actualización, no es necesario esperar a que se actualicen todas las réplicas y los resultados se pueden devolver inmediatamente, lo que puede mejorar el rendimiento y el tiempo de respuesta del sistema. Al mismo tiempo, dado que sólo es necesario garantizar el orden de las operaciones relacionadas causalmente, el rendimiento se puede mejorar aún más.

Sin embargo, la desventaja de la coherencia causal es que el modelo de programación es más complejo y la aplicación necesita ocuparse del orden de las operaciones por sí misma. Por ejemplo, si un operador realiza una serie de operaciones en una secuencia, pero el orden de las operaciones visto por otros operadores puede ser inconsistente con el orden real de las operaciones, esto puede causar algunos problemas.

La implementación de modelos de consistencia causal generalmente se basa en tecnologías como Vector Clock o Version Vector para garantizar el orden de las operaciones relacionadas causalmente.

2.6 Modelo de consistencia final

La coherencia eventual es un modelo de coherencia de datos, que es un caso especial de coherencia débil. En el modelo de coherencia eventual, el sistema no garantiza que se mostrará la misma vista de datos a todos los operadores en cualquier momento, pero sí garantiza que, en ausencia de nuevas actualizaciones de datos, todas las copias eventualmente alcanzarán un estado consistente.

Específicamente, una vez que se ha actualizado un elemento de datos, las operaciones de lectura posteriores pueden devolver datos más antiguos durante un período de tiempo hasta que se hayan actualizado todas las réplicas. Este proceso puede tardar un poco, pero una vez que se actualicen todas las réplicas, todos los operadores verán la misma vista de los datos.

La ventaja de la coherencia eventual es que puede proporcionar un mayor rendimiento y disponibilidad en un entorno distribuido, al tiempo que garantiza la coherencia de los datos. Porque al realizar una operación de actualización, no es necesario esperar a que se actualicen todas las réplicas y los resultados se pueden devolver inmediatamente, lo que puede mejorar el rendimiento y el tiempo de respuesta del sistema. Además, incluso si una copia no se puede actualizar a tiempo debido a problemas o fallas en la red, no afectará la disponibilidad del sistema.

La coherencia final se ha aplicado en muchos sistemas prácticos, como los sistemas DNS, el sistema Dynamo de Amazon y muchas bases de datos NoSQL (como Redis, MongoDB, etc.). Estos sistemas generalmente necesitan manejar una gran cantidad de solicitudes de lectura y escritura, tienen altos requisitos de rendimiento y disponibilidad, y requisitos relativamente bajos de coherencia de los datos.

Por ejemplo, supongamos que tenemos un sistema distribuido con dos nodos: Nodo A y Nodo B. Ahora, realizamos una operación de escritura en el nodo A, cambiando el valor del elemento de datos x de 0 a 1. Una vez completada esta operación de escritura, el valor del elemento de datos x en el nodo A se ha convertido en 1, pero el valor del elemento de datos x en el nodo B aún puede ser 0, porque el resultado de la operación de escritura aún no se ha propagado al nodo B. . Por lo tanto, si realizamos una operación de lectura posterior en el nodo B, la operación de lectura puede leer el valor anterior del elemento de datos x, 0, en lugar del nuevo valor de 1.

Ps: Los amigos cuidadosos pueden encontrar que en el mismo ejemplo, los resultados del "modelo de consistencia secuencial" y el "modelo de consistencia eventual" son los mismos, pero ¿por qué el primero pertenece a la consistencia fuerte y el segundo a la consistencia débil? Esto se debe a que las dos definiciones de "la operación de escritura se considera completada" son diferentes.

En un modelo de consistencia fuerte, como un modelo de consistencia lineal, una operación de escritura se considera completa si y solo si la operación de escritura se ha aplicado a todas las réplicas, es decir, todos los nodos han visto este resultado de la operación de escritura.

Sin embargo, en un modelo de consistencia débil, como un modelo de consistencia eventual, una operación de escritura puede considerarse completa siempre que la operación de escritura se haya aplicado a una réplica, incluso si las otras réplicas aún no han visto el resultado de la operación de escritura. . . En este caso, es posible que otros nodos tengan que esperar un rato para ver los resultados de la operación de escritura.

La implementación del modelo de coherencia eventual generalmente se basa en algunas estrategias de replicación, como la lista de preferencias y el hash consistente en el sistema Dynamo, así como en algunas tecnologías de procesamiento de transacciones distribuidas como TCC o protocolos de coherencia como ZooKeeper o ZAB et al.

2.7 Otros modelos de consistencia

Además, existen algunos modelos de consistencia que se clasifican según sus escenarios, como por ejemplo:

1. Consistencia de la sesión: en la misma sesión, el cliente puede leer los datos que ha escrito antes, es decir, una vez que un cliente escribe datos nuevos, en la misma sesión, todas las operaciones de lectura posteriores pueden leer estos nuevos datos.
2. Consistencia de lectura monótona: si un nodo lee una vez un determinado valor de un elemento de datos del sistema, al menos puede leer este valor en operaciones de lectura posteriores. En otras palabras, el nodo lee El valor del elemento de datos obtenido no se transferirá atrás.
3. Consistencia de escritura monótona: el sistema requiere que las operaciones de escritura en un nodo se realicen en el orden en que ocurren, es decir, para dos operaciones de escritura cualesquiera, si ocurren en un orden determinado en un nodo, entonces el orden de ejecución de estas dos operaciones de escritura son las mismas en todos los nodos.
4. Consistencia de lectura de sus escrituras: el sistema garantiza que un nodo pueda leer los últimos datos que ha escrito antes, es decir, si un nodo escribe un nuevo valor de un elemento de datos, en las operaciones de lectura posteriores, este nodo Al menos puedo leer este nuevo valor.
5. Consistencia de escritura-seguimiento-lectura: si un nodo ha leído un determinado valor de un elemento de datos del sistema, en operaciones de escritura posteriores, este nodo puede al menos escribir un valor mayor o igual a este El nuevo valor del valor, es decir, el valor del elemento de datos escrito por el nodo no se revertirá.

---

3. Introducción a la teoría de la PAC

3.1 Introducción a la teoría de la PAC

La teoría CAP, también conocida como protocolo CAP, se refiere al hecho de que en un sistema distribuido, la "consistencia", la "disponibilidad" y la "tolerancia de partición" solo se pueden satisfacer al mismo tiempo. Es imposible cuidar de dos de las tres elementos.

Respecto a la coherencia: en la teoría CAP, la coherencia suele referirse a una coherencia fuerte. En la teoría CAP, la coherencia significa que los datos vistos por todos los nodos en el sistema distribuido al mismo tiempo son consistentes, es decir, para cualquier nodo, cualquier operación tiene un orden fijo globalmente, y todos los nodos observan todas las operaciones en este orden. ;

Respecto a la disponibilidad: en la teoría CAP, la disponibilidad generalmente se refiere a: "Las lecturas y escrituras siempre tienen éxito", es decir, "el servicio siempre está disponible dentro del tiempo de respuesta normal". Una buena disponibilidad significa principalmente que el sistema puede servir bien a los usuarios sin causar una mala experiencia de usuario, como fallas en la operación del usuario o tiempo de espera de acceso. Disponibilidad Generalmente, la disponibilidad está estrechamente relacionada con la redundancia de datos distribuidos, el equilibrio de carga, etc.;

Con respecto a la tolerancia de partición: en la teoría CAP, la tolerancia de partición generalmente se refiere a: "El sistema continúa funcionando a pesar de la pérdida arbitraria de mensajes o la falla de parte del sistema", es decir, "el sistema distribuido encuentra un determinado Cuando falla un nodo o una partición de red , aún puede proporcionar servicios externos que cumplan con los requisitos de coherencia o disponibilidad";

Explicación de la partición de red: por ejemplo, hay dos servidores (Servidor A, Servidor B) y hay comunicación entre ellos, sin embargo, de repente, por razones de ubicación, el enlace de red entre los dos se interrumpe, lo que provoca que los dos servidores se interrumpan. en la misma red. Se produjo una partición de red entre el "Servidor A" y el "Servidor B", convirtiéndose en la "red A" donde se encuentra el "Servidor A" y la "red B" donde se encuentra el "Servidor A".

¡La llamada tolerancia de partición significa que múltiples servidores de un servicio de datos aún pueden continuar brindando servicios cuando ocurre la situación anterior (partición de red)!

3.2 Prueba del escenario básico de la teoría de la PAC

La siguiente es la prueba de la teoría CAP: el siguiente es un escenario básico de un sistema distribuido: hay dos nodos Nodo1 y Nodo2 en la red (simplemente puede entender que Nodo1 y Nodo2 son dos computadoras respectivamente), y la red entre los dos se puede conectar., Hay una "Aplicación A" y una "Base de datos A" en el Nodo1, y el Nodo2 también tiene una "Aplicación B" y una "Base de datos B". Ahora, la "Aplicación A" y la "Aplicación B" son dos partes del sistema distribuido, y la "Base de datos A" y la "Base de datos B" son dos subbases de datos del almacenamiento de datos del sistema distribuido.

• Cuando se cumple la coherencia: los datos en el Nodo1 y el Nodo2 son los mismos, V0=V0.

• Cuando se alcanza la disponibilidad: los usuarios recibirán una respuesta inmediata ya sea que soliciten el Nodo1 o el Nodo2.

• Cuando se cumple la tolerancia a fallas de la partición: si el Nodo1 o el Nodo2 fallan o la red no está disponible, el funcionamiento normal del Nodo1 y el Nodo2 no se verá afectado.

3.3 Prueba de la teoría del CAP: funcionamiento normal

La siguiente figura es el proceso de operación normal del sistema distribuido. El usuario solicita la actualización de datos de la máquina Nodo1. El programa A actualiza la base de datos V0 a V1. El sistema distribuido sincroniza los datos M y sincroniza V1 a V0 en el Nodo2 para que los datos en Node2 V0 también se actualiza a V1 y los datos en Node2 responden a la solicitud de Node2.

Aquí, puede definir si los datos entre la base de datos V de Nodo1 y Nodo2 son los mismos que la coherencia; la respuesta de solicitud externa a Nodo1 y Nodo2 es disponibilidad; el entorno de red entre Nodo1 y Nodo2 es tolerancia a fallas de partición.

3.4 Prueba de la teoría CAP: se produce una anomalía

Este es un escenario de operación normal y un escenario ideal, pero la realidad es cruel: cuando ocurre un error, ¿se pueden satisfacer la coherencia, la disponibilidad y la tolerancia de partición al mismo tiempo, o existe una compensación?

Como sistema distribuido, la mayor diferencia entre este y un sistema independiente es la red. Ahora supongamos una situación extrema, la red entre el Nodo1 y el Nodo2 está desconectada. Necesitamos soportar esta anomalía de la red, lo que equivale a encontrar una falla de partición. tolerancia ¿Puede satisfacer la coherencia y la capacidad de respuesta al mismo tiempo? ¿O deberíamos elegir entre ellos?

Supongamos que cuando la red entre el Nodo1 y el Nodo2 se desconecta, un usuario envía una solicitud de actualización de datos al Nodo1, luego los datos V0 en el Nodo1 se actualizarán a V1. Dado que la red está desconectada, el sistema distribuido opera M sincrónicamente, por lo que los datos en el Nodo 2 todavía es V0; en este momento, un usuario envía una solicitud de lectura de datos al Nodo 2. Dado que los datos no se han sincronizado, la aplicación no puede devolver inmediatamente los últimos datos V1 al usuario. ¿Qué debo hacer?

Hay dos opciones:

• Primero, sacrifique la coherencia de los datos y responda a los datos antiguos V0 al usuario;
• En segundo lugar, se sacrifica la disponibilidad, se bloquea y se espera hasta que se restablezca la conexión de red y se complete la operación de actualización de datos M, y luego se responden los últimos datos V1 al usuario.

Este proceso demuestra que para que un sistema distribuido satisfaga la tolerancia a fallas de partición, solo se puede elegir uno de coherencia y disponibilidad.

3.5 Compensaciones de la teoría de la PAC

A través de la teoría CAP sabemos que las tres características de coherencia, disponibilidad y tolerancia a la partición no se pueden cumplir al mismo tiempo, entonces, ¿cuál deberíamos abandonar?

• CA sin P: si no se requiere P (no se permite la partición), se garantizan C (consistencia fuerte) y A (disponibilidad). Pero, de hecho, la partición no es un problema en el que piense, pero siempre existirá, por lo que el sistema CA permite que cada subsistema siga siendo CA después de la partición.
• CP sin A: si no se requiere A (disponible), significa que cada solicitud debe ser muy consistente entre los servidores, y P (partición) hará que el tiempo de sincronización se extienda indefinidamente, por lo que también se puede garantizar CP. Muchas transacciones distribuidas de bases de datos tradicionales caen en este patrón.
• AP sin C: para tener alta disponibilidad y permitir la partición, es necesario renunciar a la coherencia. Una vez que se produce la partición, los nodos pueden perder contacto. Para una alta disponibilidad, cada nodo solo puede proporcionar servicios con datos locales, lo que provocará inconsistencia de datos globales. Muchos NoSQL ahora entran en esta categoría.

Para la mayoría de los escenarios de aplicaciones de Internet a gran escala, hay muchos hosts e implementaciones dispersas, y la escala actual del clúster es cada vez mayor, por lo que las fallas de los nodos y las fallas de la red son normales, y se debe garantizar que la disponibilidad del servicio alcance N nueves, es decir , P y A están garantizados, descarte C (lo mejor que puede hacer es garantizar la coherencia final). Aunque afectará la experiencia del cliente en algunos lugares, no es lo suficientemente grave como para provocar un flujo de usuarios.

Para escenarios que involucran dinero donde no puede haber compromiso, C debe garantizarlo. Si la red falla, es mejor detener el servicio, esto es para asegurar CA y abandonar P. Parece que en los últimos años han ocurrido no menos de 10 accidentes en el sector bancario nacional, pero el impacto no fue grande, no hubo muchos informes y el público en general sabía poco. Otra opción es garantizar CP y descartar A. Por ejemplo, una falla en la red solo puede leer pero no escribir.

---

4. Introducción a la teoría ACID y la teoría BASE.

4.1 Teoría del ÁCIDO

ACID y BASE son dos teorías de diseño de sistemas distribuidos comunes y representan dos conceptos de diseño diferentes.

ACID puede entenderse como el significado más importante de ACID, que es atomicidad y aislamiento, es decir, coherencia obligatoria, hacerlo todo o no hacerlo, y los datos vistos por todos los usuarios son consistentes. Enfatizar la confiabilidad, consistencia y disponibilidad de los datos.

ACID se refiere a Atomicidad, Consistencia, Aislamiento y Durabilidad.

• Atomicidad: todas las operaciones en una transacción se completan por completo o no se completan y no terminarán en algún punto intermedio. Si se produce un error durante la ejecución de la transacción, se revertirá al estado anterior al inicio de la transacción, como si la transacción nunca se hubiera ejecutado;
• Consistencia: la integridad de la base de datos no se ve comprometida antes de que comience la transacción y después de que finalice. Esto significa que los datos escritos deben cumplir plenamente con todas las reglas preestablecidas, incluida la precisión y la concatenación de los datos, y que la base de datos posterior puede completar espontáneamente el trabajo predeterminado;
• Aislamiento: la base de datos permite que múltiples transacciones simultáneas lean, escriban y modifiquen sus datos al mismo tiempo. El aislamiento puede evitar la inconsistencia de los datos debido a la ejecución cruzada cuando se ejecutan múltiples transacciones al mismo tiempo. El aislamiento de transacciones se divide en diferentes niveles, que incluyen lectura no confirmada, lectura confirmada, lectura repetible, serialización, etc.;
• Durabilidad: Una vez completada la transacción, las modificaciones a los datos son permanentes y no se perderán incluso si el sistema falla.

4.2 Teoría BASE

La teoría BASE fue propuesta por los arquitectos de eBay. BASE es el resultado de la compensación entre coherencia y disponibilidad en CAP, se deriva del resumen de las prácticas de sistemas distribuidos de Internet a gran escala y evoluciona gradualmente en base a la ley CAP. La idea central es que incluso si no se puede lograr una coherencia sólida, cada aplicación puede utilizar los métodos adecuados para lograr la coherencia final en el sistema en función de sus propias características comerciales.

BASE se refiere a Básicamente Disponible, Estado Suave y Eventualmente consistente.

• Básicamente disponible: el sistema siempre está disponible, pero en algunos casos puede que solo proporcione funciones parciales, por ejemplo, en el caso de particiones de red, solo puede leer pero no escribir, o solo devolver parte de los datos;
• Estado suave: el estado del sistema puede cambiar debido a diversas razones, como retrasos en la red, fallas parciales, etc. El sistema no necesita mantener la coherencia en tiempo real;
• Coherencia final: el sistema garantiza que sin nuevas operaciones de actualización, todos los datos de réplica eventualmente alcanzarán un estado consistente después de un período de tiempo.

La principal diferencia entre ACID y BASE es que ACID proporciona un modelo de coherencia estricto, que es adecuado para escenarios con requisitos de coherencia muy altos, como las transferencias bancarias. BASE proporciona un modelo de coherencia eventual, que es adecuado para escenarios con requisitos de disponibilidad muy altos, como aplicaciones de Internet. En el diseño de sistemas reales, es necesario sopesar la relación entre coherencia y disponibilidad y elegir una teoría de diseño adecuada en función de las necesidades y características del sistema.

---

5. Estado actual y perspectivas de soluciones coherentes

5.1 Casos prácticos de aplicación

Los siguientes son algunos casos de aplicaciones prácticas de grandes empresas de Internet que garantizan la coherencia de los datos en sus sistemas distribuidos:

1. Bigtable de Google: Bigtable es un sistema de almacenamiento distribuido de Google para almacenar datos estructurados. Bigtable utiliza un servicio de bloqueo distribuido llamado Chubby para garantizar la coherencia de los datos. Chubby proporciona un servicio de bloqueo basado en el algoritmo de Paxos. Bigtable garantiza la coherencia de los datos adquiriendo bloqueos en Chubby.

2. Amazon's Dynamo: Dynamo es un sistema distribuido de almacenamiento de valores clave de Amazon, que se utiliza para manejar el servicio de carrito de compras de Amazon. Dynamo utiliza una tecnología llamada hash consistente para distribuir datos. Al introducir los conceptos de nodos virtuales y anillos hash, garantiza la coherencia de los datos cuando se agregan o eliminan nodos. Al mismo tiempo, Dynamo también utiliza una tecnología llamada reloj vectorial para resolver el problema de los conflictos de datos.

3. Cassandra de Facebook: Cassandra es un sistema de almacenamiento distribuido desarrollado por Facebook para almacenar datos de búsqueda en la bandeja de entrada de Facebook. Cassandra también utiliza hash consistente para distribuir datos y también introduce un protocolo llamado Gossip para sincronizar la información del estado del nodo para garantizar la coherencia de los datos.

4. Kafka de LinkedIn: Kafka es un sistema de mensajería distribuida desarrollado por LinkedIn y utilizado para procesar los flujos de datos en tiempo real de LinkedIn. Kafka utiliza un servicio llamado ZooKeeper para garantizar la coherencia de los datos. ZooKeeper proporciona un servicio de coherencia basado en el algoritmo Paxos. Kafka garantiza la coherencia de los datos manteniendo la información de metadatos en ZooKeeper.

Los anteriores son algunos casos de aplicaciones prácticas de grandes empresas de Internet que garantizan la coherencia de los datos en sus sistemas distribuidos. Estos casos muestran cómo elegir el modelo de coherencia adecuado y la coherencia de acuerdo con las necesidades y características del sistema en el diseño del sistema real.

5.2 Tendencias de desarrollo futuras

Con el desarrollo de la computación en la nube y la tecnología de big data, la escala de los sistemas distribuidos es cada vez mayor y el problema de la coherencia de los datos se vuelve cada vez más complejo. Las siguientes son algunas tendencias futuras de desarrollo de soluciones de coherencia de datos en sistemas distribuidos, así como posibles desafíos:

1. Mayor rendimiento y disponibilidad: a medida que los usuarios tienen requisitos cada vez mayores de calidad del servicio, los sistemas distribuidos deben proporcionar mayor rendimiento y disponibilidad. Esto requiere mejorar el rendimiento y la disponibilidad del sistema tanto como sea posible y al mismo tiempo garantizar la coherencia de los datos. Esto puede requerir diseñar algoritmos de consenso más eficientes o introducir más técnicas de optimización en el diseño del sistema.

2. Modelos de coherencia más complejos: a medida que aumenta la complejidad de los requisitos comerciales, es posible que se requieran modelos de coherencia más complejos para satisfacer las necesidades comerciales. Por ejemplo, para algunas empresas, puede ser necesario garantizar la coherencia causal o la coherencia de las transacciones. Esto requiere que se consideren más factores en el diseño de modelos de consistencia y algoritmos de consenso.

3. Sistemas distribuidos a mayor escala: a medida que los sistemas distribuidos se vuelven cada vez más grandes, el problema de la coherencia de los datos se vuelve cada vez más complejo. Por ejemplo, cuando la escala del sistema alcanza una escala global, es posible que sea necesario considerar cuestiones como la latencia de la red y las diferencias de zona horaria. Esto requiere que se consideren más factores en el diseño del algoritmo de consenso.

4. Seguridad de los datos y protección de la privacidad: a medida que la seguridad de los datos y la protección de la privacidad se vuelven cada vez más importantes, cómo proteger la seguridad y la privacidad de los datos y al mismo tiempo garantizar la coherencia de los datos también es un desafío importante. Esto puede requerir la introducción de más técnicas de seguridad y protección de la privacidad en el diseño de algoritmos de consenso.

Las anteriores son las tendencias de desarrollo futuras de las soluciones de coherencia de datos en algunos sistemas distribuidos, así como los desafíos que pueden enfrentar. En el futuro, debemos continuar la investigación y exploración para satisfacer las necesidades de coherencia de los datos en los sistemas distribuidos.