太强了，全面解析缓存应用经典问题

本文正在参加「金石计划 . 分割6万现金大奖」

hello，我们好，我是张张，「架构精进之路」公号作者。

1、前语

跟着互联网从简略的单向阅读恳求，发展为依据用户个性信息的定制化以及交际化的恳求，这要求产品需求做到以用户和联系为根底，对海量数据进行剖析和核算。关于后端服务来说，意味着用户的每次恳求都需求查询用户的个人信息和很多的联系信息，此外大部分场景还需求对上述信息进行聚合、过滤、排序，终究才干回来给用户。

CPU是信息处理、程序运转的终究履行单元，假如它的世界也有“秒”的概念，假设它的时钟跳一下为一秒，那么在CPU（CPU的一个核心）眼中的时刻概念是什么样的呢？

可见I/O的速度与CPU和内存相比是要差几个数量级的，假如数据悉数从数据库获取，一次恳求触及屡次数据库操作会大大增加呼应时刻，无法供给好的用户体验。

关于大型高并发场景下的Web运用，缓存更为重要，更高的缓存射中率就意味着更好的功用。缓存体系的引进，是提高体系呼应时延、提高用户体验的仅有途径，杰出的缓存架构规划也是高并发体系的基石。

缓存的思维依据以下几点：

• 时刻局限性原理 程序有在一段时刻内屡次拜访同一个数据块的倾向。例如一个热门的商品或许一个热门的新闻会被数以百万乃至千万的更多用户检查。经过缓存，能够高效地重用之前检索或核算的数据。

• 以空间换取时刻 关于大部分体系，全量数据一般存储在MySQL 或许Hbase，可是它们的拜访效率太低。所以会开辟一个高速的拜访空间来加快拜访过程，例如Redis读的速度是110000次/s，写的速度是81000次/s 。

• 功用和本钱的Tradeoff 高速的拜访空间带来的是本钱的提高，在体系规划时要兼顾功用和本钱。例如，在相同本钱的状况下，SSD 硬盘容量会比内存大 10～30 倍以上，但读写推迟却高 50～100 倍。

引进缓存会给体系带来以下优势：

• 提高恳求功用

• 下降网络拥塞

• 减轻服务负载

• 增强可扩展性

相同的，引进缓存也会带来以下劣势：

• 毫无疑问会增加体系的杂乱性，开发杂乱性和运维杂乱性成倍提高。

• 高速的拜访空间会比数据库存储的本钱高。

• 因为一份数据一同存在缓存和数据库中，乃至缓存内部也会有多个数据副本，多份数据就会存在数据双写的不一致问题，一同缓存体系本身也会存在可用性问题和分区的问题。

在缓存体系的规划架构中，还有许多坑，许多的明枪暗箭，假如规划不妥会导致许多严重的结果。规划不妥，轻则恳求变慢、功用下降，重则会数据不一致、体系可用性下降，乃至会导致缓存雪崩，整个体系无法对外供给服务。

2、缓存的主要存储形式

三种形式各有好坏，适用于不同的事务场景，不存在最佳形式。

● Cache Aside（旁路缓存）

写： 更新db时，删去缓存，当下次读取数据库时，驱动缓存的更新。

读： 读的时分先读缓存，缓存未射中，那么就读数据库，而且将数据回种到缓存，一同回来相应结果

**特色：**懒加载思维，以数据库中的数据为准。在稍微杂乱点的缓存场景，缓存都不简略是数据库中直接取出来的，或许还需求从其他表查询一些数据，然后进行一些杂乱的运算，才干终究核算出值。这种存储形式合适于对数据一致性要求比较高的事务，或许是缓存数据更新比较杂乱、代价比较高的事务。例如：一个缓存触及多个表的多个字段，在1分钟内被修改了100次，可是这个缓存在1分钟内就被读取了1次。假如运用这种存储形式只删去缓存的话，那么1分钟内，这个缓存不过就从头核算一次罢了，开支大幅度下降。

● Read/Write Through（读写穿透）

写： 缓存存在，更新数据库，缓存不存在，一同更新缓存和数据库

读： 缓存未射中，由缓存服务加载数据而且写入缓存

特色：

读写穿透对热数据友爱，特别合适有冷热数据区分的场合。

1）简化运用程序代码

在缓存方法中，运用程序代码依然很杂乱，而且直接依赖于数据库，假如多个运用程序处理相同的数据，乃至会呈现代码重复。读写穿透形式将一些数据拜访代码从运用程序转移到缓存层，这极大地简化了运用程序并更明晰地笼统了数据库操作。

2）具有更好的读取可伸缩性

在大都状况下，缓存数据过期今后，多个并行用户线程终究会打到数据库，再加上数以百万计的缓存项和数千个并行用户恳求，数据库上的负载会显著增加。读写穿透能够保证运用程序永远不会为这些缓存项拜访数据库，这也能够让数据库负载保持在最小值。

3）具有更好的写功用

读写穿透形式能够让运用程序快速更新缓存并回来，之后它让缓存服务在后台更新数据库。当数据库写操作的履行速度不如缓存更新的速度快时，还能够指定限流机制，将数据库写操作安排在非高峰时刻进行，减轻数据库的压力。

4）过期时主动刷新缓存

读写穿透形式允许缓存在过期时主动从数据库从头加载目标。这意味着运用程序不必在高峰时刻拜访数据库，因为最新数据总是在缓存中。

● Write Behind Caching（异步缓存写入）

**写：**只更新缓存，缓存服务异步更新数据库。

**读：**缓存未射中由封装好的缓存服务加载数据而且写入缓存。

**特色：**写功用最高，定期异步刷新数据库数据，数据丢掉的概率大，合适写频率高，而且写操作需求兼并的场景。运用异步缓存写入形式，数据的读取和更新经过缓存进行，与读写穿透形式不同，更新的数据并不会立即传到数据库。相反，在缓存服务中一旦进行更新操作，缓存服务就会跟踪脏记载列表，并定期将当时的脏记载集刷新到数据库中。作为额定的功用改进，缓存服务会兼并这些脏记载，兼并意味着假如相同的记载被更新，或许在缓冲区内被屡次标记为脏数据，则只保证终究一次更新。关于那些值更新十分频繁，例如金融市场中的股票价格等场景，这种方法能够很大程度上改进功用。假如股票价格每秒钟变化 100 次，则意味着在 30 秒内会发生 30 x 100 次更新，兼并将其削减至只要一次。

3、缓存的常见经典问题

3.1、缓存会集失效

缓存会集失效大大都状况呈现在高并发的时分，假如很多的缓存数据会集在一个时刻段失效，查询恳求会打到数据库，数据库压力凸显。比方同一批火车票、飞机票，当能够售卖时，体系会一次性加载到缓存，而且过期时刻设置为预先装备的固定时刻，那过期时刻到期后，体系就会因为热门数据的会集没有射中而呈现功用变慢的状况。

处理计划：

• 运用基准时刻+随机时刻，下降过期时刻的重复率，防止集体失效。即相同事务数据设置缓存失效时刻时，在本来设置的失效时刻根底上，再加上一个随机值，让数据涣散过期，一同对数据库的恳求也会涣散开，防止瞬时悉数过期对数据库形成过大压力。

3.2、缓存穿透

缓存穿透是指一些反常拜访，每次都去查询压根儿就不存在的key，导致每次恳求都会打到数据库上去。例如查询不存在的用户，查询不存在的商品id。假如是用户偶尔过错输入，问题不大。但假如是一些特别用户，控制一批肉鸡，持续的拜访缓存不存在的key，会严重影响体系的功用，影响正常用户的拜访，乃至或许会让数据库直接宕机。咱们在规划体系时，一般只考虑正常的拜访恳求，所以这种状况往往容易被疏忽。

处理计划：

• 第一种计划便是，查询到不存在的数据时，初次查询数据库，即便数据库没有数据，依然回种这个 key 到缓存，并运用一个特别约好的value表明这个key的值为空。后面再次呈现对这个key的恳求时，直接回来null。为了健壮性，设置空缓存key时，必定要设置过期时刻，以防止之后该key被写入了数据。

• 第二种计划是，构建一个 BloomFilter 缓存过滤器，记载全量数据，这样拜访数据时，能够直接经过 BloomFilter 判断这个 key 是否存在，假如不存在直接回来即可，压根儿不需求查询缓存或数据库。比方，能够运用依据数据库增量日志解析框架（阿里的canal），经过消费增量数据写入到BloomFilter 过滤器。BloomFilter的所有操作也是在内存里完结，功用很高，要到达 1% 的误判率，平均单条记载占用 1.2 字节即可。一同需求留意的是BloomFilter 只要新增没有删去操作，关于现已删去的key能够配合上述缓存空值处理计划一同运用。Redis供给了自定义参数的布隆顾忌器，能够运用bf.reserve进行创立，需求设置参数error_rate（过错率）和 innitial_size。error_rate越低需求的空间越大，innitial_size表明估计放入的元素数量，当实际数量超越这个值今后，误判率会上升。

3.3、缓存雪崩

缓存雪崩是缓存机器因为某种原因悉数或许部分宕机，导致很多的数据落到数据库，终究把数据库打死。例如某个服务，恰好在恳求高峰期间缓存服务宕机，本来打到缓存的恳求，这是时分悉数打到数据库，数据库扛不住在报警今后也会宕机，重启数据库今后，新的恳求会再次把数据库打死。

处理计划：

• 事前：缓存采用高可用架构规划，redis运用集群布置方法。对重要事务数据的数据库拜访增加开关，当发现数据库呈现堵塞、呼应慢超越阈值的时分，关闭开关，将一部分或许全都的数据库恳求履行failfast操作。

• 事中：引进多级缓存架构，增加缓存副本，比方新增本地 ehcache 缓存。引进限流降级组件，对缓存进行实时监控和实时报警。经过机器替换、服务替换进行及时康复；也能够经过各种主动毛病转移战略，主动关闭反常接口、中止边际服务、中止部分非核心功用措施，保证在极点场景下，核心功用的正常运转。

• 过后：redis耐久化，支撑一同敞开两种耐久化方法，咱们能够综合运用 AOF 和 RDB 两种耐久化机制，用 AOF 来保证数据不丢掉，作为数据康复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢掉或损坏不可用的时分，还能够运用 RDB 来进行快速的数据康复。一同把RDB 数据备份到远端的云服务，假如服务器内存和磁盘的数据一同丢掉，依然能够从远端拉取数据做灾备康复操作。

3.4、缓存数据不一致

同一份数据，既在缓存里又在数据库里，肯定会呈现数据库与缓存中的数据不一致现象。假如引进多级缓存架构，缓存会存在多个副本，多个副本之间也会呈现缓存不一致现象。缓存机器的带宽被打满，或许机房网络呈现动摇时，缓存更新失利，新数据没有写入缓存，就会导致缓存和 DB 的数据不一致。缓存 rehash 时，某个缓存机器反复反常，屡次上下线，更新恳求屡次 rehash。这样，一份数据存在多个节点，且每次 rehash 只更新某个节点，导致一些缓存节点发生脏数据。再比方，数据发生了变更，先删去了缓存，然后要去修改数据库，此时还没修改。一个恳求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中。随后数据变更的程序完结了数据库的修改，数据库和缓存中的数据不一样了。

处理计划：

• 设置key的过期时刻尽量短，让缓存更早的过期，从db加载新数据，这样无法保证数据的强一致性，可是能够保证终究一致性。

  cache更新失利今后引进重试机制，比方连续重试失利今后，能够将操作写入重试行列，当缓存服务可用时，将这些key从缓存中删去，当这些key被从头查询时，从头从数据库回种。

  延时双删去战略，首先删去缓存中的数据，在写数据库，休眠一秒今后（具体时刻需求依据具体事务逻辑的耗时进行调整）再次删去缓存。这样能够将一秒内形成的所有脏数据再次删去。

  缓存终究一致性，使客户端数据与缓存解耦，运用直接写数据到数据库中。数据库更新binlog日志，利用Canal中间件读取binlog日志。Canal借助于限流组件按频率将数据发到MQ中，运用监控MQ通道，将MQ的数据更新到Redis缓存中。

  更新数据的时分，依据数据的仅有标识，将操作路由之后，发送到一个 jvm 内部行列中。读取数据的时分，假如发现数据不在缓存中，那么将从头履行“读取数据+更新缓存”的操作，依据仅有标识路由之后，也发送到同一个 jvm 内部行列中。该计划关于读恳求进行了十分轻度的异步化，运用必定要留意读超时的问题，每个读恳求必须在超时时刻范围内回来。因而需求依据自己的事务状况进行测试，或许需求布置多个服务，每个服务分摊一些数据的更新操作。假如一个内存行列里居然会挤压 100 个事务数据的修改操作，每个操作操作要耗费 10ms 去完结，那么终究一个读恳求，或许等候 10 * 100 = 1000ms = 1s 后，才干得到数据，这个时分就导致读恳求的长时堵塞。

3.5、竞赛并发

当体系的线上流量特别大的时分，缓存中会呈现数据并发竞赛的现象。在高并发的场景下，假如缓存数据正好过期，各个并发恳求之间又没有任何协调动作，这样并发恳求就会打到数据库，对数据形成较大的压力，严重的或许会导致缓存“雪崩”。别的高并发竞赛也会导致数据不一致问题，例如多个redis客户端一同set同一个key时，key最开始的值是1，本来按顺序修改为2,3,4，终究是4，可是顺序变成了4,3,2，终究变成了2。

处理计划：

分布式锁+时刻戳

能够依据redis或许zookeeper完结一个分布式锁，当一个key被高并发拜访时，让恳求去抢锁。也能够引进音讯中间件，把Redis.set操作放在音讯行列中。总归，将并行读写改成串行读写的方法，然后来防止资源竞赛。关于key的操作的顺序性问题，能够经过设置一个时刻戳来处理。大部分场景下，要写入缓存的数据都是从数据库中查询出来的。在数据写入数据库时，能够保护一个时刻戳字段，这样数据被查询出来时都会带一个时刻戳。写缓存的时分，能够判断一下当时数据的时刻戳是否比缓存里的数据的时刻戳要新，这样就防止了旧数据对新数据的掩盖。

3.6、热门Key问题

关于大大都互联网体系，数据是分冷热的，拜访频率高的key被称为热key，比方热门新闻、热门的谈论。而在突发事件发生时，瞬间会有很多用户去拜访这个突发热门信息，这个突发热门信息所在的缓存节点因为超大流量而到达理网卡、带宽、CPU 的极限，然后导致缓存拜访变慢、卡顿、乃至宕机。接下来数据恳求到数据库，终究导致整个服务不可用。比方微博中数十万、数百万的用户一同去吃一个新瓜，秒杀、双11、618 、春节等线上促销活动，明星成婚、离婚、出轨这种特别突发事件。

处理计划：

要处理这种极热 key 的问题，首先要找出这些 热key 。关于重要节假日、线上促销活动、凭借经验能够提早评估出或许的热 key 来。而关于突发事件，无法提早评估，能够经过 Spark或许Flink，进行流式核算，及时发现新发布的热门 key。而关于之前已发出的事情，逐步发酵成为热 key 的，则能够经过 Hadoop 进行离线跑批核算，找出最近历史数据中的高频热 key。还能够经过客户端进行核算或许上报。找到热 key 后，就有许多处理办法了。首先能够将这些热 key 进行涣散处理。redis cluster有固定的16384个hash slot，对每个key核算CRC16值，然后对16384取模，能够获取key对应的hash slot。比方一个热 key 姓名叫 hotkey，能够被涣散为 hotkey#1、hotkey#2、hotkey#3，……hotkey#n，这 n 个 key 就会涣散存在多个缓存节点，然后 client 端恳求时，随机拜访其间某个后缀的热key，这样就能够把热 key 的恳求打散。

其次，也能够 key 的姓名不变，对缓存提早进行多副本+多级结合的缓存架构规划。比方利用ehcache，或许一个HashMap都能够。在你发现热key今后，把热key加载到体系的JVM中，之后针对热key的恳求，能够直接从jvm中获取数据。再次，假如热 key 较多，还能够经过监控体系对缓存的 SLA 实时监控，经过快速扩容来削减热 key 的冲击。

3.7、大Key问题

有些时分开发人员规划不合理，在缓存中会形成特别大的目标，这些大目标会导致数据迁移卡顿，别的在内存分配方面，假如一个key特别大，当需求扩容时，会一次性申请更大的一块内存，这也会导致卡顿。假如大目标被删去，内存会被一次性收回，卡顿现象会再次发生。在平时的事务开发中，要尽量防止大key的发生。假如发现体系的缓存大起大落，极有或许是大key引起的，这就需求开发人员定位出大key的来历，然后进行相关的事务代码重构。Redis官方现已供给了相关的指令进行大key的扫描，能够直接运用。

处理计划：

• 假如数据存在 Redis 中，比方事务数据存 set 格局，大 key 对应的 set 结构有几千几万个元素，这种写入 Redis 时会耗费很长的时刻，导致 Redis 卡顿。此时，能够扩展新的数据结构，一同让 client 在这些大 key 写缓存之前，进行序列化构建，然后经过 restore 一次性写入。

• 将大 key 分拆为多个 key，尽量削减大 key 的存在。一同因为大 key 一旦穿透到 DB，加载耗时很大，所以能够对这些大 key 进行特别照顾，比方设置较长的过期时刻，比方缓存内部在筛选 key 时，平等条件下，尽量不筛选这些大 key。

END

期望今日的讲解对我们有所帮助，谢谢！

Thanks for reading!

作者：架构精进之路，十年研发风雨路，大厂架构师，CSDN 博客专家，专注架构技术沉积学习及共享，职业与认知升级，坚持共享接地气儿的干货文章，等待与你一同生长。
关注并私信我回复“01”，送你一份程序员生长进阶大礼包，欢迎勾搭。