《Mysql实例MySQL中SELECT+UPDATE处理并发更新问题解决方案分享》要点:
本文介绍了Mysql实例MySQL中SELECT+UPDATE处理并发更新问题解决方案分享,希望对您有用。如果有疑问,可以联系我们。
MYSQL应用问题背景:
MYSQL应用假设MySQL数据库有一张会员表vip_member(InnoDB表),结构如下:
MYSQL应用当一个会员想续买会员(只能续买1个月、3个月或6个月)时,必须满足以下业务要求:
MYSQL应用•如果end_at早于当前时间,则设置start_at为当前时间,end_at为当前时间加上续买的月数
MYSQL应用•如果end_at等于或晚于当前时间,则设置end_at=end_at+续买的月数
MYSQL应用•续买后active_status必须为1(即被激活)
MYSQL应用问题分析:
MYSQL应用对于上面这种情况,我们一般会先SELECT查出这条记录,然后根据查出记录的end_at再UPDATE start_at和end_at,伪代码如下(为uid是1001的会员续1个月):
MYSQL应用假如同时有两个线程执行上面的代码,很显然存在“数据覆盖”问题(即一个是续1个月,一个续2个月,但最终可能只续了2个月,而不是加起来的3个月).
MYSQL应用解决方案:
MYSQL应用A、我想到的第一种方案是把SELECT和UPDATE合成一条SQL,如下:
MYSQL应用 So easy!
MYSQL应用B、第二种方案:事务,即用一个事务来包裹上面的SELECT+UPDATE操作.
MYSQL应用 那么是否包上事务就万事大吉了呢?
MYSQL应用 显然不是.因为如果同时有两个事务都分别SELECT到相同的vip_member记录,那么一样的会发生数据覆盖问题.那有什么办法可以解决呢?难道要设置事务隔离级别为SERIALIZABLE,考虑到性能不现实.
MYSQL应用 我们知道InnoDB支持行锁.查看MySQL官方文档(innodb locking reads)了解到InnoDB在读取行数据时可以加两种锁:读共享锁和写独占锁.
MYSQL应用 读共享锁是通过下面这样的SQL获得的:
MYSQL应用 如果事务A获得了先获得了读共享锁,那么事务B之后仍然可以读取加了读共享锁的行数据,但必须等事务A commit或者roll back之后才可以更新或者删除加了读共享锁的行数据.
MYSQL应用 如果事务A先获得了某行的写共享锁,那么事务B就必须等待事务A commit或者roll back之后才可以访问行数据.
MYSQL应用 显然要解决会员状态更新问题,不能加读共享锁,只能加写共享锁,即将前面的SQL改写成如下:
MYSQL应用 另外这里特别提醒下:UPDATE/DELETE SQL尽量带上WHERE条件并在WHERE条件中设定索引过滤条件,否则会锁表,性能可想而知有多差了.
MYSQL应用C、第三种方案:乐观锁,类CAS机制
MYSQL应用 第二种加锁方案是一种悲观锁机制.而且SELECT...FOR UPDATE方式也不太常用,联想到CAS实现的乐观锁机制,于是我想到了第三种解决方案:乐观锁.
MYSQL应用 具体来说也挺简单,首先SELECT SQL不作任何修改,然后在UPDATE SQL的WHERE条件中加上SELECT出来的vip_memer的end_at条件.如下:
MYSQL应用 这样可以根据UPDATE返回值来判断是否更新成功,如果返回值是0则表明存在并发更新,那么只需要重试一下就好了.
MYSQL应用方案比较:
MYSQL应用三种方案各自优劣也许众说纷纭,只说说我自己的看法:
MYSQL应用•第一种方案利用一条比较复杂的SQL解决问题,不利于维护,因为把具体业务糅在SQL里了,以后修改业务时不但需要读懂这条SQL,还很有可能会修改成更复杂的SQL
MYSQL应用•第二种方案写独占锁,可以解决问题,但不常用
MYSQL应用•第三种方案应该是比较中庸的解决方案,并且甚至可以不加事务,也是我个人推荐的方案
MYSQL应用
此外,乐观锁和悲观锁的选择一般是这样的(参考了文末第二篇资料):
MYSQL应用•如果对读的响应度要求非常高,比如证券交易系统,那么适合用乐观锁,因为悲观锁会阻塞读
MYSQL应用•如果读远多于写,那么也适合用乐观锁,因为用悲观锁会导致大量读被少量的写阻塞
MYSQL应用•如果写操作频繁并且冲突比例很高,那么适合用悲观写独占锁
转载请注明本页网址:
http://www.vephp.com/jiaocheng/3588.html