做者:林冠宏 / 指尖下的幽灵html
博客:http://www.cnblogs.com/linguanh/github
GitHub : https://github.com/af913337456/数据库
腾讯云专栏: https://cloud.tencent.com/developer/user/1148436/activities并发
虫洞区块链专栏:https://www.chongdongshequ.com/article/1536563643883.html高并发
距离上次择文发表,两月余久。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 中的例子,文字解析见图。
撮合中的全部表锁
替换成了共享锁
,运行其它业务读取所锁的行数据,在当前事务的批量操做还没结束以前,不容许修改。