mysql乐观锁与悲观锁

mysql中保证数据更新安全的方法？

java代码中的锁，需要确保更新仅有一个入口，限制性太强。
悲观锁，事务中select .. for update;然后执行update。
乐观锁，通过时间戳、自增版本号等，select version ...; update version...where version =;注意此时的事物隔离级别必须是读已提交，此时才能读到最新的版本。

乐观锁在可重复读级别与读已提交级别区别？

乐观锁分为select number where productId 和 update number = number-1 where productId  and number两条sql
读已提交：执行update number = number-1 where productId  and number
可重复读：执行：update number = number-1 where productId  and number
流程上本质是相同的，但是如果执行流程上有多次select number where productId就会不同，
读已提交下，最终读到的number总是最新的，所以update成功的几率更大。
可重复读下，最终的number可能因为mvcc的原因，number可能不是最新的数据，导致update成功几率更小。
综上：乐观锁在两种隔离级别下均可使用，但是在读已提交下效率更高。所以推荐在读已提交下使用乐观锁

悲观锁中select for update的理解

锁的范围：where是否走索引：不走索引锁整表，走了锁特定行+间隙锁（可重复读下才有该锁）
读已提交：可读 insert可以 select for update互斥
可重复读：可读 insert不可以 select for update互斥

乐观与悲观锁的适用场景

乐观锁：乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。因为冲突多的话，会需要大量的重试。
悲观锁：适合于写多的场景，即发生冲突的概率比较高的场景，此时可以避免悲观锁的大量重试。

为什么java中的悲观锁syn适用于冲突低的场景，乐观锁reenTrantLock适用于冲突高的场景？而在mysql中不同？

本质原因是重试的机制不同，java中重试仅仅从内存中重新获取最新值即可，而且reentranLock中使用了队列等保存等待锁的队列，无论多少都是挨个处理。所以重试的成本低。
但是mysql的重试需要重新从mysql中select和update，需要读磁盘网络传输等，失败后的重试成本异常的高。

mvcc再理解

a=1
事物1 开始 
事物2 开始，修改a=2, commit
事物1 读a，a为多少？
此时a为2，因为在此之前a没有读过，所以没有做版本号的控制。

悲观锁

悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。

Java synchronized 就属于悲观锁的一种实现，每次线程要修改数据时都先获得锁，保证同一时刻只有一个线程能操作数据，其他线程则会被block。

乐观锁

乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在提交更新的时候会判断一下在此期间别人有没有去更新这个数据。乐观锁适用于读多写少的应用场景，这样可以提高吞吐量。

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。

乐观锁一般来说有以下2种方式：

1. 使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。
2. 使用时间戳（timestamp）。乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）, 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

Java JUC中的atomic包就是乐观锁的一种实现，AtomicInteger 通过CAS（Compare And Set）操作实现线程安全的自增。

MySQL隐式和显示锁定

MySQL InnoDB采用的是两阶段锁定协议（two-phase locking protocol）。在事务执行过程中，随时都可以执行锁定，锁只有在执行 COMMIT或者ROLLBACK的时候才会释放，并且所有的锁是在同一时刻被释放。前面描述的锁定都是隐式锁定，InnoDB会根据事务隔离级别在需要的时候自动加锁。

另外，InnoDB也支持通过特定的语句进行显示锁定，这些语句不属于SQL规范：

• SELECT ... LOCK IN SHARE MODE
• SELECT ... FOR UPDATE

实战

接下来，我们通过一个具体案例来进行分析：考虑电商系统中的下单流程，商品的库存量是固定的，如何保证商品数量不超卖？ 其实需要保证数据一致性：某个人点击秒杀后系统中查出来的库存量和实际扣减库存时库存量的一致性就可以。

假设，MySQL数据库中商品库存表tb_product_stock 结构定义如下：

CREATE TABLE `tb_product_stock` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '自增ID',
  `product_id` bigint(32) NOT NULL COMMENT '商品ID',
  `number` INT(8) NOT NULL DEFAULT 0 COMMENT '库存数量',
  `create_time` DATETIME NOT NULL COMMENT '创建时间',
  `modify_time` DATETIME NOT NULL COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `index_pid` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='商品库存表';

对应的POJO类：

class ProductStock {
    private Long productId; //商品id
    private Integer number; //库存量

    public Long getProductId() {
        return productId;
    }

    public void setProductId(Long productId) {
        this.productId = productId;
    }

    public Integer getNumber() {
        return number;
    }

    public void setNumber(Integer number) {
        this.number = number;
    }
}

不考虑并发的情况下，更新库存代码如下：

    /**
     * 更新库存(不考虑并发)
     * @param productId
     * @return
     */
    public boolean updateStockRaw(Long productId){
        ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId}", productId);
        if (product.getNumber() > 0) {
            int updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId}", productId);
            if(updateCnt > 0){    //更新库存成功
                return true;
            }
        }
        return false;
    }

多线程并发情况下，会存在超卖的可能。

悲观锁

/**
     * 更新库存(使用悲观锁)
     * @param productId
     * @return
     */
    public boolean updateStock(Long productId){
        //先锁定商品库存记录
        ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId} FOR UPDATE", productId);
        if (product.getNumber() > 0) {
            int updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId}", productId);
            if(updateCnt > 0){    //更新库存成功
                return true;
            }
        }
        return false;
    }

乐观锁

    /**
     * 下单减库存
     * @param productId
     * @return
     */
    public boolean updateStock(Long productId){
        int updateCnt = 0;
        while (updateCnt == 0) {
            ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId}", productId);
            if (product.getNumber() > 0) {
                updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId} AND number=#{number}", productId, product.getNumber());
                if(updateCnt > 0){    //更新库存成功
                    return true;
                }
            } else {    //卖完啦
                return false;
            }
        }
        return false;
    }

使用乐观锁更新库存的时候不加锁，当提交更新时需要判断数据是否已经被修改（AND number=#{number}），只有在 number等于上一次查询到的number时 才提交更新。

** 注意** ：UPDATE 语句的WHERE 条件字句上需要建索引

乐观锁与悲观锁的区别

乐观锁的思路一般是表中增加版本字段，更新时where语句中增加版本的判断，算是一种CAS（Compare And Swep）操作，商品库存场景中number起到了版本控制（相当于version）的作用（ AND number=#{number}）。

悲观锁之所以是悲观，在于他认为本次操作会发生并发冲突，所以一开始就对商品加上锁（SELECT ... FOR UPDATE），然后就可以安心的做判断和更新，因为这时候不会有别人更新这条商品库存。

小结

这里我们通过 MySQL 乐观锁与悲观锁 解决并发更新库存的问题，当然还有其它解决方案，例如使用 分布式锁。目前常见分布式锁实现有两种：基于Redis和基于Zookeeper，基于这两种 业界也有开源的解决方案，例如 Redisson Distributed locks 、 Apache Curator Shared Lock ，这里就不细说，网上Google 一下就有很多资料。

参考链接：https://www.jianshu.com/p/f5ff017db62a