Deprecated: 函数 get_currentuserinfo 自版本 4.5.0 起已弃用!请使用 wp_get_current_user() 替代。 in /data/home/qxu1142130176/htdocs/wp-includes/functions.php on line 5383
最新消息:

乐观锁的两种实现方式

数据库 前端收藏 1330浏览

什么场景下需要使用锁?

在多节点部署或者多线程执行时,同一个时间可能有多个线程更新相同数据,产生冲突,这就是并发问题。这样的情况下会出现以下问题:
更新丢失:一个事务更新数据后,被另一个更新数据的事务覆盖。
脏读:一个事务读取另一个事物为提交的数据,即为脏读。
其次还有幻读。。
针对并发引入并发控制机制,即加锁。
加锁的目的是在同一个时间只有一个事务在更新数据,通过锁独占数据的修改权。

锁的实现方式

          1、悲观锁(Pessimistic Locking),前提是,一定会有并发抢占资源,强行独占资源,在整个数据处理过程中,将数据处于锁定状态。
          2、乐观锁(Optimistic Locking),前提是,不会发生并发抢占资源,只有在提交操作的时候检查是否违反数据完整性。只能防止脏读后数据的提交,不能解决脏读。
          当然,还有其他的锁机制,暂时不多介绍,着重于乐观锁的实现。
          乐观锁,使用版本标识来确定读到的数据与提交时的数据是否一致。提交后修改版本标识,不一致时可以采取丢弃和再次尝试的策略。
           记录1,id,status1,status2,stauts3,version,表示有三个不同的状态,以及数据当前的版本
           操作1:update table set status1=1,status2=0,status3=0 where id=111;
           操作2:update table set status1=0,status2=1,status3=0 where id=111;
           操作3:update table set status1=0,status2=0,status3=1 where id=111;
           没有任何控制的情况下,顺序执行3个操作,最后前两个操作会被直接覆盖。
           加上version字段,每一次的操作都会更新version,提交时如果version不匹配,停止本次提交,可以尝试下一次的提交,以保证拿到的是操作1提交后的结果。
          这是一种经典的乐观锁实现。
          另外,java中的Compare and Swap即CAS,解决多线程并行情况下使用锁造成性能损耗的一种机制。
          CAS操作包含三个操作数,内存位置(V),预期原值(A)和新值(B)。如果内存位置的值与预期原值相匹配,那么处理器会西东将该位置值更新为新值。否则,处理器不做任何操作。
          记录2: id,stauts,status 包含3种状态值 1,2,3
           操作,update status=3 where id=111 and status=1;
           即 如果内存值为1,预期值为1,则修改新值。对于没有执行的操作则丢弃。

转载请注明:前端收藏 » 乐观锁的两种实现方式