MySQL中SELECT+UPDATE处理并发更新问题解决方案分享

问题背景：

假设MySQL数据库有一张会员表vip_member（InnoDB表），结构以下：

当一个会员想续买会员（只能续买1个月、3个月或6个月）时，必须知足如下业务要求：

•若是end_at早于当前时间，则设置start_at为当前时间，end_at为当前时间加上续买的月数

•若是end_at等于或晚于当前时间，则设置end_at=end_at+续买的月数

•续买后active_status必须为1（即被激活）

问题分析：

对于上面这种状况，咱们通常会先SELECT查出这条记录，而后根据查出记录的end_at再UPDATE start_at和end_at，伪代码以下（为uid是1001的会员续1个月）：

代码以下:

vipMember = SELECT * FROM vip_member WHERE uid=1001 LIMIT 1 # 查uid为1001的会员
if vipMember.end_at < NOW():
  
 UPDATE vip_member SET start_at=NOW(), end_at=DATE_ADD(NOW(), INTERVAL 1
 MONTH), active_status=1, updated_at=NOW() WHERE uid=1001
else:
   UPDATE vip_member SET end_at=DATE_ADD(end_at, INTERVAL 1 MONTH), active_status=1, updated_at=NOW() WHERE uid=1001

假如同时有两个线程执行上面的代码，很显然存在“数据覆盖”问题（即一个是续1个月，一个续2个月，但最终可能只续了2个月，而不是加起来的3个月）。

解决方案：

A、我想到的第一种方案是把SELECT和UPDATE合成一条SQL，以下：

代码以下:

UPDATE vip_member 
SET 
   start_at = CASE
              WHEN end_at < NOW() 
                 THEN NOW()
              ELSE start_at
              END,
   end_at = CASE
            WHEN end_at < NOW()
               THEN DATE_ADD(NOW(), INTERVAL #duration:INTEGER# MONTH)
            ELSE DATE_ADD(end_at, INTERVAL #duration:INTEGER# MONTH)
            END,
   active_status=1,
   updated_at=NOW()
WHERE uid=#uid:BIGINT#
LIMIT 1;

    So easy！

B、第二种方案：事务，即用一个事务来包裹上面的SELECT+UPDATE操做。

    那么是否包上事务就万事大吉了呢？

    显然不是。由于若是同时有两个事务都分别SELECT到相同的vip_member记录，那么同样的会发生数据覆盖问题。那有什么办法能够解决呢？难道要设置事务隔离级别为SERIALIZABLE，考虑到性能不现实。

    咱们知道InnoDB支持行锁。查看MySQL官方文档（innodb locking reads）了解到InnoDB在读取行数据时能够加两种锁：读共享锁和写独占锁。

    读共享锁是经过下面这样的SQL得到的：

代码以下:

SELECT * FROM parent WHERE NAME = 'Jones' LOCK IN SHARE MODE;

    若是事务A得到了先得到了读共享锁，那么事务B以后仍然能够读取加了读共享锁的行数据，但必须等事务A commit或者roll back以后才能够更新或者删除加了读共享锁的行数据。代码以下:

SELECT counter_field FROM child_codes FOR UPDATE;
UPDATE child_codes SET counter_field = counter_field + 1;

   若是事务A先得到了某行的写共享锁，那么事务B就必须等待事务A commit或者roll back以后才能够访问行数据。

   显然要解决会员状态更新问题，不能加读共享锁，只能加写共享锁，即将前面的SQL改写成以下：

 代码以下:

vipMember = SELECT * FROM vip_member WHERE uid=1001 LIMIT 1 FOR UPDATE # 查uid为1001的会员
if vipMember.end_at < NOW():
  
 UPDATE vip_member SET start_at=NOW(), end_at=DATE_ADD(NOW(), INTERVAL 1
 MONTH), active_status=1, updated_at=NOW() WHERE uid=1001
else:
   UPDATE vip_member SET end_at=DATE_ADD(end_at, INTERVAL 1 MONTH), active_status=1, updated_at=NOW() WHERE uid=1001

    另外这里特别提醒下：UPDATE/DELETE SQL尽可能带上WHERE条件并在WHERE条件中设定索引过滤条件，不然会锁表，性能可想而知有多差了。

C、第三种方案：乐观锁，类CAS机制

    第二种加锁方案是一种悲观锁机制。并且SELECT...FOR UPDATE方式也不太经常使用，联想到CAS实现的乐观锁机制，因而我想到了第三种解决方案：乐观锁。

    具体来讲也挺简单，首先SELECT SQL不做任何修改，而后在UPDATE SQL的WHERE条件中加上SELECT出来的vip_memer的end_at条件。以下：

代码以下:

vipMember = SELECT * FROM vip_member WHERE uid=1001 LIMIT 1 # 查uid为1001的会员
cur_end_at = vipMember.end_at
if vipMember.end_at < NOW():
  
 UPDATE vip_member SET start_at=NOW(), end_at=DATE_ADD(NOW(), INTERVAL 1
 MONTH), active_status=1, updated_at=NOW() WHERE uid=1001 AND 
end_at=cur_end_at
else:
   UPDATE vip_member SET 
end_at=DATE_ADD(end_at, INTERVAL 1 MONTH), active_status=1, 
updated_at=NOW() WHERE uid=1001 AND end_at=cur_end_at

    这样能够根据UPDATE返回值来判断是否更新成功，若是返回值是0则代表存在并发更新，那么只须要重试一下就行了。

方案比较：

三种方案各自优劣也许众说纷纭，只说说我本身的见解：

•第一种方案利用一条比较复杂的SQL解决问题，不利于维护，由于把具体业务糅在SQL里了，之后修改业务时不但须要读懂这条SQL，还颇有可能会修改为更复杂的SQL

•第二种方案写独占锁，能够解决问题，但不经常使用

•第三种方案应该是比较中庸的解决方案，而且甚至能够不加事务，也是我我的推荐的方案

此外，乐观锁和悲观锁的选择通常是这样的（参考了文末第二篇资料）：

•若是对读的响应度要求很是高，好比证券交易系统，那么适合用乐观锁，由于悲观锁会阻塞读

•若是读远多于写，那么也适合用乐观锁，由于用悲观锁会致使大量读被少许的写阻塞

•若是写操做频繁而且冲突比例很高，那么适合用悲观写独占锁