Los sistemas distribuidos modernos se basan en concesiones. El rendimiento, la fiabilidad, la escalabilidad y la coherencia no son gratuitos: siempre hay que pagar un precio. Ahí es donde entra en juego el teorema CAP: es el punto de partida para comprender los compromisos inevitables en el diseño distribuido.  ¿Por qué es cierto el teorema CAP? ¿Qué explica realmente? Y, lo más importante, ¿es suficiente? En este artículo, exploraremos el teorema CAP, sus limitaciones, las críticas que ha enfrentado y cómo las ideas más nuevas como PACELC están impulsando el debate. Profundicemos.  Teorema CAP  La primera versión del teorema CAP comenzó como un debate entre   . Pero con el tiempo evolucionó, obtuvo una prueba formal y se convirtió en el teorema CAP tal como lo conocemos hoy. ACID y BASE  El teorema CAP establece que   : un sistema distribuido puede satisfacer como máximo dos de tres propiedades simultáneamente   Consistencia   Disponibilidad   Tolerancia de partición  Esta limitación obliga a los ingenieros a hacer concesiones difíciles en función de los objetivos del sistema y las realidades de sus entornos distribuidos.  Consistencia   La consistencia en CAP no es lo mismo que la consistencia en   . En el teorema CAP se refiere a   o   . Significa que   , independientemente de qué nodo procese la solicitud. Esto significa que cada operación de lectura refleja la escritura más reciente, sin importar qué nodo consulte. las transacciones ACID linealización consistencia fuerte todos los nodos en un sistema distribuido deben presentar siempre una vista única y actualizada de los datos  💡 Por otro lado, la coherencia en ACID se centra en garantizar que una transacción lleve la base de datos de un estado válido a otro estado válido, siguiendo las reglas definidas por el esquema de la base de datos. Se trata más bien de aplicar restricciones de integridad (como claves externas, restricciones únicas, etc.) y garantizar que la base de datos no quede en un estado no válido, incluso en caso de fallos.  Disponibilidad   La disponibilidad en CAP significa que   . En otras palabras, si un nodo en buen estado recibe una solicitud, debe procesarla y responderla. Sin embargo, CAP   ; solo garantiza que el nodo no falle de manera silenciosa (por ejemplo, en   , los nodos pueden responder con datos obsoletos durante una partición para garantizar la disponibilidad). cada nodo que no falla debe devolver una respuesta para cada solicitud que recibe, independientemente de las particiones de la red no garantiza que la respuesta siempre sea "correcta" o esté actualizada un sistema AP  💡 Eric Brewer (el autor original de CAP) describió originalmente esta propiedad de forma un poco más flexible: "casi todas las consultas deberían obtener una respuesta". Sin embargo, en la prueba formal de CAP, la disponibilidad se hizo más estricta y se requirió que "todas las consultas reciban una respuesta siempre que el nodo que las maneja esté en buen estado".  En la práctica, sin embargo, la disponibilidad no es una garantía absoluta; a menudo depende de restricciones específicas del sistema, como el tiempo que está dispuesto a esperar para recibir una respuesta. En los sistemas del mundo real,   desempeña un papel fundamental a la hora de determinar el SLA (acuerdo de nivel de servicio), aunque el CAP en sí no tenga en cuenta directamente la latencia. Más información al respecto en   . el tiempo de respuesta (o los tiempos de espera) esta publicación del blog  Tolerancia de partición   La tolerancia a las particiones tiene que ver con la supervivencia ante fallas de red.   Una partición se produce cuando los nodos no pueden comunicarse debido a paquetes perdidos, tiempos de espera agotados o divisiones de la red. Si los nodos no pueden comunicarse debido a una división de la red (partición), el sistema debe cumplir con sus garantías de consistencia o disponibilidad, según sus opciones de diseño.  Los sistemas distribuidos no viven en un mundo de cuento de hadas con redes perfectas. Los paquetes se descartan, se agotan los tiempos de espera y los picos de latencia son inevitables. Por este motivo,   : las particiones se producirán tarde o temprano, por lo que no se puede "elegir" ignorarlas, por muy tentador que pueda parecer. la tolerancia a las particiones no es negociable en ningún sistema distribuido  En CAP, la tolerancia a particiones no significa que el sistema siga funcionando como si nada hubiera pasado, sino que el sistema debe decidir si priorizar la disponibilidad (AP) o la consistencia (CP) durante una partición. Si ignorara la tolerancia a particiones, básicamente estaría construyendo un sistema monolítico no distribuido.  La PAC explicada  La forma más sencilla de entender el CAP es considerar una   , una situación en la que dos partes de un sistema distribuido no pueden comunicarse entre sí. En tal escenario, el sistema se enfrenta a tres posibles resultados: partición de red    mientras que la otra está aislada, las dos partes tendrán estados inconsistentes. Esto da como resultado una pérdida de   . Si una parte del sistema acepta actualizaciones C (Consistencia)    , debe bloquear las actualizaciones en una o ambas partes de la partición para garantizar un estado unificado en todos los nodos. Esto genera una pérdida de   porque algunas solicitudes se rechazarán o retrasarán indefinidamente. Si el sistema decide mantener la coherencia A (disponibilidad)    y consistente (C) sin tolerar la partición (P), no está verdaderamente distribuido. Esto requeriría que los nodos interactúen y concilien el estado, lo cual es imposible durante una partición. Si el sistema elige permanecer disponible (A)  Por lo tanto,   , el sistema solo puede satisfacer   . Una vez que se resuelve la partición (es decir, los nodos vuelven a interactuar), el sistema puede recuperar las tres propiedades, pero   , las compensaciones son inevitables. durante una partición dos de las tres propiedades (C, A o P) durante la partición en sí  Implicaciones del teorema  Una consecuencia del teorema para sistemas asincrónicos es que solo son posibles tres combinaciones de consistencia, disponibilidad y tolerancia de partición:  AP (Disponibilidad + Tolerancia de partición)  Los sistemas de este tipo responden a las consultas, pero los datos devueltos pueden no estar siempre actualizados, con actualizaciones más lentas de los datos pero "siempre" disponibles. Ejemplos de este tipo de sistemas son DNS, DynamoDB y Cassandra.  CP (Consistencia + Tolerancia de partición)  Los sistemas de este tipo siempre devuelven datos actualizados, pero algunos nodos del sistema, o incluso todos, pueden no responder si se dividen en particiones. Ofrece actualizaciones atómicas, pero puede provocar tiempos de espera agotados. Las bases de datos NoSQL, como Google BigTable, MongoDB, HBase y Redis, son todas sistemas de este tipo.  CA (Consistencia + Disponibilidad)  Los sistemas de este tipo siempre devuelven datos actualizados cuando no hay particiones. Debido a esta última limitación, normalmente, estos sistemas se utilizan solo en una máquina. Un ejemplo son las bases de datos relacionales clásicas.  En realidad, elegimos entre CP y AP porque CA es básicamente un monolito sin particiones. Para sistemas de gran escala, los diseñadores no pueden abandonar P y, por lo tanto, tienen una elección difícil entre C y A.  En CA, la falla de un nodo significa la indisponibilidad total del servicio. Pero esto no deshabilita la escalabilidad, ya que podemos clonar monolitos independientes y distribuir la carga entre ellos.  Crítica del teorema CAP  El teorema CAP ha sido un concepto fundamental en los sistemas distribuidos, pero no está exento de limitaciones. A pesar de su claridad a la hora de presentar la idea de las compensaciones, el teorema CAP ha sido criticado a menudo por simplificar en exceso realidades complejas, lo que ha dado lugar a malentendidos y aplicaciones incorrectas.  1. Las compensaciones sólo se aplican durante las particiones  Una de las críticas más comunes es que las disyuntivas del teorema CAP (elegir entre   y   solo se aplican cuando realmente se produce   . En un funcionamiento normal, cuando la red es estable y no existen particiones, no existe una disyuntiva inherente entre consistencia y disponibilidad. consistencia (C) disponibilidad (A)) una partición de la red (P)  Además, estas compensaciones no son universales en todo el sistema. Dentro del mismo sistema distribuido:  Diferentes partes del sistema pueden experimentar diferentes compensaciones según el contexto (como la ubicación del usuario o el tipo de datos).  Algunas operaciones pueden priorizar la consistencia mientras que otras priorizan la disponibilidad.  Las decisiones pueden variar en tiempo de ejecución dependiendo de factores como la carga, la latencia o los requisitos del usuario.  Este matiz a menudo se pierde en los debates de alto nivel sobre CAP, lo que lleva a clasificaciones demasiado simplificadas de los sistemas como "CP" o "AP" en general.  2. CAP ignora la latencia  Otra crítica importante es que el teorema CAP no tiene en cuenta   , aunque en la práctica la latencia y la partición están profundamente conectadas. Por ejemplo: la latencia  Una red lenta (alta latencia) puede parecer indistinguible de una partición.  Los tiempos de espera (que se utilizan para detectar fallas) son subjetivos y dependen en gran medida del diseño del sistema y de las condiciones de la red. Lo que un sistema define como una "partición" puede ser simplemente un retraso transitorio para otro.  En sistemas distribuidos del mundo real, cuando se produce una partición o una latencia alta, el sistema debe tomar una decisión dentro de un   : priorizar la disponibilidad devolviendo un resultado posiblemente obsoleto, o priorizar la consistencia esperando más tiempo (y posiblemente no respondiendo). La vista binaria de CAP no captura la complejidad de estas decisiones. período de tiempo de espera  3. Las propiedades CAP no son binarias  El teorema CAP presenta la consistencia, la disponibilidad y la tolerancia a la partición como propiedades binarias: se tienen o no se tienen. Pero en la práctica,   : las tres propiedades existen en un espectro    no es una propiedad binaria de "activación/desactivación": varía entre el 0 % y el 100 %. Por ejemplo, un sistema puede garantizar una disponibilidad del 99,99 %, pero eso permite pequeños períodos de indisponibilidad. La disponibilidad    tiene distintos niveles, desde la coherencia eventual hasta la coherencia causal y la coherencia fuerte. No todas las aplicaciones requieren linealización completa. La coherencia    en sí no es un evento claro y definido. Los sistemas pueden no estar de acuerdo sobre si existe una partición (por ejemplo, un nodo considera que un tiempo de espera es un error, mientras que otro continúa funcionando normalmente). La tolerancia a particiones  Esta naturaleza continua de las propiedades hace que CAP sea demasiado simplista para modelar las complejidades de los sistemas distribuidos modernos.  Teorema PACELC  Si bien el CAP revolucionó nuestra comprensión de las compensaciones en los sistemas distribuidos, no es la última palabra sobre el tema.   se considera un enfoque alternativo para el diseño de sistemas distribuidos. Se basa en el modelo CAP, pero además de la consistencia, la disponibilidad y la tolerancia a las particiones, también incluye la latencia y la exclusión lógica entre combinaciones de estos conceptos. El teorema PACELC descrito por Daniel J. Abadi  PACELC introduce dos modos de funcionamiento distintos para sistemas distribuidos:    (   ): ¿Qué compensación hace el sistema cuando se produce una partición? Aquí, volvemos a analizar la compensación CAP clásica entre   y   . Modo de partición PAC disponibilidad (A) consistencia (C)    (   ): ¿Qué compensación hace el sistema cuando no hay partición y la red funciona normalmente? En este modo, el sistema se enfrenta a una compensación diferente: entre   y   .  Modo Else ELC latencia (L) consistencia (C)  El equilibrio entre latencia y consistencia  Si bien las particiones son inevitables en los sistemas distribuidos, son poco frecuentes en comparación con los desafíos que surgen durante el funcionamiento normal. En los sistemas distribuidos modernos,   suele ser un cuello de botella más grande que las particiones de red, en particular para aplicaciones a escala global. Aquí es donde se centra   : abordando las desventajas que se producen cuando el sistema funciona sin particiones. A diferencia de CAP, que se centra únicamente en el comportamiento durante escenarios de falla, PACELC enfatiza las decisiones que los arquitectos deben tomar todos los días para equilibrar   y   : la latencia PACELC la latencia (L) la consistencia (C)    requiere coordinación y sincronización entre nodos para mantener una vista unificada de los datos. Esta sobrecarga genera demoras y reduce los tiempos de respuesta. Una coherencia sólida    (como los que adoptan la consistencia eventual) priorizan la velocidad al relajar las garantías de consistencia. Estos sistemas responden más rápido, pero ocasionalmente pueden devolver datos obsoletos o inconsistentes. Los sistemas de baja latencia  Al ampliar la conversación más allá de las particiones para incluir el funcionamiento normal, PACELC garantiza que el rendimiento diario de los sistemas distribuidos se trate con la importancia que merece.  Envolviéndolo  La formulación del teorema CAP ha sido un acontecimiento significativo en la comunidad, y los estudios sobre su impacto en el diseño de sistemas distribuidos han demostrado que los diseñadores de sistemas distribuidos no deben limitar el sistema a dos propiedades, sino que deben esforzarse por maximizar las garantías requeridas en cada caso particular. Para ello, es razonable dividir el sistema en segmentos, cada uno de los cuales tiene sus propios requisitos, y diseñar el sistema en función de los requisitos de cada uno de los segmentos.  El teorema CAP ha sido una piedra angular del pensamiento de sistemas distribuidos durante décadas. Nos brindó un marco para razonar sobre las compensaciones inherentes de la consistencia, la disponibilidad y la tolerancia a las particiones. Pero, en muchos sentidos, es una simplificación de la realidad, que supone opciones binarias e ignora factores críticos como la latencia.  PACELC se basa en el CAP, reconociendo que:   Existen compensaciones incluso cuando no existen particiones.    en el diseño de sistemas distribuidos. La latencia es una preocupación de primera clase  Tanto CAP como PACELC son herramientas valiosas, pero ninguna de ellas es una receta paso a paso para construir sistemas. En cambio, proporcionan   para evaluar las ventajas y desventajas y comprender los límites de las arquitecturas distribuidas. modelos mentales  Materiales adicionales   La PAC doce años después: cómo han cambiado las "reglas"   Cassandra: La guía definitiva    y  Por favor, dejen de llamar a las bases de datos CP o AP Una crítica del teorema CAP por Martin Kleppmann   Notas sobre sistemas distribuidos para jóvenes   ¡Gracias por leer!   ¿Tienes curiosidad sobre algo o tienes ideas para compartir? ¡Deja tu comentario a continuación! Echa un vistazo   o sígueme a través de   ,   o   . a mi blog LinkedIn Substack Telegram

Subscribe

Buy My Book

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Make resilience your competitive advantage

Por qué los sistemas distribuidos no pueden tenerlo todo

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps