最近在公司的开发任务中接到一个优化的任务，主要是将一个查询次数比较多，但是数据量不大的一个表的查询由DB查询改为走缓存查询，当领导将这个任务交给我时，瞬间就想到了redis，然后就联想到了缓存击穿、缓存穿透、缓存雪崩的一系列问题。然后自认为可以提交一份满意的答卷，一个晚上就写了一个使用redis缓存的方案，里面包含了解决缓存常见问题的思路。
第二天一早，就拿着方案找上老板，然后巴拉巴拉说了一堆，然后老板说，你这个怎么解决缓存穿透等问题的，然后我就拿着从网上找的一堆关于三个问题的解决方案，什么分布式锁、热点数据永不过期、过期时间随机、布隆过滤器.... 然后说了一堆，老板直接来了句：我现在想要，一百个请求进来，只有一个请求去查数据库，然后其他请求原地等待，然后这个请求拿到数据后，设置缓存，其他99个请求就直接走缓存，然后我看你方案里说使用分布式锁，即使是使用double check的方式，还是会难以避免其他请求去竞争这个分布式锁的资源。
伪代码如下：
get(code) {
// 走缓存
if (redis.get(code) != null) {
return redis.get(code);
} else {
// 缓存没有 加锁走数据库
Lock lock = redis.createLock(code);
lock.lock;
try {
// double check 走缓存
if (redis.get(code) != null) {
return redis.get(code);
} else {
// 查询数据库 设置缓存
result = db.find(code);
redis.set(result, time);
return result;
}
} catch (Eeception e) {
...
} finally {
lock.unlock();
}
}
}
当时就很气，心想着你这不是为难我胖虎吗，
然后我又拿着方案回去改。想着，不就是让其他请求不去竞争分布式锁资源吗？然后我就想着，直接使用分布式锁的tryLock，抢到锁资源的去查db，抢不到就sleep一段时间，回调get方法不久行了吗，然后又一版方案出来了。
伪代码如下：
get(code) {
// 走缓存
if (redis.get(code) != null) {
return redis.get(code);
} else {
// 缓存没有 加锁走数据库
Lock lock = redis.createLock(code);
// 竞争锁资源
if (lock.tryLock()) {
try {
// 查询数据库 设置缓存
result = db.find(code);
redis.set(result, time);
return result; } finally {
redis.unlock();
}
} else {
Thread.sleep(500);
get(code);
}
}
}
心想着，这样子不就ok了吗，
方案一出，我就去找老板交差了，然后老板看了一下，说：你这个方案是可以用，但是睡眠也不好，如果并发特别高，线程池一下子就会被打满.... ，然后被他喷了一脸口水之后，他又说，这种情况可以考虑一下本地缓存，这张表的数据量并不是很大，但是用到的地方非常多，查询次数非常多（配置表），放redis不太好。然后我脱口而出，那不是线上每一台机器都会有自己的一个本地缓存。然后老板又说，是的，因为本来量就不大，每一台机器都有一个本地缓存，开销也不大。并且你要使用本地缓存之后，也要完成这种，只有一个请求打到数据库，其他的等数据库查出来走缓存的效果，不能去竞争锁资源....
带着老板的要求，一脸蒙蔽的回到自己的工位，想了半天，没有一点思路，想用Synchronized锁，但是同时还是避免不了争夺锁资源的情况。
可能，老板看出了我的一脸茫然，然后他就跟我说，可以去看一看AQS的几种同步工具，作为校招生的我，当时又是一脸茫然，偷偷回去恶补知识，好像老板还特意提了一句读写锁，当时我就恨不得为老板出生入死，连特么做梦都在加班。
然后回去又疯狂研究AQS的几种同步工具，尤其是读写锁，一看读写锁的特性，读写锁实际是一种特殊的自旋锁，它把对共享资源的访问者划分成读者和写者，读者只对共享资源进行读访问，写者则需要对共享资源进行写操作。这样一想，卧槽，感觉发现了新大陆，这不就完美解决了一个请求去请求数据库，其他被堵塞在原地了吗。
但是写出demo之后发现，emmm，所有的读锁被阻塞之后还是会去竞争写锁的资源，并且，读锁还无法针对更细粒度的对象加锁，直接把不同的code也给阻塞了，当时我就感觉整个人就不好了。
本地缓存加读写锁伪代码：
public void readWriteMathod(String key){
readWriteLock.readLock().lock();//读锁，只对写的线程互斥
Object value = null;
try {
// 尝试从本地缓存中获取数据
value = map.get(key);
if (value != null) {
System.out.println(Thread.currentThread().getName() + "拿到了值，值为" + value);
return;
}
if (value == null) {
readWriteLock.readLock().unlock();
//发现目标值为null,释放掉读锁
readWriteLock.writeLock().lock();
//发现目标值为null,需要取值操作,上写锁
try {
value = map.get(key);
// 很严谨这一步。再次取目标值
if (value == null) { //很严谨这一步。再次判断目标值,防止写锁释放后，后面获得写锁的线程再次进行取值操作
// 模拟DB操作
result = db.find(code);
// 本地缓存 map.put(key, value);
System.out.println(Thread.currentThread().getName() + "设置了值，值为" + value);
}
readWriteLock.readLock().lock();//再次对读进行锁住，以防止写的操作，造成数据错乱
} finally {
/** 先加读锁再释放写锁读作用：
* 防止在100行出多个线程获得写锁进行写的操作，所以在写锁还没有释放前要上读锁
*/
readWriteLock.writeLock().unlock();
}
}
} finally {
readWriteLock.readLock().unlock();
}
}
然后在心累的同时，又发现了一个更有意思的东西，ReentrantLock的Condition，简介：
condition可以通俗的理解为条件队列。当一个线程在调用了await方法以后，直到线程等待的某个条件为真的时候才会被唤醒。这种方式为线程提供了更加简单的等待/通知模式。Condition必须要配合锁一起使用，因为对共享状态变量的访问发生在多线程环境下。一个Condition的实例必须与一个Lock绑定，因此Condition一般都是作为Lock的内部实现。
顿时灵感一来，又一个demo出现。
condition伪代码：
private static Lock lock = new ReentrantLock();
private static Condition cacheCondition = lock.newCondition();
get(code) {
// 从缓存中查
if (map.get(code) != null) {
return map.get(code);
} else {
//缓存中没有
if (lock.tryLock()) {
try {
value = db.find(code);
map.put(code, value);
if (condition != null) {
condition.signalAll();
}
return value;
} finally {
lock.unlock();
}
} else {
try {
lock.lock();
if (map.get(key) == null)
{
condition.await();
get(code);
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
}
}
}
demo写完之后，仔细去回看代码，发现这个方案解决了由一个请求去查db，其他的等待这个请求查到数据后唤醒它们，乍一看，非常符合我老板的要求，但是，没一会我又发现了，这个锁的粒度同样很大，直接将所有的请求都给阻塞了。这个方案又out了。
正当我焦头烂额的时候，另一个大佬问我有什么问题吗，然后我就给他说了一遍老板的需求和目前的一个情况。然后他给我说，你可以去研究一下ConcurrentHashMap的putIfAbsent方法，顺便给我写了个小demo。
伪代码：
void get(code) {
if (map.get(code) != null) {
return map.get(code);
}
Future f = futureMap.get(code);
if (f == null) {
MyFuture myFuture = new MyFuture(code);
FutureTask curTask = new FutureTask<>(myFuture);
// 如果已存在，返回已存在的，如果不存在，返回null，并且将当前的值插入到map FutureTask pre = map.putIfAbsent(code, curTask); if (pre == null) {
// 执行当前任务，查数据库
new Thread(curTask).start();
value = curTask.get();
// 设置缓存
map.set(code, value);
// 移除当前任务
futureMap.remove(code);
return value;
} else {
// 返回已插入任务的返回值，最多等500ms，无值抛出超时异常，有则返回
return pre.get(500, TimeUnit.MILLISECONDS);
}
}
// 获取f任务的返回值,最多等500ms
return f.get(500, TimeUnit.MILLISECONDS);
}
MyFutureTask implements Callable<String> {
// 构造方法
MyFuture(code) {
code = code;
}
@Override
public String call() throws Exception {
value = db.find(code);
return value;
}
}
完美利用ConcurrentHashMap的putIfAbsent的特性，同时只允许一个线程进行插入操作，并且第一次插入返回null，后面插入返回第一次插入的值。源码如下
具体的源码我这个小菜鸟就不解释了，大佬跟我说，他的上一家电商公司，用这种方案，经过了8000QPS的考验，对我现在这个场景的缓存来说（接近400QPS），完全足够了，然后，我就只能在大佬的帮助下，交出了这一次的方案。终究还是一只小菜鸟。在网上找到的巨多的方案，都只是非常普通的加分布式锁..... 心累，在这把这个方案分享一下，在分享一下踩过的坑。
不过虽然，花了将近4天研究这些东西，但是对我一个刚从大学毕业的小菜鸟来说，收获真的蛮大的。在附上一句，打工人，打工魂，打工都是人上人！
