[TOC]
[图片上传失败...(image-2e0e27-1615694322860)]
常见概念：
- cache miss:表示没有命中缓存，如果缓存内容中还有内存空间的话，会将数据加入缓存中。
- 存储成本：当没有命中缓存时，回源获取会将数据防止到存储中，整个数据放置到存储空间所需要的时间以及空间称之为存储成本。
访问缓存场景分析：
缓存穿透
现象：每次请求直接穿透缓存层，直接回源到数据库中，给数据库带来了巨大访问压力，甚至宕机。
原因：访问数据会先访问缓存，如果缓存中数据不存在缓存中才会查询数据库，但是如果查询数据库也查询不出来数据，也是说当前访问数据永远不会写入缓存中。这就导致了，访问一定不存在的数据，就相当于缓存形同虚设，每次请求都会到db层，造成数据库负担过大。
解决方案：
- 如果db查询不到数据，保存空对象到缓存层，设置较短的失效时间
- 采用bloom filter保存缓存过的key，在访问请求到来时可以过滤掉不存在的key，防止这些请求到db层。（相当于保存了一份历史，如果历史中没有的，不让请求到db层）
- 针对业务场景对请求的参数进行有效性校验，防止非法请求击垮db
缓存击穿
现象：当某一key失效时，造成大量请求到db层，击垮存储层。
原因：为了保证缓存数据的时效性，通常会设置一个失效时间，如果是热点key，高并发时会有海量请求直接越过缓存层到数据库，这样就会给数据库造成的负担增大，甚至宕机。
解决方案：
- 使用互斥锁，当缓存失效时，保证一个请求能访问数据库，并更新缓存，其他线程等待并重试。
- 缓存数据“永不过期”：如果缓存数据不设置失效时间的话，就不会存在热点key过期造成了大量请求到数据库。但是，缓存数据就变成“静态数据”，因此当缓存数据快要过期时，采用异步线程的方式提前进行更新缓存数据。（后台偷偷更新）
缓存雪崩
现象：多个key失效，造成大量请求到db层，导致db层负担过重甚至宕机
原因：缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到数据库，最终导致数据库瞬时压力过大而崩溃。
解决方案：
- 方案一：使用互斥锁的方式，保证只有单个线程进行请求能够到达db层。
- 方案二：在每个key的失效时间的基础上再加一个1到5分钟的随机值，这样就能保证大规模key集体失效的概率，并且需要让多个key的失效时间能够均匀分布。
缓存击穿强调的是热点key的失效，导致某一时刻大量请求会直接到db层，解决方案的核心原则是规避数据库的并发操作。缓存雪崩强调的多个key的集体失效，与key是否是热点数据并不是必然的因素，解决方案的核心原则则让key之间的失效时间分布更加均匀，避免集体失效的情况。
数据更新场景分析
为什么不是更新缓存，而是失效（删除）缓存？
- 并发写容易写覆盖造成脏数据的问题（具体情况参考文章）
- 双写不同数据源容易造成数据不一致
- 违背数据懒加载，避免不必要的计算消耗（如果有些缓存值是需要经过复杂的计算才能得出，所以如果每次更新数据的时候都更新缓存，但是后续在一段时间内并没有读取该缓存数据，这样就白白浪费了大量的计算性能，完全可以后续由读请求的时候，再去计算即可，这样更符合数据懒加载，降低计算开销。）
可能存在的更新时序？
- 先缓存失效再更新数据库
[图片上传失败...(image-49d50f-1615694322860)] - 假设在并发的情况下，按照这种更新时序会存在什么问题？
线程A先失效缓存数据的时候，B线程读请求发现缓存数据为空的话，就会从数据库中读取旧值放入到缓存中，这样就导致后续的读请求读到的都是缓存中的脏数据。针对这样的情况可以采用延时双删的策略来有效避免，伪代码 如下：
cache.delKey(key);
db.update(data);
Thread.sleep(xxx);
cache.delKey(key);
主要是在写请求更新完数据库后进行休眠一段时间，然后删除可能由读请求带来的脏数据存入到缓存。另外，数据库如果采用的是主从分离的架构的话，读出来的数据也有可能是主从未同步完成造成的脏数据。这种通过延时双删的方式需要线程休眠，因此很显然会降低系统吞吐量，并不是一种优雅的解决方式，也可以采用异步删除的方式。当然可以设置过期时间，到期后缓存失效载入最新的数据，需要系统能够容忍一段时间的数据不一致。
- 先更新数据再失效缓存：这是推荐的更新数据时采用的方式，实际上这也是可能存在数据不一致的情况：
[图片上传失败...(image-4e5d0e-1615694322860)]
假设缓存刚好到期失效时，读请求从db中读取数据，写请求更新完数据后再失效缓存后，读请求将旧数据存入到缓存中，这种情况也会导致脏数据的问题。实际上这种情况发生的概率很低，要发生这种情况的前提条件是写数据库要先于读数据库完成，一般而言读数据库相比于写数据库要耗时更短，这种前提条件成立的概率很低。针对这种”逻辑失败“造成的数据不一致，可以采用上面所说的异步双删的策略以及过期失效的方式来避免。
个人理解：缓存刚好到期，此时读请求到db来读取缓存，读和写数据库发生并发，写数据库先完成，删除了缓存，然后读请求是拿到的老数据，导致缓存在被删除后，又更新为了读到的老数据。
Write/Read Through
Cache Aside Pattern对db以及缓存的更新逻辑是由调用方自己去控制，很显然这是一个很复杂的过程。Write/Read Through对调用方而言，缓存是作为整个的数据存储，而不用关系缓存后面的db，数据库的更新则是由缓存统一进行管理，对调用方而言只需要和缓存进行交互，整体过程是透明的。
- Read Through：当数据发生更新时，查询缓存时更新缓存，然后由缓存层同步的更新数据库即可，对调用方而言只需要和缓存层交互即可；
- Write Through：Write Through 套路和Read Through相仿，不过是在更新数据时发生。当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后再由Cache自己同步更新数据库。如下图所示（来源于网络）：
[图片上传失败...(image-5ba324-1615694322860)]
Write Behind Cache Pattern
这种模式是当数据更新的时候直接更新缓存数据，然后建立异步任务去更新数据库。这种异步方式请求响应会很快，系统的吞吐量会明显提升。但是，因为是异步更新数据库，数据一致性的保障就会变弱，如果更新数据库失败则会永远的造成系统脏数据，需要很精细设计系统重试的策略，另外如果异步服务宕机的话，还要考虑更新的数据如何持久化，服务重启后能够迅速恢复。在更新数据库时，由于并发多任务的存在，还需要考虑并发写是否会造成脏数据的问题，就需要追溯每次更新数据的时序。使用这种模式需要考虑的细节会有很多，设计出一套好的方案是件很不容易的事情。
数据不一致问题
原因：
逻辑失败造成的数据不一致： 在上一章主要分析了更新数据时的四种更新策略，在并发的情况下，无论是先删除缓存还是更新数据库，还是更新数据库再失效缓存，都会数据不一致的情况，主要是因为异步读写请求在并发情况下的操作时序导致的数据不一致，称之为”逻辑失败“。解决这种因为并发时序导致的问题，核心的解决思想是将异步操作进行串行化
物理失败造成的数据不一致： 在cache aside pattern中先更新数据库再删除缓存以及异步双删策略等等，如果删除缓存失败时都出现数据不一致的情况。但是数据库更新以及缓存操作是没办法放到一个事务中，一般来说，使用缓存是分布式缓存如果缓存服务很耗时，那么将更新数据库以及失效缓存放到一个事务中，就会造成大量的数据库连接挂起，严重的降低系统性能，甚至会因为数据库连接数过多，导致系统崩溃。像这种因为缓存操作失败，导致的数据不一致称之为”物理失败“。大多数情况物理失败的情况会重用重试的方式进行解决。
数据一致性的解决方案
在绝大部分业务场景中，追求的是最终一致性，针对物理失败造成的数据不一致常用的方案有：消费消息异步删除缓存以及订阅Binlog的方式，针对逻辑失败造成的数据不一致常用的方案有：队列异步操作同步化
消费消息异步删除缓存
[图片上传失败...(image-ec5eb7-1615694322860)]
订阅Binlog
[图片上传失败...(image-c27c4c-1615694322860)]
利用队列串行化
在分析cache aside pattern发现在并发的情况下也会存在数据不一致的场景，只不过发生的概率很低，另外如果先删除缓存再更新数据库在并发读写的情况下也会存在数据不一致的情况。类似这种由于并发时序导致的数据不一致的情况，都是因为写请求还没有结束读请求读取的是旧数据，如果读请求在写请求之后处理，即请求的处理能够串行化的话，就能保证读请求读到的是写请求更新的最新的数据。
将请求进行串行化，最常用的方式是采用队列的方式，一个队列只能对应一个工作线程，更新数据的写请求放置队列中，等待异步处理；读请求如果能从缓存中获取数据，则返回，如果缓存中没有数据，就将读请求放置到队列中，等待写请求数据更新完成。这种方案需要考虑的问题有：
- 读请求长时间阻塞：如果队列中挤压了多个写请求，则读请求会存在长时间阻塞的情况，需要设置超时处理策略，一旦超过超时时间，则直接读取数据库返回，避免长时间不响应；另外，在业务中需要进行压测，考虑队列中在峰值情况下会积攒多少写请求，如果过多，需要考虑队列优化的方式和相应的解决方案；
- 多个队列分散压力：可以根据数据项通过hash等路由方式，创建多个队列并行执行来提升系统吞吐量；
- 操作复杂需要考虑全面：由于采用队列来进行串行化，那么要考虑队列的可用性，队列阻塞以及服务挂掉后的容灾恢复策略是否健壮等等，相对而言整体的方案需要考虑的点会有很多；
常见的几个场景问题：
1）过期还是不过期缓存数据：针对缓存数据是否需要设置过期时间也需要结合场景来进行分析，一些长尾商品，大多数数据在业务中都是读场景更多，并且缓存空间很大的话，就可以考虑不过期数据。那是否就意味着这就是一份静态数据了？当缓存空间已满时，数据会根据淘汰策略移除缓存，另外数据更新时也可以通过Binlog等其他方式进行异步失效缓存。
如果系统通过消息异步更新操作成本过高或者依赖于外部系统无法进行订阅binlog异步更新的话，就需要来采用过期缓存数据来保障数据最终一致性。
2）维度化缓存与增量更新：如果一个实体包含多个属性，在实体发生变更时，如果将所有的属性全部更新一遍，这个成本就很高，况且只是其中的几个属性发生变化。因此，将多个属性进行各个维度化进行拆解，按照多维度进行缓存，更新时只需要增强更新对应维度即可；
3）大value：大value的问题要时刻警惕，可以考虑将value进行压缩，以及缓存时进行拆解，然后在业务服务中进行数据聚合来避免大value的问题；
4）热点缓存问题：针对热点数据如果每次都从远程缓存去获取，会给缓存系统带来过多的负载，会导致获取缓存数据响应过慢，可以使用缓存集群，挂载更多的从缓存，读取数据从从缓存中获取。针对热点数据可以使用应用本地缓存来减少对远程缓存的请求负载；
5）数据预热：可以预先将数据加载到缓存中，方式缓存数据为空，大量的请求回源到db。如果容量很高可以考虑全量预热，如果容量优先，就只能选择高频热点数据进行数据预热，还需要关注是否有批量操作以及慢sql带来的性能问题，在整个数据预热过程中需要有可靠的监控机制来保障；
6）非预期热点数据：针对业务预估不足的热点数据，需要有热点发现系统来统计热点key，实时监控非预期的热点数据，可以将这些key推到本地缓存中，防止预估不足的热点key拖垮远程缓存服务。
7）缓存实例故障快速恢复：当某一个缓存实例故障后，缓存一般是采用分片实例存储，假设缓存key路由策略采用的取模机制的话，会导致当前实例的流量迅速到达db层，这种情况可以采用主从机制，当一个实例故障后其他实例可以使用，但是这种方式的问题在于水平扩展不够，如果分片实例上增加一个节点的话，会导致缓存命中率迅速下降。
如果key路由策略采用的一致性哈希的话，某一个实例节点故障，只会导致哈希环上的部分缓存不命中不会导致大量请求到达db，但是针对热点数据的话，可能会导致改节点负载过高成为系统瓶颈。针对实例故障恢复的方式有：1. 主从机制，对数据进行备份，尽可能保障有可用数据；2. 服务降低，新增缓存实例然后异步线程预热数据；3. 可以先采用一致性哈希路由策略，当出现热点数据时到达某个阈值时降级为取模的策略。
多级缓存设计案例
从用户发出请求到到最底层的数据库实际上会经历很多节点，因此在整个链路上都可以设置缓存，并且按照缓存最近原则将缓存放置在里用户最近的地方提升系统响应的效果最为明显，相应的提升系统吞吐量的效果就越为显著，通过能够大大降低对后端的压力。整个链路流程里可以添加缓存的地方有：发起请求->浏览器/客户端缓存->边缘缓存/CDN->反向代理(nginx)缓存->远程缓存->进程内缓存->数据库缓存。服务端多级缓存设计通用的技术方案如下：
[图片上传失败...(image-32078-1615694322860)]
Binlog:
binlog是MySQL server层维护的一种二进制日志，主要用来记录对mysql数据更新或潜在发生更新的SQL语句，并以事务的形式保存在磁盘中;
主要作用有：
- 复制：MySQL Replication在Master端开启binlog,master把它的二进制日志传递给slaves并回访来达到master-slave数据一致的目的
- 数据恢复：通过mysql binlog工具恢复数据
- 增量备份
查看binlog日志文件位置
show variables like '%log_bin%';
-- 查看binlog格式
show variables like 'binlog_format';
携程机票订单缓存方案
为了解决数据一致性问题，我们设计了两套方案来更新缓存数据，保证缓存数据的实时性。两套方案相互补充，避免其一短暂失效而产生一致性问题。
方案一的思路是扫描数据库的数据变化记录，比如数据表里面的数据更新时间戳，或者订阅数据库的binlog记录。当扫描到数据变化时，删除对应的缓存数据。
方案二的思路是借助于携程的消息通知平台服务。在订单处理流转的各个重要环节，会有消息事件产生。通过订阅这些消息，能够感知到订单数据的变化，并且通过对不同消息的影响数据范围可以精准地配置缓存数据更新。
两套方案的并行实施，保证了缓存数据的延迟控制在了100毫秒以内。