MySQL/InnoDB的加锁，是一个老生常谈的话题。在数据库高并发请求下，如何兼顾数据完整性与用户体验的敏捷性是一代又一代程序员一直在思考的问题。
乐观锁
乐观锁之所以叫乐观，是因为这个模式不会对数据加锁。而是对数据操作保持一种乐观的心态，认为不会产生并发操作问题(即不会有其他线程同时对数据进行修改)。乐观锁查询数据时直接进行查询，更新时会判断其他线程有没有对数据进行修改，如果没有则进行更新，反之则拒绝更新。
乐观锁最常用数据版本(Version)的记录机制实现。即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加1。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。
示例：
1、数据库表三个字段，分别是id、value、versionselect id,value,version from TABLE where id = #{id}
2、每次更新表中的value字段时，为了防止发生冲突，需要这样操作：update TABLE
set value=2,version=version+1
where id=#{id} and version=#{version}
在larave中，我们可以在数据库维护一个lock_version字段，每次更新操作时，校验lock_version，并在更新完成后增加lock_version的值。
悲观锁
悲观锁就比较狠了，悲观锁对数据做“有罪推定”。即在操作数据时，默认此操作会出现数据冲突，所以在进行每次操作时都要加锁才能进行对相同数据的操作。一旦加锁，不同线程同时执行时，只能有一个线程执行，其他的线程在入口处等待，直到锁被释放。
悲观锁可以由数据库语句实现，分为共享锁和排它锁。
共享锁 (lock in share mode)
共享锁又称读锁 (read lock)，是读取操作创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改(获取数据上的排他锁)，直到已释放所有共享锁。如果事务对读锁进行修改操作，很可能会造成死锁。
在Laravel中，我们在构造查询时，可以使用 sharedLock 方法为运行语句增加一把”共享锁“。DB::table('users')->where('votes', '>', 100)->sharedLock()->get();
上面这个查询等价于下面这条 SQL 语句：select * from `users` where `votes` > '100' lock in share mode
注意
在查询语句后面增加 LOCK IN SHARE MODE 后，Mysql会对查询结果中的每行都加一个共享(读)锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请共享锁，否则会被阻塞。 其他线程也可以读取使用了共享锁的表，而且这些线程读取的是同一个版本的数据。
加上共享锁后，对于update，insert，delete语句会自动加排它锁。
排它锁 (for update)
排他锁又称写锁(exclusive lock or writer lock)。若某个事务对某一行加上了排他锁，只能这个事务对其进行读写，在此事务结束之前，其他事务不能对其进行加任何锁，其他进程可以读取，不能进行写操作，需等待其释放。排它锁会阻塞所有的排它锁和共享锁。
在Laravel中，我们在构造查询时，可以使用 lockForUpdate 方法为运行语句增加一把“排它锁”，避免选择行被其它共享锁修改或删除：DB::table('users')->where('votes', '>', 100)->lockForUpdate()->get();
上面这个查询等价于下面这条 SQL 语句：select * from `users` where `votes` > '100' for update
注意
for update 与 lock in share mode 都是用于确保被选中的记录值不能被其它事务更新(上锁)，两者的区别在于 lock in share mode 不会阻塞其它事务读取被锁定行记录的值，而 for update 会阻塞其他锁定性读对锁定行的读取(非锁定性读仍然可以读取这些记录，lock in share mode 和 for update 都是锁定性读)。
总结
乐观锁适用于读多写少的情况，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。
但如果经常产生冲突，还是使用悲观锁更稳定、可靠一些。
参考链接
