Redis缓存篇
一、缓存
为了系统性能的提升，我们一般都会将部分数据放入缓存中，加速访问。而 db 承担数据落盘工作。
哪些数据适合放入缓存？
- 即时性、数据一致性要求不高的
- 访问量大且更新频率不高的数据（读多，写少）
举例：电商类应用，商品分类，商品列表等适合缓存并加一个失效时间(根据数据更新频率来定)，后台如果发布一个商品，买家需要 5 分钟才能看到新的商品一般还是可以接受的。
伪代码如下：
data = cache.load(id);//从缓存加载数据
If(data == null){
data = db.load(id);//从数据库加载数据
cache.put(id,data);//保存到 cache 中
}
return data;
注意：在开发中，凡是放入缓存中的数据我们都应该指定过期时间，使其可以在系统即使没有主动更新数据也能自动触发数据加载进缓存的流程。避免业务崩溃导致的数据永久不一致问题。
本地缓存与分布式缓存：
本地缓存：和微服务同一个进程。缺点：分布式时本地缓存不能共享
分布式缓存：缓存中间件，例如redis。
二、缓存失效问题
大并发读情况下的缓存失效问题。
缓存穿透
假如发送过来的key是不存在于Redis中的，那么就查不到缓存，查不到缓存就去数据库中查，若数据库也查不到，这些请求就像是“穿透”了一样，全都打在了数据库层面，这就是缓存穿透。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。
解决方法
- 最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。
- 缓存无效key，如果缓存和数据库都查不到某个key，就将这个key往Redis里面存入一个类似null的值（java层面是不允许直接设置null给Redis的，会抛异常），并且设置一个较短的过期时间。
/*
解决缓存穿透的伪代码
1.设置一个类似于null值的标志
2.若从缓存中和数据库中查不到的话，将这个null值的标志存入redis,同时设置它一个较短的过期时间
*/
public String getDictInfoStrikeByNull(String key){
String nullTag = "" ;
//1.从redis中获取值
String dictValue = getFromRedis(key);
if(dictValue ==null){
//当redis中不存在时访问数据库
dictValue = sysDictDbService.loadData(key);
//从数据库中查询不到数据则redis填充标记值
//如果从redis取得是null标记字符则也返回null
return nullTag.equals(dictValue) ? null : dictValue;
}
- 布隆过滤器
详解布隆过滤器的原理，使用场景和注意事项 - 知乎 (zhihu.com)
https://javaguide.cn/cs-basics/data-structure/bloom-filter.html
加入布隆过滤器之后的缓存处理流程图如下。
布隆过滤器（Bloom Filter）是 1970 年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。
布隆过滤器是一个 bit 向量或者说 bit 数组，长这样：
如果我们要映射一个值到布隆过滤器中，我们需要使用多个不同的哈希函数生成**多个哈希值，**并对每个生成的哈希值指向的 bit 位置 1，例如针对值 “baidu” 和三个不同的哈希函数分别生成了哈希值 1、4、7，则上图转变为：
Ok，我们现在再存一个值 “tencent”，如果哈希函数返回 3、4、8 的话，图继续变为：
值得注意的是，4 这个 bit 位由于两个值的哈希函数都返回了这个 bit 位，因此它被覆盖了。现在我们如果想查询 “dianping” 这个值是否存在，哈希函数返回了 1、5、8三个值，结果我们发现 5 这个 bit 位上的值为 0，说明没有任何一个值映射到这个 bit 位上，因此我们可以很确定地说 “dianping” 这个值不存在。而当我们需要查询 “baidu” 这个值是否存在的话，那么哈希函数必然会返回 1、4、7，然后我们检查发现这三个 bit 位上的值均为 1，那么我们可以说 “baidu” 存在了么？答案是不可以，只能是 “baidu” 这个值可能存在。
这是为什么呢？答案跟简单，因为随着增加的值越来越多，被置为 1 的 bit 位也会越来越多，这样某个值 “taobao” 即使没有被存储过，但是万一哈希函数返回的三个 bit 位都被其他值置位了 1 ，那么程序还是会判断 “taobao” 这个值存在。
总结：
当字符串存储要加入到布隆过滤器中时，该字符串首先由多个哈希函数生成不同的哈希值，然后将对应的位数组的下标设置为 1（当位数组初始化时，所有位置均为 0）。当第二次存储相同字符串时，因为先前的对应位置已设置为 1，所以很容易知道此值已经存在（去重非常方便）。
不同的字符串可能哈希出来的位置相同，这种情况我们可以适当增加位数组大小或者调整我们的哈希函数。
综上，我们可以得出：布隆过滤器说某个元素存在，小概率会误判(因为hash冲突)。布隆过滤器说某个元素不在，那么这个元素一定不在。
简单版，使用boolean判断，哈希冲突的概率比较大，即误判很大：
public class MyBloomFilter {
/**
* 位数组的大小
*/
private static final int DEFAULT_SIZE = 1 << 28;
/**
* 通过这个数组可以创建 6 个不同的哈希函数
*/
private static final int[] SEEDS = new int[]{3, 13, 31, 71, 91, 117};
/**
* 位数组
*/
private boolean[] bits = new boolean[DEFAULT_SIZE];
/**
* 存放包含 hash 函数的类的数组
*/
private SimpleHash[] func = new SimpleHash[SEEDS.length];
/**
* 初始化多个包含 hash 函数的类的数组，每个类中的 hash 函数都不一样
*/
public MyBloomFilter() {
// 初始化多个不同的 Hash 函数
for (int i = 0; i < SEEDS.length; i++) {
func[i] = new SimpleHash(DEFAULT_SIZE, SEEDS[i]);
}
}
/**
* 添加元素到位数组
*/
public void add(Object value) {
for(SimpleHash sh : func){
bits[sh.hash(value)] = true;
}
}
/**
* 判断指定元素是否存在于位数组
*/
public boolean contains(Object value) {
for(SimpleHash sh : func){
if(!bits[sh.hash(value)]) return false;
}
return true;
}
/**
* 静态内部类。用于 hash 操作！
*/
public static class SimpleHash {
private int mask;
private int seed;
public SimpleHash(int cap, int seed) {
this.mask = cap - 1;
this.seed = seed;
}
/**
* 计算 hash 值
* 仿照hashMap1.8的hash函数
*/
public int hash(Object value) {
int h;
return (value == null) ? 0 : mask & (seed * ((h = value.hashCode()) ^ (h >>> 16)));
}
}
}
利用jdk中的BitSet，这样几乎没有哈希冲突了，误判次数很少。
当一个元素加入布隆过滤器中的时候，会进行哪些操作：
- 使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。
- 根据得到的哈希值，在位数组中把对应下标的值置为 1。
当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行哪些操作：
- 对给定元素再次进行相同的哈希计算；
- 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。
然后，一定会出现这样一种情况：不同的字符串可能哈希出来的位置相同。 （可以适当增加位数组大小或者调整我们的哈希函数来降低概率）
缓存击穿
key对应的数据存在，但是在redis中过期了（某一个key），此时若有大量的并发进来，这些请求发现缓存过期后都去数据库中查，查到之后再放回缓存，这时候大并发的请求可能瞬间把后端数据库压垮。
解决方法
- 如果是对于热点缓存的话，可以考虑这个key永不过期。
- 使用互斥锁。
如果想要保证一台机器只能有一个线程去查数据库的话，那么可以加一个synchronized关键字，搭配上双重检查的机制。伪代码如下：
public Object getData(){
Object data = redis.get(key);
if(data == null){
synchronized(this){
data = redis.get(key);
if(data == null){
data = db.get(key);
redis.set(key,data);
}
}
}
return data;
}
也可以采用redis的setnx命令，让全局只有一条线程去查，其他没有setnx成功的线程自旋等待。
缓存雪崩
什么是缓存雪崩？
缓存在同一时间大面积的失效，后面的请求都直接落到了数据库上，造成数据库短时间内承受大量请求。
举个例子 ：秒杀开始 12 个小时之前，我们统一存放了一批商品到 Redis 中，设置的缓存过期时间也是 12 个小时，那么秒杀开始的时候，这些秒杀的商品的访问直接就失效了。导致的情况就是，相应的请求直接就落到了数据库上，就像雪崩一样可怕。
发生缓存雪崩有两个原因：
- 大量数据同时过期；
- Redis 故障宕机；
Redis故障宕机
- 服务熔断
因为 Redis 故障宕机而导致缓存雪崩问题时，我们可以启动服务熔断机制，暂停业务应用对缓存服务的访问，直接返回错误，不用再继续访问数据库，从而降低对数据库的访问压力，保证数据库系统的正常运行，然后等到 Redis 恢复正常后，再允许业务应用访问缓存服务。
服务熔断机制是保护数据库的正常运行，但是暂停了业务应用访问缓存服务，全部业务都无法正常工作。
- 请求限流
只将少部分请求发送到数据库进行处理，再多的请求就在入口直接拒绝服务，等到 Redis 恢复正常并把缓存预热完后，再解除请求限流的机制。
- redis集群
服务熔断或请求限流机制是缓存雪崩发生后的应对方案，我们最好通过主从节点的方式构建 Redis 缓存高可靠集群。
如果 Redis 缓存的主节点故障宕机，从节点可以切换成为主节点，继续提供缓存服务，避免了由于 Redis 故障宕机而导致的缓存雪崩问题。
大量数据同时过期
- 均匀设置过期时间
如果要给缓存数据设置过期时间，应该避免将大量的数据设置成同一个过期时间。我们可以在对缓存数据设置过期时间时，给这些数据的过期时间加上一个随机数，这样就保证数据不会在同一时间过期。
- 互斥锁
当业务线程在处理用户请求时，如果发现访问的数据不在 Redis 里，就加个互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到 Redis 里），当缓存构建完成后，再释放锁。未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。
实现互斥锁的时候，最好设置超时时间，不然第一个请求拿到了锁，然后这个请求发生了某种意外而一直阻塞，一直不释放锁，这时其他请求也一直拿不到锁，整个系统就会出现无响应的现象。
- 双key策略
我们对缓存数据可以使用两个 key，一个是主 key，会设置过期时间，一个是备 key，不会设置过期，它们只是 key 不一样，但是 value 值是一样的，相当于给缓存数据做了个副本。
当业务线程访问不到「主 key 」的缓存数据时，就直接返回「备 key 」的缓存数据，然后在更新缓存的时候，同时更新「主 key 」和「备 key 」的数据。
双 key 策略的好处是，当主 key 过期了，有大量请求获取缓存数据的时候，直接返回备 key 的数据，这样可以快速响应请求。而不用因为 key 失效而导致大量请求被锁阻塞住（采用了互斥锁，仅一个请求来构建缓存），后续再通知后台线程，重新构建主 key 的数据。
- 后台缓存更新
业务线程不再负责更新缓存，缓存也不设置有效期，而是让缓存“永久有效”，并将更新缓存的工作交由后台线程定时更新。
事实上，缓存数据不设置有效期，并不是意味着数据一直能在内存里，因为当系统内存紧张的时候，有些缓存数据会被“淘汰”，而在缓存被“淘汰”到下一次后台定时更新缓存的这段时间内，业务线程读取缓存失败就返回空值，业务的视角就以为是数据丢失了。
解决上面的问题的方式有两种。
第一种方式，后台线程不仅负责定时更新缓存，而且也负责频繁地检测缓存是否有效，检测到缓存失效了，原因可能是系统紧张而被淘汰的，于是就要马上从数据库读取数据，并更新到缓存。
这种方式的检测时间间隔不能太长，太长也导致用户获取的数据是一个空值而不是真正的数据，所以检测的间隔最好是毫秒级的，但是总归是有个间隔时间，用户体验一般。
第二种方式，在业务线程发现缓存数据失效后（缓存数据被淘汰），通过消息队列发送一条消息通知后台线程更新缓存，后台线程收到消息后，在更新缓存前可以判断缓存是否存在，存在就不执行更新缓存操作；不存在就读取数据库数据，并将数据加载到缓存。这种方式相比第一种方式缓存的更新会更及时，用户体验也比较好。
在业务刚上线的时候，我们最好提前把数据缓起来，而不是等待用户访问才来触发缓存构建，这就是所谓的缓存预热，后台更新缓存的机制刚好也适合干这个事情。
三、缓存与数据一致性
先更新数据库，还是先更新缓存？
- 先更新数据库再更新缓存
- A 请求先将数据库的数据更新为 1，然后在更新缓存前，请求 B 将数据库的数据更新为 2，紧接着也把缓存更新为 2，然后 A 请求更新缓存为 1。
- 此时，数据库中的数据是 2，而缓存中的数据却是 1，出现了缓存和数据库中的数据不一致的现象。
- 先更新缓存再更新数据库
- A 请求先将缓存的数据更新为 1，然后在更新数据库前，B 请求来了， 将缓存的数据更新为 2，紧接着把数据库更新为 2，然后 A 请求将数据库的数据更新为 1。
- 此时，数据库中的数据是 1，而缓存中的数据却是 2，出现了缓存和数据库中的数据不一致的现象。
- 无论是「先更新数据库，再更新缓存」，还是「先更新缓存，再更新数据库」，这两个方案都存在并发问题，当两个请求并发更新同一条数据的时候，可能会出现缓存和数据库中的数据不一致的现象。
先更新缓存，还是先删除缓存？
- 先删除缓存，再更新数据库
- 假设某个用户的年龄是 20，请求 A 要更新用户年龄为 21，所以它会删除缓存中的内容。这时，另一个请求 B 要读取这个用户的年龄，它查询缓存发现未命中后，会从数据库中读取到年龄为 20，并且写入到缓存中，然后请求 A 继续更改数据库，将用户的年龄更新为 21。
- 最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库的数据不一致。
- 可以看到，先删除缓存，再更新数据库，在「读 + 写」并发的时候，还是会出现缓存和数据库的数据不一致的问题。
- 先更新数据库，再删除缓存
- 假如某个用户数据在缓存中不存在，请求 A 读取数据时从数据库中查询到年龄为 20，在未写入缓存中时另一个请求 B 更新数据。它更新数据库中的年龄为 21，并且清空缓存。这时请求 A 把从数据库中读到的年龄为 20 的数据写入到缓存中。最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库数据不一致。
- 从上面的理论上分析，先更新数据库，再删除缓存也是会出现数据不一致性的问题，但是在实际中，这个问题出现的概率并不高。因为缓存的写入通常要远远快于数据库的写入，所以在实际中很难出现请求 B 已经更新了数据库并且删除了缓存，请求 A 才更新完缓存的情况。
- 而一旦请求 A 早于请求 B 删除缓存之前更新了缓存，那么接下来的请求就会因为缓存不命中而从数据库中重新读取数据，所以不会出现这种不一致的情况。
- 所以，「**先更新数据库 + 再删除缓存」的方案，是可以保证数据一致性的。**并且可以给缓存数据加上了「过期时间」，就算在这期间存在缓存数据不一致，有过期时间来兜底，这样也能达到最终一致。
为什么明明更新了数据，但是数据要过一段时间才生效？
「先更新数据库， 再删除缓存」其实是两个操作，前面的所有分析都是建立在这两个操作都能同时执行成功，而在删除缓存（第二个操作）的时候失败了，导致缓存中的数据是旧值。
好在之前给缓存加上了过期时间，所以才会出现过一段时间才更新生效的现象，假设如果没有这个过期时间的兜底，那后续的请求读到的就会一直是缓存中的旧数据，这样问题就更大了。
如何保证「先更新数据库 ，再删除缓存」这两个操作能执行成功？
以下两个方法都是异步操作缓存。
重试机制
我们可以引入消息队列，将第二个操作（删除缓存）要操作的数据加入到消息队列，由消费者来操作数据。
- 如果应用删除缓存失败，可以从消息队列中重新读取数据，然后再次删除缓存，这个就是重试机制。当然，如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了。
- 如果删除缓存成功，就要把数据从消息队列中移除，避免重复操作，否则就继续重试。
订阅 MySQL binlog，再操作缓存
「先更新数据库，再删缓存」的策略的第一步是更新数据库，那么更新数据库成功，就会产生一条变更日志，记录在 binlog 里。
于是我们就可以通过订阅 binlog 日志，拿到具体要操作的数据，然后再执行缓存删除。
四、常见的缓存读写策略
Cache Aside Pattern（旁路缓存模式）
- 写操作：更新db然后删除缓存
- 读操作：先读缓存，读不到就读db，然后回写缓存
- 服务端需要同时维系 DB 和 cache
为什么是删除缓存而不是更新缓存？
- 在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值，比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据并进行运算，才能计算出缓存最新的值的。更新缓存的代价有时候是很高的，如果你频繁修改一个缓存涉及的多个表，缓存也频繁更新，但这个缓存并非是会被频繁访问到的，开销就会很大了。其实删除缓存，而不是更新缓存，就是一个 lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。
- 写db成功，更新缓存失败，会导致数据不一致
- 如果同⼀个操作时间内，有两个以上的更新操作，存在并发更新导致旧更新缓存覆盖了新更新缓存的情况。
缺陷
- 首次请求数据一定不在cache里：可以将热点数据可以提前放入cache 中。
- 写操作比较频繁的话导致cache中的数据会被频繁被删除，这样会影响缓存命中率 。解决方法：
- 数据库和缓存数据强一致场景 ：更新DB的时候同样更新cache，不过我们需要加一个锁/分布式锁来保证更新cache的时候不存在线程安全问题。
- 可以短暂地允许数据库和缓存数据不一致的场景 ：更新DB的时候同样更新cache，但是给缓存加一个比较短的过期时间，这样的话就可以保证即使数据不一致的话影响也比较小。
Read Through（读穿透）
- 从cache中读取数据，读取到就直接返回；
- 读取不到，先从db加载，写入到cache后返回响应。
在 Cache-Aside Pattern 下，发生读请求的时候，如果 cache 中不存在对应的数据，是由客户端自己负责把数据写入 cache，而 Read-Through Pattern 则是 cache 服务自己来写入缓存的，这对客户端是透明的。
和 Cache Aside Pattern 一样， Read-Through Pattern 也有首次请求数据一定不再 cache 的问题，对于热点数据可以提前放入缓存中。
Write Through（写穿透）
- 先查 cache，cache 中不存在，直接更新 DB。
- cache 中存在，则先更新 cache，然后 cache 服务自己更新 DB（同步更新 cache 和 DB）。
Write Back（异步缓存写入）
Write Behind Pattern 和 Read/Write Through Pattern 很相似，两者都是由 cache 服务来负责 cache 和 DB 的读写。
但是，两个又有很大的不同：Read/Write Through 是同步更新 cache 和 DB，而 Write Behind Caching 则是只更新缓存，不直接更新 DB，而是改为异步批量的方式来更新 DB。
- application写入缓存成功后直接返回，经过一段时间的延迟后，将缓存的数据回写db
- 如果Cache故障，可能会丢失数据：比如cache数据可能还没异步更新DB的话，cache服务可能就就挂掉了。
- 这种⽅式能极⾼地提升写⼊性能，适⽤于写⼊qps极⾼的服务，配合Read-Through 可以让数据有很好的⼀致
- 可以容忍db故障一段时间
- Write Behind Pattern 下 DB 的写性能非常高，非常适合一些数据经常变化又对数据一致性要求没那么高的场景，比如浏览量、点赞量。
五、如何设计一个缓存策略，可以动态缓存热点数据呢？
由于数据存储受限，系统并不是将所有数据都需要存放到缓存中的，而只是将其中一部分热点数据缓存起来，所以我们要设计一个热点数据动态缓存的策略。
热点数据动态缓存的策略总体思路：通过数据最新访问时间来做排名，并过滤掉不常访问的数据，只留下经常访问的数据。
以电商平台场景中的例子，现在要求只缓存用户经常访问的 Top 1000 的商品。具体细节如下：
- 先通过缓存系统做一个排序队列（比如存放 1000 个商品），系统会根据商品的访问时间，更新队列信息，越是最近访问的商品排名越靠前；
- 同时系统会定期过滤掉队列中排名最后的 200 个商品，然后再从数据库中随机读取出 200 个商品加入队列中；
- 这样当请求每次到达的时候，会先从队列中获取商品 ID，如果命中，就根据 ID 再从另一个缓存数据结构中读取实际的商品信息，并返回。
在 Redis 中可以用 zadd 方法和 zrange 方法来完成排序队列和获取 200 个商品的操作。