La PAC es bien conocida por muchos, así que no voy a dedicar tiempo a explicar aquí el material de introducción, pero quería identificar correctamente un concepto erróneo que ha surgido varias veces en conversaciones recientes. Aquí está el remate de este post: El comportamiento 'CAP' de Couchbase Server como un solo cluster vs Couchbase Server con XDCR es diferente.
Empecemos con el despliegue de un solo cluster de Couchbase Server: CAP es generalmente demasiado alto nivel para describir todos los colores de un sistema pero Couchbase Server es principalmente referido como un sistema CP con opciones para reemplazar C en favor de A (por ejemplo auto-failover).
Sin embargo con un despliegue multi cluster con XDCR, Couchbase Server te proporciona AP. Puedes escribir en uno de los clusters y nosotros detectaremos y resolveremos el conflicto dándote consistencia eventual entre múltiples clusters (recomendamos encarecidamente que entiendas cómo detectamos y resolvemos estos conflictos para estar seguro de que el efecto es el que esperas). Couchbase Server puede ser un sistema más CP o más AP dependiendo de la topología de despliegue.
Voy a inyectar una advertencia y esta discusión también vienen en varias opiniones que tenemos en la ingeniería aquí también: CAP es una definición de alto nivel. Es una buena primera introducción para entender el enfoque de un sistema. Sin embargo, no es ideal para describir todos los colores del sistema. Con eso, la tabla adjunta debería darte más detalles sobre cómo funciona el balance CAP de Couchbase Server. Recorrido rápido por las columnas: La tabla mira varias topologías de despliegue con XDCR. Los Dominios de Fallo describen el dominio de fallo para la topología en cuestión. CAP Balance describe el AP-nees vs CP-ness del sistema. usa la siguiente tabla con precaución.
Por último, si no has mirado XDCR como un servicio de disponibilidad, la siguiente tabla es un buen punto de partida. Si quieres leer más sobre XDCR y su comportamiento, también te recomiendo que descargues el siguiente documento: Desarrollo de aplicaciones con XDCR
Gracias por leer y, como siempre, los comentarios son bienvenidos.
Cihan Biyikoglu - Gestión de productos @ Couchbase
Topología de despliegue |
Dominio de fallos |
Balance de la PAC |
Comentarios |
|
Clúster de un único servidor Couchbase |
Dominio de fallos a nivel de nodo (por ejemplo, fallos de HW, fallos de comunicación entre nodos). |
Puede ser configurado CP y puede ser sintonizado para estar Disponible a través de auto failover o con réplicas de lectura y más. |
Couchbase Server permite la lectura de vbuckets activos o réplicas, por lo que puede ser ajustado con auto-failover para darle disponibilidad de escritura después de un corto tiempo de failover. |
|
Clusters de servidores Couchbase con XDCR unidireccional para HA/DR |
Fallos en nodos y clústeres (ejemplos: fallos en DC causados por desastres naturales). |
AP a través de clústeres con XDCR unidireccional con protección contra fallos en todo el clúster o en los nodos. Mismo "equilibrio CAP" dentro de cada clúster para fallos de nodo. |
Unidireccional con capacidad computacional pasiva en un segundo sitio/centro de datos. El clúster de destino se puede utilizar para lecturas consistentes durante el estado estacionario y se puede promover a lectura/escritura cuando falla el clúster de origen. |
|
Clusters de servidores Couchbase con XDCR bidireccional para HA/DR |
Fallos en nodos y clústeres (ejemplos: fallos en DC causados por desastres naturales). |
AP a través de clústeres con XDCR bidireccional con protección contra fallos en todo el clúster o en los nodos. Mismo "equilibrio CAP" dentro de cada clúster para fallos de nodo. |
Bidireccional con capacidad computacional activa/dividida entre sitios/centros de datos. El clúster de destino puede utilizarse para lecturas y escrituras coherentes durante el estado estacionario. Pueden producirse conflictos de escritura si se muta la misma clave en ambos clústeres. Muchos clientes minimizan los conflictos de escritura segmentando el tráfico de escritura en rangos de claves que no se solapan entre los clústeres de origen y destino. |
