作者：林冠宏 / 指尖下的幽灵
掘金：
博客：
GitHub ：
腾讯云专栏：
虫洞区块链专栏：
距离上次择文发表，两月余久。2018年也即将要结束了，目前的工作依然是与区块链应用相关的，也很荣幸在9月初受邀签约出版暂名为《区块链以太坊DApp实战开发》一书，预计在明年年初出版。
这次让我有感记录这篇文章的原因是最近在使用Go语言重写一个原来由PHP语言编写的交易所订单撮合模块的时候，发现订单撮合的部分代码在撮合的时候，为保证各表数据在并发情况下不出现读写脏乱而采用了全局锁表的操作。后面我采用了共享锁的形式进行了修改，于刚刚重写完，并进行了并发单元测试，表现正常。
- 场景描述
- 解决问题
- 订单撮合实例
- 共享锁 与 排他锁
- 前置知识
- 行锁与表锁
- 两种行锁的特点
- 两种行锁的加锁方式
- 锁的释放
- 操作例子
- 改造代码片段
高并发的业务常见是有很多种类的，最常见的例如秒杀抢购。它们都有一个共同的特点就是数据更新都比较频繁，通常涉及到多张业务表的增改操作，且表格越多的，要考虑的问题也越多。
订单撮合可以理解为订单买卖，拿这个为例子进行列举一个可能会导致数据错乱的情形。假设现在买卖手机，A用户是要买手机的，B用户是卖手机的。A的买入单订单1，和B的卖出单订单2，订单2卖出手机，一台手机卖1000元。此时A的网上的钱包余额是1001元，刚好比手机价格高，是可以成交的。
此时记录用户钱包钱数数量的是一张数据表。每次花费了钱或者增加了钱，都要更新这个表。
当这两笔订单进入到系统里面进行撮合。假设系统的订单撮合运行流程如下图所示：
当判断条件进行A用户的钱包余额判断的时候，发现 1001 > 1000，结果是通过，此时准备进入“进行记录更细”步骤。但是，就在这个过程之中的时间差中，A用户使用了系统的网上提现功能，并成功转出了10元，剩余的是1001 - 10 = 991元。但是由于撮合系统的余额判断过程以及通过了，导致下面的交易流程依然能进行，最终A用991元买了B的1000元售价的手机。
上述的常见问题是一个很简单的模型，现实的系统中往往是更复杂的。但是它所体现出的问题却是真实存在的，对于这类问题，有很多解决方案。其中，就可以考虑使用数据库的锁。
本文要介绍的是MySQL数据库的共享锁 与 排他锁，其它的不作说明或引申。
下面的截图就是我所重写好的撮合系统原始的PHP代码，所使用了表锁的方式来解决前面的并发读写导致数据脏乱的问题。这种方式虽然是解决了问题，但是导致了性能低下的问题。
- MySQL 是数据库，不是
数据库引擎
- MySQL有两种常用存储引擎:
MyISAM和InnoDB
-
MyISAM不支持事务操作，InnoDB支持事务操作
- MySQL 的锁分有
行锁 和 表锁
- MyISAM 只有表锁
- Innodb 行锁，表锁都有
- 行锁中有
共享锁和排他锁
-
共享锁 简称 S锁，排他锁简称 X锁
简述：
行锁，锁的是表中对应的行，只限制当前行的读写。 表锁，锁的是整张表，限制的是整张表的数据读写。
比较：
- 行锁，计算机资源开销大，加锁慢；会出现
死锁；锁定粒度最小，锁冲突的概率最低，并发度最高，性能高。
- 表锁，计算机资源开销小，加锁快；不会出现
死锁；锁定粒度大，锁冲突的概率最高，并发度最低，性能低。
共享锁
A 对数据 B 加了 共享锁，A能读取和修改数据B，C 等其它只能读取数据B，但是不能修改。直至A释放了B的锁。
排他锁
A 对数据 B 加了 排他锁，A能读取和修改数据B，C 等其它不能再对数据B加其它的锁。直观体验是不能修改，不能使用含有加锁动作的select读取。
要注意的是：
- 行锁的实现SQL语句中必须要有索引的限制条件，例如含有
where id=xxx 这类语句。
- 行锁的实现SQL语句没有索引限制条件会变成
表锁
-
InnoDB引擎 默认的修改数据类SQL语句，update,delete,insert等，都会自动给涉及到的数据加上排他锁。
共享锁
- select 的添加可以使用满足格式：
select ... where 索引限制 lock in share mode 的语句。例如“select name from lgh_user where id = 1 lock in share model” 此时 id 是索引。
排他锁
- 满足格式：
select ... where 索引限制 for update 的语句
演示事务 tx 中的例子，文字解析见图。
撮合中的所有表锁替换成了共享锁，运行其它业务读取所锁的行数据，在当前事务的批量操作还没结束之前，不允许修改。
（编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
