共计 1376 个字符,预计需要花费 4 分钟才能阅读完成。
悲观锁 (Pessimistic Lock)
顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会 block 直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。
乐观锁 (Optimistic Lock)
顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于 write_condition 机制的其实都是提供的乐观锁。
两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行 retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。本质上,数据库的乐观锁做法和悲观锁做法主要就是解决下面假设的场景,避免丢失更新问题:
一个比较清楚的场景
下面这个假设的实际场景可以比较清楚的帮助我们理解这个问题:假设当当网上用户下单买了本书,这时数据库中有条订单号为 001 的订单,其中有个 status 字段是’有效’, 表示该订单是有效的;
后台管理人员查询到这条 001 的订单,并且看到状态是有效的用户发现下单的时候下错了,于是撤销订单,假设运行这样一条 SQL:update order_table set status =‘取消’where order_id = 001;
后台管理人员由于在 b 这步看到状态有效的,这时,虽然用户在 c 这步已经撤销了订单,可是管理人员并未刷新界面,看到的订单状态还是有效的,于是点击”发货”按钮,将该订单发到物流部门,同时运行类似如下 SQL,将订单状态改成已发货:updateorder_table set status =‘已发货’where order_id = 001
观点 1:只有冲突非常严重的系统才需要悲观锁;“所有悲观锁的做法都适合于状态被修改的概率比较高的情况,具体是否合适则需要根据实际情况判断。”,表达的也是这个意思,不过说法不够准确;的确,之所以用悲观锁就是因为两个用户更新同一条数据的概率高,也就是冲突比较严重的情况下,所以才用悲观锁。
观点 2:最后提交前作一次 selectfor update 检查,然后再提交 update 也是一种乐观锁的做法,的确,这符合传统乐观锁的做法,就是到最后再去检查。但是 wiki 在解释悲观锁的做法的时候,’Itis not appropriate for use in web application development.’,现在已经很少有悲观锁的做法了,所以我自己将这种二次检查的做法也归为悲观锁的变种,因为这在所有乐观锁里面,做法和悲观锁是最接近的,都是先 selectfor update,然后 update