En el diseño del sistema de picos, la sobreventa es un problema clásico y común. Cualquier producto tendrá un límite superior. Cómo evitar que el número de personas que realicen un pedido con éxito y compren el producto no supere el límite superior del número de Este es un problema al que debe enfrentarse toda actividad de compra urgente.
1 Descripción del problema de sobreventa
Cuando varios usuarios inician una solicitud de pedido para el mismo producto al mismo tiempo, primero consultan el inventario de productos y luego modifican el inventario de productos, habrá problemas de competencia de recursos, lo que dará como resultado resultados de inventario anormales.
Pregunta: Cuando hay un total de 15 artículos en stock del producto A, el usuario A realiza un pedido de 10 artículos primero y el usuario B realiza un pedido de 8 artículos. En este momento, el inventario solo puede satisfacer a una persona para que lo coloque correctamente. El pedido. Si dos personas envían al mismo tiempo, se sobrevendirá. Problema.
Hay muchas formas de resolver el problema de la sobreventa. El uso de sincronizados puede garantizar la coherencia de los datos, pero es ineficiente e inútil en un entorno distribuido; el uso de tablas de bloqueo de bases de datos provocará un bajo rendimiento de la base de datos. Bajo la condición única, es más apropiado adoptar un bloqueo optimista y el clúster puede considerar el bloqueo distribuido .
2 cerradura optimista
2.1 Introducción al bloqueo optimista
Bloqueo pesimista, pensando que los datos son fácilmente modificados por otros hilos, para asegurar la veracidad de los datos, cada vez que se adquieren y modifican los datos, los datos se bloquean. Por ejemplo, clases sincronizadas y relacionadas con el bloqueo en Java.
Las cerraduras optimistas piensan que no serán interferidas por otros hilos durante la operación, por lo que no bloquean el objeto operado. Durante la actualización, se juzgará si otros subprocesos lo han modificado durante la modificación. Si no se ha modificado, significa que solo está funcionando el hilo actual y los datos se modifican normalmente. Si los datos han sido modificados por otros subprocesos, detendrá la actualización anterior y seleccionará la estrategia de ejecución, como descartar, informar un error y reintentar.
El bloqueo optimista generalmente se implementa mediante el algoritmo CAS. Por ejemplo, clases atómicas y contenedores concurrentes en Java.
2.2 Operación de actualización sin bloqueo
El bloqueo optimista no es una función de la base de datos, sino una práctica de la base de datos. Suponga que se realizan las siguientes operaciones: obtener una fila de datos de la tabla, calcular los datos y actualizar los datos de la fila.
CREATE TABLE theTable(
iD int NOT NULL,
val1 int NOT NULL,
val2 int NOT NULL
)
INSERT INTO theTable (iD, val1, val2) VALUES (1, 2 ,3);
Sin procesamiento de bloqueo
-- 查询数据
SELECT iD, val1, val2
FROM theTable
WHERE iD = @theId;
-- 计算新值
-- 更新数据
UPDATE
theTable
SET
val1 = @newVal1,
val2 = @newVal2
WHERE
iD = @theId;
-- 继续执行
2.3 Implementación del control optimista de bloqueo 1-condicional
--查询数据
SELECT iD, val1, val2
FROM theTable
WHERE iD = @theId;
--计算新值
--更新数据
UPDATE
theTable
SET
val1 = @newVal1,
val2 = @newVal2
WHERE
iD = @theId
AND val1 = @oldVal1
AND val2 = @oldVal2;
--判断影响行数
-- {if AffectedRows == 1 }
-- {继续执行}
-- {else}
-- {数据过期}
-- {endif}
La clave de la operación anterior es verificar la estructura de la instrucción UPDATE y el número de filas afectadas subsiguientes para determinar si alguien ha modificado los datos. Todas las operaciones anteriores no utilizan transacciones, lo que también muestra que la clave del bloqueo optimista no es la transacción en sí.
2.4 Extensión: el uso de transacciones
--查询数据
SELECT iD, val1, val2
FROM theTable
WHERE iD = @theId;
--计算新值
--开始事务，更新数据
UPDATE
theTable
SET
val1 = @newVal1,
val2 = @newVal2
WHERE
iD = @theId
AND val1 = @oldVal1
AND val2 = @oldVal2;
--判断影响行数
-- {if AffectedRows == 1 }
-- COMMIT TRANSACTION; // 提交事务
-- {继续执行}
-- {else}
-- ROLLBACK TRANSACTION; // 回滚事务
-- {数据过期}
-- {endif}
Una vez que se utiliza la transacción, la modificación se puede revertir. A través de la transacción, podemos determinar la cantidad de operaciones para cada reversión, dónde colocar el límite de la transacción y dónde buscar conflictos.
Para otros procesos antes de que se confirme la transacción actual, lo que sucede depende del nivel de aislamiento actual de la base de datos. Tomando SQL Server como ejemplo, su nivel de aislamiento es READ_COMMITTED, y la fila actualizada está bloqueada hasta COMMIT, por lo que "otros procesos" no pueden realizar ninguna operación en la fila (siga esperando), mientras que SELECT (en realidad solo puede ejecutar READ_COMMITTED).
2.5 Implementación de Optimistic Locking 2-Version Number
El uso de números de versión también es una forma común de implementar el bloqueo optimista. Al agregar un campo de versión a la tabla: al leer datos, se lee el valor del campo de versión y los datos se actualizan una vez, el valor de la versión aumenta en 1. Cuando enviamos una actualización, juzgamos si el valor de la última versión de la tabla es coherente con el valor de la versión leída anteriormente. Si es coherente, actualícelo; de lo contrario, se considerará como datos caducados.
--查询数据
SELECT iD,val1,val2,VERSION
FROM theTable
WHERE iD = @theId;
--计算新值
UPDATE
theTable
SET
val1 = @newVal1,
val2 = @newVal2,
VERSION = VERSION + 1
WHERE
iD = @theId
AND VERSION = @oldversion;
--判断影响行数
-- {if AffectedRows == 1 }
-- {继续执行}
-- {else}
-- {数据过期}
-- {endif}
Referencia
https://stackoverflow.com/questions/17431338/optimistic-locking-in-mysql
Este artículo es publicado por OpenWrite , una plataforma de publicación múltiple para blogs .