基于数据库来做分布式锁的话，通常有两种做法：
- 基于数据库的乐观锁
- 基于数据库的悲观锁
乐观锁：
乐观锁机制其实就是在数据库表中引入一个版本号（version）字段来实现的。当我们要从数据库中读取数据的时候，同时把这个version字段也读出来，如果要对读出来的数据进行更新后写回数据库，则需要将version加1，同时将新的数据与新的version更新到数据表中，且必须在更新的时候同时检查目前数据库里version值是不是之前的那个version，如果是，则正常更新。如果不是，则更新失败，说明在这个过程中有其它的进程去更新过数据了。
update table set x=x+1, version=version+1 where id=#{id} and version=#{version}; 
如图，假设同一个账户，用户A和用户B都要去进行取款操作，账户的原始余额是2000，用户A要去取1500，用户B要去取1000，如果没有锁机制的话，在并发的情况下，可能会出现余额同时被扣1500和1000，导致最终余额的不正确甚至是负数。但如果这里用到乐观锁机制，当两个用户去数据库中读取余额的时候，除了读取到2000余额以外，还读取了当前的版本号version=1，等用户A或用户B去修改数据库余额的时候，无论谁先操作，都会将版本号加1，即version=2，那么另外一个用户去更新的时候就发现版本号不对，已经变成2了，不是当初读出来时候的1，那么本次更新失败，就得重新去读取最新的数据库余额。
通过上面这个例子可以看出来，使用「乐观锁」机制，必须得满足：
（1）锁服务要有递增的版本号version
（2）每次更新数据的时候都必须先判断版本号对不对，然后再写入新的版本号
悲观锁：
总是假设最坏的情况，每次取数据时都认为其他线程会修改，所以都会加锁（读锁、写锁、行锁等），当其他线程想要访问数据时，都需要阻塞挂起。可以依靠数据库实现，如行锁、读锁和写锁等，都是在操作之前加锁，在Java中，synchronized的思想也是悲观锁。
悲观锁也叫作排它锁，在Mysql中是基于 for update 来实现加锁的，例如：
//锁定的方法-伪代码
public boolean lock(){
connection.setAutoCommit(false)
for(){
result =
select * from user where
id = 100 for update;
if(result){
//结果不为空，
//则说明获取到了锁
return true;
}
//没有获取到锁，继续获取
sleep(1000);
}
return false;
}
//释放锁-伪代码
connection.commit();上面的示例中，user表中，id是主键，通过 for update 操作，数据库在查询的时候就会给这条记录加上排它锁。
（需要注意的是，在InnoDB中只有字段加了索引的，才会是行级锁，否者是表级锁，所以这个id字段要加索引）
当这条记录加上排它锁之后，其它线程是无法操作这条记录的。
那么，这样的话，我们就可以认为获得了排它锁的这个线程是拥有了分布式锁，然后就可以执行我们想要做的业务逻辑，当逻辑完成之后，再调用上述释放锁的语句即可。