本文共 2089 字,大约阅读时间需要 6 分钟。
作者:林冠宏 / 指尖下的幽灵
掘金:
博客:
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
代码,所使用了表锁
的方式来解决前面的并发读写导致数据脏乱的问题。这种方式虽然是解决了问题,但是导致了性能低下
的问题。
数据库引擎
MyISAM
和InnoDB
MyISAM
不支持事务操作,InnoDB
支持事务操作行锁
和 表锁
共享锁
和排他锁
共享锁
简称 S锁,排他锁
简称 X锁简述:
行锁,锁的是表中对应的行,只限制当前行的读写。
表锁,锁的是整张表,限制的是整张表的数据读写。
比较:
死锁
;锁定粒度最小,锁冲突的概率最低,并发度
最高,性能高。死锁
;锁定粒度大,锁冲突的概率最高,并发度
最低,性能低。共享锁
A 对数据 B 加了 共享锁,A能读取和修改数据B,C 等其它只
能读取
数据B,但是不能修改
。直至A释放了B的锁。
排他锁
A 对数据 B 加了 排他锁,A能读取和修改数据B,C 等其它不能再对数据B加其它的锁。直观体验是不能修改,不能使用含有加锁动作的
select
读取。
要注意的是:
where id=xxx
这类语句。表锁
InnoDB引擎
默认的修改数据
类SQL语句,update
,delete
,insert
等,都会自动给涉及到的数据加上排他锁。共享锁
select ... where 索引限制 lock in share mode
的语句。例如“select name from lgh_user where id = 1 lock in share model” 此时 id 是索引。排他锁
select ... where 索引限制 for update
的语句非事务(Transaction) 中,语句执行完毕,便释放锁。
行锁在事务 (Transaction) 中,只有等到当前的事务Transaction 进行了 commit 或 roll back,锁才能释放。
演示事务 tx 中的例子,文字解析见图。
撮合中的所有表锁
替换成了共享锁
,运行其它业务读取所锁的行数据,在当前事务的批量操作还没结束之前,不允许修改。
转载地址:http://jusoa.baihongyu.com/