并发更改引发的问题
注意下面的例子:
事务1 | 事务2 |
---|---|
BEGIN; | BEGIN; |
SELECT data FROM test WHERE id = 1; | |
得到 AB | SELECT data FROM test WHERE id = 1; |
得到 AB | |
UPDATE test SET data = ‘CB’ WHERE id = 1; | |
UPDATE test SET data = ‘AD’ WHERE id = 1; | |
等待事务1 | |
COMMIT; | 等待事务1 |
COMMIT; | |
SELECT data FROM test WHERE id = 1; | |
得到 AD |
看到什么问题没?显然,事务1的更改被覆盖了。
解决方法
悲观锁
当我们要对表中的一条数据进行修改的时候,为了避免同时被其他人修改,最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制,先锁定再修改的方式被称为悲观并发控制(又名“悲观锁”,Pessimistic Concurrency Control,缩写“PCC”)。
举例如下:
事务1 | 事务2 |
---|---|
BEGIN; | BEGIN; |
SELECT data FROM test WHERE id = 1 FOR UPDATE; | |
得到 AB | SELECT data FROM test WHERE id = 1 FOR UPDATE; |
等待事务1 | |
UPDATE test SET data = ‘CB’ WHERE id = 1; | 等待事务1 |
等待事务1 | |
COMMIT; | 等待事务1 |
得到 CB |
乐观锁
乐观锁是相对悲观锁而言的,乐观锁假设数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则返回给用户错误的信息,让用户决定如何去做。乐观锁不会刻意使用数据库本身的锁机制,而是依据数据本身来保证数据的正确性。
举例如下:
事务1 | 事务2 |
---|---|
BEGIN; | BEGIN; |
SELECT data FROM test WHERE id = 1; | |
得到 AB | SELECT data FROM test WHERE id = 1; |
得到 AB | |
UPDATE test SET data = ‘CB’ WHERE id = 1 AND data = ‘AB’; | |
UPDATE test SET data = ‘AD’ WHERE id = 1 AND data = ‘AB’; | |
等待事务1 | |
COMMIT; | 等待事务1 |
COMMIT; | |
SELECT data FROM test WHERE id = 1; | |
得到 CB |
显然,事务1更新成功,事务2实际上是更新失败的,可以尝试再次更新。
总结
-
乐观锁并未真正加锁,效率高。一旦锁的粒度掌握不好,更新失败的概率就会比较高,容易发生业务失败。
-
悲观锁依赖数据库锁,效率低。但是更新失败的概率比较低。