数据库锁机制

数据库是一个多用户共享的资源，这样的话对于多个用户在存取同一数据的时候，就会出现问题，举个最经典的问题----票务系统，如何保证数据的正确性。当只剩下最后1张票的时候，两个用户同时取到数据并更新，那么最后是谁买到票了呢？

数据库事物

数据库事务是指单个逻辑工作单元执行一系列操作，要么完成执行，要么完成不执行。数据库事务必须满足ACID(原子性、一致性、隔离性、持久性)。

原子性

对于其数据的修改，要么全部执行，要么完全不执行。原子性消除了系统处理操作子集的可能。

一致性

事务完成时，必须是所有的数据都保持一致

隔离性

由并发事务所做的修改必须与任何其他事务并发事务所做的修改隔离

持久性

完成事务后，对系统的修改时永久性的

锁

今天我们所讲的数据库是MySQL。InnoDB支持行/表级锁，默认行级锁。

共享锁

又称读锁（S锁），是读取操作创建的锁，其他用户可以并发的读取数据，但任何事务都不能对数据修改，直至释放所有的共享锁。

用法

SELECT ... lock in share mode;

排他锁

又称写锁（X锁），如果事务A对某数据加上了排他锁后，别的事物不能对该数据加任何类型的锁

用法

SELECT ... FOR UPDATE;

共享锁和排他锁

1、在同一资源上面，不能共同存在共享和排他
2、可以共同存在共享锁
3、不能共同存在排他锁

行级锁和表锁

行级锁：一种X锁，防止其他事务修改加锁的这行数据
如果被锁定的字段不是主键，也没有针对它建立索引，数据库会锁住扫过的所有数据。
表级锁：对当前整张表进行加锁

乐观锁

乐观锁是基于一种具有“乐观”的思想，假设数据库操作的并发非常少，多数情况下是没有并发的，更新是按照顺序执行的，少有的一些并发通过版本控制来防止脏数据的产生。事务每次操作的时候，别的事务都不会修改这些数据。所以在访问之前不要求上锁，只是在更新修改操邹的时候判断一下在访问期间有没有别的事务对数据修改，判断是否冲突。这种适合多读的应用类型。
通常可以在数据表中加一个version字段，每次操作，version加1。更新是判断version的值是否和之前相等；或者判断时间戳来控制版本。
乐观锁在同一时刻，只有一个请求会成功，适用并发不高的场景。

悲观锁

事务提交操作的时候，别的事务也对该数据块进行了修改，所以访问之前都需要上锁。这个需要数据库自己实现，我们直接调用数据库相关语句就可以了。

select ... where id = $id for update

悲观锁是在数据库引擎层次实现的，它能够阻止所有的数据库操作。但是为了更新一条数据，需要提前对这条数据上锁，直到这条数据处理完成，事务提交，别的请求才能更新数据，因此，悲观锁的性能比较低下，但是由于它能够保证更新数据的强一致性，是最安全的处理数据库的方式，因此，有些账户、资金处理系统仍然使用这种方式，牺牲了性能，但是获得了安全，规避了资金风险。

参考

• 数据库并发锁机制