读后写与更新丢失
前言
读后写是一个典型多变但又常见的场景.比如缓存更新.下单扣减库存.这个场景下如果稍不注意就会写出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计数的功能:
- 如果key存在就给value加1.
- 如果key不存在就设置为1.
这个看似完美的功能在单线程的时候可以很好的工作.不会有什么问题.
但是一到并发环境.就会遇到线程安全问题.
- 如果同时有两个线程进入了方法.
- 这个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两步是典型的读后写.没有保证原子操作.
这会导致什么.
- 如果DB连着更新了两次.消息被发送到两台机器或一台机器的两个处理线程.
- 后一次更新中查出来的新数据先被写入了缓存.
- 前一次更新的数据后被写入了缓存.
那实际上当前的Cache是有脏数据的.最后一次更新的数据丢了.这个问题发现的几率要取决于是否同key频繁写.频繁写的情况下是否会出现后更新的先被写进去.所以有时候问题时隐时现.不好排查.
解决方案中最简单的还是加锁.
只不过在分布式场景下需要加分布式锁.
这个坑我就踩过.查了好久.从db写入.到发消息.到写缓存.所有的日志都能串起来.就是数据不对.后来偶然想到了时序才想明白.
总结：多机的分布式场景下.读后写容易被忽略.需要重视
DB的读后写场景
下单扣减库存是一个典型的读后写场景.
- 我们从数据库中读取数据:select * from product where id = 123;
- 校验库存是否够用 if product.getInventory() > toOrder
- 如果够用,我们就update product set product set inventory = inventory - #{toOrder} where id = 123;
熟悉的场景,熟悉的bug.
- 如果有两个扣减请求过来.我们将数据从DB中读取出来后.
- 在内存中扣减的情况,
- 可能超卖.可能更新库存数据错误.
这时候.有的开发可能觉得.这好办.数据库我加个事务.不就解决了么.真的可以解决么?看情况.这要根据数据库的隔离级别来分析.
一般情况下,mysql的隔离级别都使用read commited. 你读取的时候如果另一个扣减事务没提交.你是无法感知的.所以加事务并不能解决问题.但是加事务.确实是正确解决路上的一个步骤.
延续我们上面的方案.我们想到的办法应该是加锁.那锁怎么加.
关于数据库的更新丢失问题.有两种解决方案.一种叫乐观锁.一种叫悲观锁.
乐观锁
乐观锁中,我们会引入一个类似版本号的概念.比如给每一行加入一个version.
- 假定.我们查出的数据version为1
- 那我们这么update：update product set version = version + 1 where version = 1
- 如果更新成功.说明中间数据没有被修改.这次更新是成功的.如果失败.说明数据被修改过.我们需要重新读取数据.进行操作.
那在我们这个扣减库存的场景中.
- 我们可以不用引入版本号.而使用库存做版本号.
- 再进一步.我们实际上并不需要严格按照版本号来做.可以使用inventory - #{toOrder} > 0.我们只要判断,扣减之后是否库存大于0.业务上就可以满足需求.如果失败.就下单失败.
总结：乐观锁不是真的锁.而是使用一种机制来保证读后写的正确性.这种方式可能会大量重试.需要根据业务场景合理使用.
悲观锁
悲观锁,则类似于我们之前的处理办法.不过我们是使用Mysql的锁来实现.
Mysql的Innodb存储引擎支持行级锁.并且有两种,读共享锁和写独占锁.
读共享锁在这个场景下并没有用.所以直接看写独占锁.
写独占锁使用也很简单.只需要在select 的语句后加上for update即可.
那我们的查询sql就修改为
select * from product where id = 123 for update;
然后我们进行更新.提交事务就可以安全的完成这个工作了.
需要注意的是.整个操作要加事务.
总结：悲观锁是由数据库的锁来保证读后写的正确性
总结
读后写是一个很常见的模型.这个模型下可能有很多场景.需要我们提高识别能力.写出正确的代码.
