前序

距离上次择文发表，两月余久。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元售价的手机。