1 使用场景
什么情况下适合使用缓存？
短时间内相同数据被重复查询且更新频率不高，这种情况可以考虑使用缓存。应用先查询缓存，如果查询不到数据，则从数据库加载该数据并保存到缓存；
高并发热点数据，完全透传到数据库会造成数据库宕机，必须使用缓存；
什么情况下不建议使用缓存？
配置型数据在不频繁读的情况下（数据库url等），可以不使用缓存。这类数据建议使用配置中心的方式主动推送；
实时性要求较高的数据，不建议使用缓存。比如用户密码，一般只用来做登录校验，不会频繁读取，缓存该数据并不能大幅提升系统性能，还可能导致用户密码修改后不能及时生效从而影响用户体验（缓存更新失败的情况）；
2 缓存选型
开发中常用的缓存有本地缓存和分布式缓存。可以用HashMap自己实现一个简单的本地缓存，也可以用Guava cache或者ehcache来实现。对于分布式缓存，业界常用的有redis、memcached、还有阿里的tair等。
什么情况适合本地缓存？
频繁被访问的大对象。分布式缓存需要跨进程访问数据，缓存服务器需要先序列化该对象，通过网络传输到应用服务器，然后应用服务器再反序列化，而序列化与反序列化的过程是非常消耗CPU的操作。
数据量小的单机应用；
什么情况适合分布式缓存？
大数据量的缓存，数据频繁的增长又清空（本地缓存会导致频繁的垃圾回收）；
分布式应用，多个应用实例访问同一份缓存数据；
3 数据数据更新
因为缓存和数据库是两个独立的组件，两者无法在同一个本地事务内完成更新，所以在写的时候有可能会出现数据不一致的情况。不考虑分布式事务的前提下，有下面几种更新策略：
先删除缓存，再更新数据库
case1：低并发场景下，先删除缓存，更新数据库后，后续读操作会从数据库读取数据并更新缓存，仅会造成一次缓存未命中；
case2：高并发场景下，写线程T1先删除缓存数据，读线程T2未命中缓存，从数据库读取数据并加载到缓存，然后线程T1更新数据库数据。这时缓存中的值就是原来的老数据，后续读操作都属于脏读。
先更新数据库，再删除缓存
case3：先更新数据库，再删除缓存，在删除缓存失败的情况下，也会出现脏数据；
case4：缓存数据失效的瞬间，读线程T1未命中缓存，然后到数据库取数据，取完数据后来了个写线程T2，T2先往数据库写数据，然后删除缓存，接着T1再把读到的老数据加载到缓存，此时也会造成脏读。这个情况出现的概率非常低，需要缓存失效的瞬间有并发的读写操作。而且数据库的写会比读慢很多，并且需要对数据加锁，所以T1必须在T2之前进入数据库进行操作，又要晚于T2更新缓存，所有这些条件都具备的概率非常低。
先更新数据库，再更新缓存
case5：假设两个写线程T1、T2并发更新某一数据，T1先获取锁、更新数据库并且释放锁，T2获取锁、更新数据库然后释放锁；接下来T2更新缓存值，T1更新缓存值，这时候缓存中的数据T1为脏数据。
不考虑缓存和数据库操作失败的情况，case4产生脏数据的概率最小。再接合缓存数据的自动过期，该方案适合成为缓存更新的通用策略。
4 缓存击穿
缓存击穿可以分为以下几种情况：
查询数据库中不存在的值，每次都会访问数据库，如果有人恶意攻击则会对数据库造成很大压力。
解决方案：
对于数据库中不存在的key-value查询，在缓存中为该key设置一个默认value。该value需要具有明显特征，不能干扰正常业务（比如”NULL”）；
使用布隆过滤器，大部分在数据库中不存在的查询请求会被该过滤器直接过滤，不会透传到数据库层。
数据缓存时间到期，失效瞬间多个线程/进程查询数据，则每个请求都会执行查询数据库，然后设置缓存的动作。如果该查询是热点key查询，数据库压力会瞬间增大。
解决方案：
请求查询数据库前先获取分布式互斥锁，取得锁的进程A查询数据库并设置缓存中的值，其余线程等待线程A执行完毕后从缓存中读取值。
public String getValue(String key) {
String retValue = getValueFromCache(key);
if(null != retValue) {
return retValue;
}
lock = getMutexLock(key);
try {
retValue = getValueFromCache(key);
if(null == retValue) {
retValue = getValueFromDB(key);
setCache(key, retValue);
}
}
finally {
unlock(key);
}
return retValue;
}
如果使用本地缓存，可以用guava代替上述功能，guava默认支持多线程的并发访问。
Cache<Key, Object> cache = CacheBuilder.newBuilder().maximumSize(1000).build();
try {
cache.get(key, new Callable<Key, Object>() {
@Override
public Object call() throws AnyException {
return getFromDB(key);
}
});
} catch (ExecutionException e) {
throw new OtherException(e.getCause());
}
5 热点key
业务高峰期，大量请求访问同一份数据，hash算法使得相同key的所有流量涌向同一台机器，这台机器成为系统瓶颈，该问题的挑战在于它无法通过增加机器容量来解决。
解决热点问题最有效的方法是从业务角度将热点拆分，对于某些不能拆分的业务，可以采取多份数据的形式分担负载。这类方案通过牺牲数据一致性来提高效率。
客户端本地缓存
热点数据缓存在客户端本地，并设置一个较短的过期时间，每次读请求先检查本地缓存。本地缓存中有数据则直接返回；如果不能命中本地缓存，再去访问分布式缓存服务器。该方案的缺点是分布式缓存数据更改后不能及时刷新本地缓存，造成数据脏读，如果业务可以容忍短时间内数据不准确，可以使用本方案。
数据多读多写
将热点key散列为多个子key，子key被hash到缓存集群的不同机器上，读数据的时候随机选择一个子key访问对应的缓存服务器，写数据的时候要更新该key对应的所有子key值。
假设某个热点key被散列为N个子key，缓存服务器的数量M>N，最理想的情况下，缓存服务器压力会降低到单key的1/N。
该方案需要业务提前感知热点key或者采用具有统计hotkey能力的缓存服务器，同时更新N份缓存数据也存在部分失败的风险，业务需要容忍短时间内的数据不一致。
6 缓存预热
缓存预热是指在用户可访问服务之前，将热点数据加载到缓存的操作，这样可以有效避免上线后瞬时大流量造成系统不可用。
