Supongamos que Alice y Joe leen el mismo elemento de datos de Couchbase Server. ambos cambiaron los datos, y luego ambos trataron de escribir las nuevas versiones de nuevo a la base de datos. ¿De quién deben guardarse los cambios? ¿Los de Alice? ¿Los de Joe? ¿Ninguno de los dos? ¿Una combinación? Son preguntas como éstas las que determinan el ganador en el debate sobre el bloqueo pesimista frente al optimista.
En concreto, los desarrolladores utilizan el bloqueo para serializar el acceso a los elementos de datos compartidos. Pero, ¿qué esquema de bloqueo debe elegir para su aplicación?
En este blog, voy a explicar el bloqueo optimista frente al bloqueo pesimista y las diferencias entre ambos. También hablar de las API de bloqueo optimista y pesimista que se pueden utilizar en Couchbase Servidor para controlar el acceso simultáneo a sus datos.
¿Qué es el bloqueo optimista en Couchbase Server?
Supongamos que estamos construyendo una aplicación online tipo wikipedia usando Couchbase Server: los usuarios pueden actualizar un artículo y añadir otros nuevos. Supongamos que Alice utiliza esta aplicación para editar un artículo en bicicletas para corregir una información. Alice abre el artículo y hace esos cambios, pero antes de pulsar guardar, se distrae y se aleja de su mesa. Mientras tanto, supongamos que Joe se da cuenta del mismo error en el artículo sobre bicicletas y quiere corregir el error.
Si se utiliza el bloqueo optimista en la aplicación, Joe puede editar el artículo y guardar sus cambios. Cuando Alice vuelva y quiera guardar sus cambios, Alice o la aplicación querrán manejar las últimas actualizaciones antes de permitir que la acción de Alice cambie el documento. Optimista El bloqueo adopta la visión "optimista" de que los conflictos de datos debidos a ediciones concurrentes ocurren raramente, por lo que es más importante permitir ediciones concurrentes.
¿Qué es el bloqueo pesimista en Couchbase Server?
Ahora supongamos que su proceso de negocio requiere acceso exclusivo a uno o más documentos o un grafo de documentos. Volviendo a nuestro ejemplo anterior, cuando Alicia está editando no quiere que ningún otro usuario edite el mismo documento. Si Joe intenta abrir la página, tendrá que esperar hasta que Alice haya liberado el candado.
Con el bloqueo pesimista, la aplicación tendrá que obtener explícitamente un bloqueo sobre el documento para garantizan el acceso exclusivo del usuario. Cuando el usuario termina de acceder al documento, los bloqueos pueden eliminarse manualmente o mediante un tiempo de espera.
¿Cuál elegir?
La respuesta es que no hay una respuesta correcta. depende. Debe elegir su cerradura en función de los requisitos de su aplicación.
A menos que espere que un documento sea muy disputado, el bloqueo optimista va a ser mucho menor sobrecarga que el bloqueo pesimista: coja el elemento que necesite, actualícelo rápidamente e intente to aplicarlo. Si algún otro actor del sistema se te adelanta, puedes volver a intentarlo hasta que lo consigas.
Con el bloqueo pesimista, puede obtener acceso exclusivo a un elemento determinado - ningún otro hilo puede acceder al elemento mientras está bloqueado. Debes asegurarte de liberar el bloqueo durante los fallos. Imagina, yo tengo el objeto cereal y no lo cederé hasta que consiga el objeto leche. Pero tú tienes el objeto leche y no lo entregarás hasta que consigas el objeto cereal. Los tiempos de espera se pueden utilizar para romper posibles bloqueos o para tratar con clientes que no liberan el bloqueo.
Para simplificar, los usuarios pueden elegir la misma estrategia de bloqueo en toda su aplicación. Este funciona bien si los requisitos de acceso de todos los diferentes objetos de la aplicación son los siguientes pero, en realidad, no es así: los distintos objetos de aplicación tienen distintos accesos requisitos. Por ejemplo, en el caso de los juegos sociales -
1. La información del inventario del personaje y del jugador es muy consultada durante el juego,
que requieren un acceso rápido de lectura-escritura. Primera opción: utilizar un bloqueo optimista. Siguiente opción -
Cierre pesimista
2. Las cuentas y preferencias de los jugadores se leen durante el inicio de sesión o al comienzo de una partida.
pero no se actualiza con frecuencia. El bloqueo optimista también funcionaría bien en este caso.
Obtención de un bloqueo pesimista en Couchbase Server
La obtención de un bloqueo en Couchbase Server consiste en los siguientes pasos :
- Utilice la API get-and-lock para obtener un valor para una clave determinada y bloquear esa clave
- La aplicación tiene ahora el control exclusivo del documento
Obtención de un bloqueo optimista en Couchbase Server
La obtención de un bloqueo en Couchbase Server consiste en los siguientes pasos :
- Utilice la API de comprobación y fijación (CAS) para recuperar un número de revisión CAS
Liberar un bloqueo en Couchbase Server
Siga estos pasos para desbloquear manualmente un candado:
- Utiliza CAS para modificar el valor y liberar el bloqueo
Entre bastidores de CAS
La operación CAS es un concepto simple que puede utilizarse para construir mecanismos de control de concurrencia más avanzados. CAS determina si un objeto ha sido actualizado por otro cliente entre el momento en que se leyó inicialmente y el momento en que se intentó guardar. Si el objeto ha sido modificado por otro cliente, se produce un error y la aplicación tiene que volver a leer el valor y reintentar la operación. Si los objetos no están en alta contención, la transformación de los datos es idempotente y el reintento de la operación se realiza fácilmente sin demasiado trabajo perdido, el bloqueo optimista es una buena solución que proporciona un alto rendimiento en el caso medio.
Una forma común de interactuar con CAS implica un bucle CAS como el que se muestra en la comunidad desarrollada ir cliente memcached.
Por ejemplo: Imagina que hay 3 clientes, como se muestra en el diagrama de interacción siguiente. Los tres clientes intentan actualizar el objeto X mediante CAS; cada cliente lo consigue, de uno en uno.
No has liberado el bloqueo, deja que Couchbase lo haga por ti
Al realizar una operación get-and-lock se proporciona como parámetro una caducidad para el bloqueo. El tiempo por defecto que una clave puede estar bloqueada es de 15 segundos. Después de 15 segundos, si no liberas el bloqueo manualmente, Couchbase lo libera automáticamente.
Reflexiones finales sobre el bloqueo pesimista y optimista en las bases de datos
El bloqueo optimista puede no ser la mejor solución para todas las situaciones. Mientras que algunos casos de uso funcionan bien con el bloqueo optimista, otros pueden necesitar esquemas más estrictos como el bloqueo pesimista.
El bloqueo puede no ser bueno para todos los casos - tu aplicación puede tener un problema si hay una contención de bloqueo. Un hilo puede mantener un bloqueo y ser desprogramado por el sistema operativo. Entonces todos los hilos que quieran adquirir este bloqueo serán bloqueados. Una opción es evitar el bloqueo por completo siempre que sea posible mediante el uso de operaciones atómicas. Estas API pueden ser muy útiles en datos muy disputados.
Sin embargo, si realmente necesitas bloqueo y crees que el bloqueo optimista cubre la mayoría de los casos de uso de tus aplicaciones, el bloqueo optimista usando CAS en Couchbase Server es tan fácil de implementar que no hay razón para que no lo intentes.
Forzar cerraduras es un arte de
legalmente, y con el permiso del usuario, desbloquear una cerradura analizando su
componentes. Aunque apertura de cerraduras se asocia sobre todo con la delincuencia y el robo, se
es una habilidad esencial para un cerrajero.
Buen artículo
¿Hay algún ejemplo de código de esto? Cuando intenté bloquear un objeto usando un pesimista en múltiples hilos no pasó nada, es decir, todos los hilos podían recuperar y guardar el objeto independientemente, como sigue:
fastChangingCouchbaseClient.asyncCas(\"1\", 0l, \"algún objeto\", PersistTo.ZERO);
for (i = 0; i < 5; i++) {
new Thread(() -> {
System.out.println(i + \" INICIO - \" + new Date());
CASValue
La salida es:
0 START - Wed Jul 16 18:23:49 BST 2014
1 START - Wed Jul 16 18:23:49 BST 2014
2 START - Wed Jul 16 18:23:49 BST 2014
3 START - Wed Jul 16 18:23:49 BST 2014
4 START - Wed Jul 16 18:23:49 BST 2014
0 END - Wed Jul 16 18:23:49 BST 2014
1 FIN - Wed Jul 16 18:23:49 BST 2014
2 END - Wed Jul 16 18:23:49 BST 2014
3 FINES - mié Jul 16 18:23:49 BST 2014
4 END - Wed Jul 16 18:23:49 BST 2014
Es decir, sin errores ni bloqueos.
Hola James,
¿Qué versión de Couchbase estás utilizando y qué versión del cliente Java?
Gracias,
Don
He descubierto que el problema anterior es causado por el hecho de que estoy usando '0l\' como el valor cas. Resulta que si se utiliza "0" como el valor de caso entonces cas no está habilitado (por diseño). Una vez que he cambiado el valor inicial cas de '0' a '1' que funcionó.
[...] Bloqueo optimista o pesimista, ¿cuál elegir? Si su aplicación necesita bloqueo, primero considere el uso de CAS (bloqueo optimista) antes de utilizar GetL (bloqueo pesimista). [...]