Modelo de consistencia
Clustron Zaris te ofrece una vista consistente y predecible de tus datos entre nodos. Este artículo explica qué significa eso en la práctica, para que puedas predecir cómo se comportan las lecturas y escrituras — y saber cuándo necesitas añadir coordinación encima.
Qué significa aquí la consistencia
La consistencia trata sobre cómo se comportan los datos cuando ocurre más de una cosa a la vez: varios nodos contienen los datos, varios clientes leen y escriben la misma clave, y las actualizaciones llegan de forma concurrente. El modelo está diseñado para equilibrar tres objetivos — corrección, disponibilidad y rendimiento — de modo que no persigue garantías absolutas a costa de dejar de ser usable.
Un almacén lógico
Incluso en modo distribuido, un almacén se presenta como un único almacén lógico. Direccionas el almacén, no los nodos individuales, y no gestionas la replicación ni enrutas solicitudes a nodos específicos por tu cuenta. Muchos nodos respaldan el almacén, pero razonas sobre una vista consistente:
Varios nodos → una vista consistente
Este es el fundamento sobre el que descansa todo lo demás: el código de tu aplicación trata un almacén distribuido igual que trata uno en proceso.
Cómo se comportan las lecturas y escrituras
Las escrituras se aplican a través del clúster, que mantiene el almacén en un estado consistente a medida que llegan los cambios. No coordinas la replicación entre nodos — esa es responsabilidad del sistema.
Las lecturas devuelven el último valor conocido. De forma crucial, una vez que una escritura tiene éxito, las lecturas posteriores reflejan esa escritura. Este comportamiento de lectura tras escritura (read-after-write) es lo que te permite escribir un valor y luego confiar en leerlo de vuelta, en lugar de dudar sobre si la actualización se ha propagado.
La lectura tras escritura se cumple porque las lecturas van al primario de forma predeterminada, y el primario es donde llegan las escrituras. Si habilitas las lecturas de réplica (AllowReplicaReads) bajo la replicación Async predeterminada, una lectura servida por una réplica rezagada puede devolver datos obsoletos — por lo que la lectura tras escritura deja de estar garantizada. Consulta Particionamiento y replicación para los detalles de enrutamiento y de los modos de replicación.
Para la mayoría de las aplicaciones, el resultado es que interactúas con el almacén como si fuera una única instancia: lecturas y escrituras predecibles, sin replicación manual, y sin tener que llevar la contabilidad de la consistencia entre nodos.
Configurar la consistencia
Los controles que dan forma a estas garantías viven en la configuración del almacén. Los valores predeterminados (replicación Async, lecturas solo del primario) te dan la lectura tras escritura de serie; cámbialos cuando una carga de trabajo necesite otras concesiones:
- Modo de replicación —
replication.mode:Async(predeterminado; latencia más baja, un failover puede perder las escrituras más recientes) oSync(espera a las réplicas, mayor durabilidad). ConSync,replication.quorum(All,MajorityoBestEffort) decide cuántas réplicas deben confirmar. - Lecturas de réplica —
reads.allowReplicaReads(predeterminadofalse). Habilítalo solo para cargas de trabajo con muchas lecturas que toleren lecturas ligeramente obsoletas; intercambia la lectura tras escritura por throughput de lectura.
{
"replication": { "factor": 2, "mode": "Sync", "quorum": "Majority" },
"reads": { "allowReplicaReads": false }
}
El factor de replicación se establece al crear el almacén (New-ZrStore -ReplicationFactor). Para cada campo y valor predeterminado, consulta la referencia de configuración.
Actualizaciones concurrentes a la misma clave
Cuando varios clientes actualizan la misma clave al mismo tiempo, el almacén gestiona las operaciones de forma segura y llega a un resultado consistente — no acabarás con un valor corrupto o escrito a medias. Lo que una escritura simple no hace es comprobar si alguien más cambió la clave primero.
Un PutAsync simple es una escritura a ciegas: sobrescribe lo que haya ahí, de modo que dos clientes que actualizan la misma clave de forma concurrente pueden producir una actualización perdida — la segunda escritura reemplaza en silencio a la primera. Si la corrección de una actualización depende del valor que leíste, no confíes en las escrituras ordinarias. Usa una transacción, que detecta un cambio conflictivo y falla en lugar de sobrescribir, o un lock o lease para asegurar que solo un cliente actualiza la clave a la vez.
El mismo modelo en ambos modos
El modelo de consistencia es idéntico en los modos en proceso y distribuido. Tu aplicación no necesita lógica diferente según dónde se ejecute el almacén, que es lo que hace seguro desarrollar contra un almacén en proceso y desplegar contra uno distribuido.
Cuándo necesitas garantías más fuertes
El comportamiento predeterminado es suficiente para lecturas y escrituras sencillas. Cuando una operación necesita orden, exclusividad o semántica de todo-o-nada, recurre a las primitivas de coordinación:
- Locks para dar a un cliente acceso exclusivo y evitar actualizaciones conflictivas.
- Transacciones para agrupar varias operaciones de modo que se apliquen juntas, con detección de conflictos mediante concurrencia optimista.
- Leases para gestionar la propiedad de un recurso y liberarla automáticamente ante un fallo.
Estas te permiten optar por una coordinación más fuerte exactamente donde la necesitas, sin pagar por ella en cada operación.