读后写与更新丢失

前言

读后写是一个典型多变但又常见的场景.比如缓存更新.下单扣减库存.这个场景下如果稍不注意就会写出bug.而且bug并不是每次都出现.排查的时候如果没有这方面的经验,可能无从下手.

Java场景下的读后写

Code:

public class Counter {

    private static final Map<String, Integer> counter = Maps.newHashMap();

    public static void add(String key) throws InterruptedException {
       if (counter.containsKey(key)) {
           counter.put(key, counter.get(key) + 1);
       } else {
           Thread.sleep(1000);
           counter.put(key, 1);
       }
    }
}

这是一个简单的给key计数的功能:

1. 如果key存在就给value加1.
2. 如果key不存在就设置为1.

这个看似完美的功能在单线程的时候可以很好的工作.不会有什么问题.

但是一到并发环境.就会遇到线程安全问题.

1. 如果同时有两个线程进入了方法.
2. 这个key并没有在counter中.那都会走counter.put(key, 1)这个方法.

结果就是本来应该是2.但是记录进去的只有1.if里的逻辑同理.

我们可以测试一下上面的代码.

    public static void main(String[] args) throws InterruptedException {
        Runnable runnable = () ->{
            try {
                add("key");
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        };

        Thread t1 = new Thread(runnable);
        Thread t2 = new Thread(runnable);

        t1.start();
        t2.start();

        t1.join();
        t2.join();
        
        System.out.println(counter);
    }

代码很简单.两个线程,都去调用add方法.然后主线程等待处理完成.打印counter.

结果

{key=1}

按道理两个线程进去,应该是2.不过很遗憾,结果是1.这就是典型的读后写场景.读就是counter.containsKey(key)
写就是counter.put(key, 1) 和 counter.put(key, counter.get(key) + 1)

出现这个问题的原因实际上是因为我们的读和写并不是原子操作.原子操作是指jvm层面是一个指令(Instruction).那如何保证读和写的原子性.最常用的方法就是加锁.

实现代码如下：

    public static synchronized void add(String key) throws InterruptedException {
        if (counter.containsKey(key)) {
            counter.put(key, counter.get(key) + 1);
        } else {
            Thread.sleep(1000);
            counter.put(key, 1);
        }
    }

再看输出：

{key=2}

我们通过对方法加锁来达到保证整个操作是原子的.
当然如果这样add方法的性能会下降.但是却保证了安全与正确.

这个例子比较简单,以目前Java的普及程度.大家都会在写代码的时候考虑到代码中的线程安全.但是这个简单的模型在其他环境中,可能并不那么好识别.

总结：单机模式下,多线程读后写,存在并发更新丢失问题

分布式缓存更新场景下的读后写

这是一个缓存服务的更新流程.按照01~05.当写数据库之后发消息到MQ.MQ推到Cache的更新服务上.更新服务查数据.写入到缓存.

这个场景和上面的场景相比,更加丰富.如果经验不足,也不容易联想到上面那个场景.
先看下问题.04~05两步是典型的读后写.没有保证原子操作.

这会导致什么.

1. 如果DB连着更新了两次.消息被发送到两台机器或一台机器的两个处理线程.
2. 后一次更新中查出来的新数据先被写入了缓存.
3. 前一次更新的数据后被写入了缓存.

那实际上当前的Cache是有脏数据的.最后一次更新的数据丢了.这个问题发现的几率要取决于是否同key频繁写.频繁写的情况下是否会出现后更新的先被写进去.所以有时候问题时隐时现.不好排查.

解决方案中最简单的还是加锁.
只不过在分布式场景下需要加分布式锁.

这个坑我就踩过.查了好久.从db写入.到发消息.到写缓存.所有的日志都能串起来.就是数据不对.后来偶然想到了时序才想明白.

总结：多机的分布式场景下.读后写容易被忽略.需要重视

DB的读后写场景

下单扣减库存是一个典型的读后写场景.

1. 我们从数据库中读取数据:select * from product where id = 123;
2. 校验库存是否够用 if product.getInventory() > toOrder
3. 如果够用,我们就update product set product set inventory = inventory - #{toOrder} where id = 123;

熟悉的场景,熟悉的bug.

1. 如果有两个扣减请求过来.我们将数据从DB中读取出来后.
2. 在内存中扣减的情况,
3. 可能超卖.可能更新库存数据错误.

这时候.有的开发可能觉得.这好办.数据库我加个事务.不就解决了么.真的可以解决么?看情况.这要根据数据库的隔离级别来分析.

一般情况下,mysql的隔离级别都使用read commited. 你读取的时候如果另一个扣减事务没提交.你是无法感知的.所以加事务并不能解决问题.但是加事务.确实是正确解决路上的一个步骤.

延续我们上面的方案.我们想到的办法应该是加锁.那锁怎么加.
关于数据库的更新丢失问题.有两种解决方案.一种叫乐观锁.一种叫悲观锁.

乐观锁

乐观锁中,我们会引入一个类似版本号的概念.比如给每一行加入一个version.

1. 假定.我们查出的数据version为1
2. 那我们这么update：update product set version = version + 1 where version = 1
3. 如果更新成功.说明中间数据没有被修改.这次更新是成功的.如果失败.说明数据被修改过.我们需要重新读取数据.进行操作.

那在我们这个扣减库存的场景中.

• 我们可以不用引入版本号.而使用库存做版本号.
• 再进一步.我们实际上并不需要严格按照版本号来做.可以使用inventory - #{toOrder} > 0.我们只要判断,扣减之后是否库存大于0.业务上就可以满足需求.如果失败.就下单失败.

总结：乐观锁不是真的锁.而是使用一种机制来保证读后写的正确性.这种方式可能会大量重试.需要根据业务场景合理使用.

悲观锁

悲观锁,则类似于我们之前的处理办法.不过我们是使用Mysql的锁来实现.

Mysql的Innodb存储引擎支持行级锁.并且有两种,读共享锁和写独占锁.

读共享锁在这个场景下并没有用.所以直接看写独占锁.

写独占锁使用也很简单.只需要在select 的语句后加上for update即可.

那我们的查询sql就修改为

select * from product where id = 123 for update;

然后我们进行更新.提交事务就可以安全的完成这个工作了.

需要注意的是.整个操作要加事务.

总结：悲观锁是由数据库的锁来保证读后写的正确性

总结

读后写是一个很常见的模型.这个模型下可能有很多场景.需要我们提高识别能力.写出正确的代码.