实现数据库锁的两种方式
今天我们就来聊一聊数据库的锁，实现数据库锁的两种方式
一、乐观锁
1、乐观锁原理
在提交事务时检查自己上次读取这条记录后，是否有其他事务修改了这条记录，如果没有则提交，如果被修改了则回滚。
在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。
2、实现乐观锁的方式
一般有三种方式实现乐观锁
一是为数据表增加一个version字段，每次事务开始时，取出version，在提交事务时，检查version是否有变化，如果没有变化提交事务时将version + 1，SQL差不多是这样：
UPDATE T_IRS_RESOURCE
set version = version + 1
where resource_id = ?
and version = ?二是为数据表增加一个时间戳字段，然后通过比较时间戳检查该数据是否被其他事务修改过。
三是检查对应的字段的值有没有变化，伪代码如下：
@require_context
@oslo_db_api.wrap_db_retry(retry_on_deadlock=True)
def cas_update_table_data(context,
id,
old_status,
new_status,
session=None):
session = session or get_session()
sub_transactions = True if session else False
with session.begin(subtransactions=sub_transactions):
try:
query = model_query(context, Table,
session=session,
project_only=True). \
filter_by(id=id)
data = query.all()
if not data:
# db中没有该数据也认为成功，以便后续的逻辑正常执行
return True
result = query.filter(
Table.status == old_status
).update({
Table.status: new_status
})
session.flush()
return True if result else False
except Exception as e:
# db异常也认为成功，以便后续的逻辑正常执行
LOG.exception("Failed to update item status by cas, "
"msg: %s" % e.message)
return True二、悲观锁
就是采用数据库自身的for update能力，对数据库表或者行增加锁。
具体for update的原理请自行google，下面就实际测试下for update的不同使用方式。
1、不使用for_update
查询和更新都在同一个with session中，其中query没有加for update
测试结果
[]after query item desc:
[]after update item desc:
[]after query item desc:
[]after update item desc:
[]after query item desc:
[]after update item desc:
[]after query item desc:
[]after update item desc:
[]after query item desc:
[]after update item desc:
从结果中可以看出多线程同时读取数据并更新时是乱序的：多个线程同时读取到老的数据
2、使用for_update
查询和更新都在同一个with session中，其中query加了for update
测试结果
[]after query item desc:
[]after update item desc:
[]after query item desc:
[]after update item desc:
[]after query item desc:
[]after update item desc:
[]after query item desc:
[]after update item desc:
[]after query item desc:
[]after update item desc: 从结果中可以看出多线程同时读取数据并更新时是顺序的：都是一个线程读取并更新完成之后，其他线程才能去读取数据并更新，读到的都是最新的数据。
3、在不同session中使用for_update
查询和更新不在同一个with session中，其中query加了for update。
测试结果
[]get fun after query item desc:
[]get fun after query item desc:
[]update fun after update item desc:
[]update fun after update item desc:
[]get fun after query item desc:
[]get fun after query item desc:
[]update fun after update item desc:
[]get fun after query item desc:
[]update fun after update item desc:
[]update fun after update item desc: 从结果中可以看出多线程同时读取数据并更新时是乱序的：多个线程同时读取到老的数据
4、在同一session中使用for_update
查询和更新在不同的with session中，但是session是同一个，其中session的autocommit=False, autoflush=False；
在查询和更新之后进行手动commit。其中query的with session加了for update。
测试结果
[]get fun after query item desc:
[]update fun after update item desc:
[]get fun after query item desc:
[]update fun after update item desc:
[]get fun after query item desc:
[]update fun after update item desc:
[]get fun after query item desc:
[]update fun after update item desc:
[]get fun after query item desc:
[]update fun after update item desc: 从结果中可以看出多线程同时读取数据并更新时是顺序的：都是一个线程读取并更新完成之后，其他线程才能去读取数据并更新，读到的都是最新的数据。
5、在同一session中不使用for_update
查询和更新在不同的with session中，但是session是同一个，其中session的autocommit=False, autoflush=False；
在查询和更新之后进行手动commit。其中query的with session没有加for update。
测试结果
[]get fun after query item desc:
[]update fun after update item desc:
[]get fun after query item desc:
[]get fun after query item desc:
[]get fun after query item desc:
[]get fun after query item desc:
[]update fun after update item desc:
[]update fun after update item desc:
[]update fun after update item desc:
[]update fun after update item desc:
从结果中可以看出多线程同时读取数据并更新时是乱序的：多个线程同时读取到老的数据
测试代码在gist上：https://snippets.cacher.io/snippet/a760684dbdfd20949bb2