缓存架构设计

103 阅读 0 评论 68 点赞

我是靠谱客的博主标致小海豚，最近开发中收集的这篇文章主要介绍缓存架构设计，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

1：缓存技术和框架的重要性

互联网的一些高并发，高性能的项目和系统中，缓存技术是起着功不可没的作用。缓存不仅仅是key-value的简单存取，它在具体的业务场景中，还是很复杂的，需要很强的架构设计能力。我曾经就遇到过因为缓存架构设计不到位，导致了系统崩溃的案例。

2：缓存的技术方案分类

1）是做实时性比较高的那块数据，比如说库存，销量之类的这种数据，我们采取的实时的缓存+数据库双写的技术方案，双写一致性保障的方案。

2）是做实时性要求不高的数据，比如说商品的基本信息，等等，我们采取的是三级缓存架构的技术方案，就是说由一个专门的数据生产的服务，去获取整个商品详情页需要的各种数据，经过处理后，将数据放入各级缓存中。

3：高并发以及高可用的复杂系统中的缓存架构都有哪些东西

1）在大型的缓存架构中，redis是最最基础的一层。高并发，缓存架构中除了redis，还有其他的组成部分，但是redis至关重要。

如果你的数据量不大（10G以内），单master就可以。redis持久化+备份方案+容灾方案+replication（主从+读写分离）+sentinal（哨兵集群，3个节点，高可用性）
如果你的数据量很大（1T+），采用redis cluster。多master分布式存储数据，水平扩容,自动进行master -> slave的主备切换。

2）最经典的缓存+数据库读写的模式，cache aside pattern。读的时候，先读缓存，缓存没有的话，那么就读数据库。更新缓存分以下两种方式：

数据发生变化时，先更新缓存，然后再更新数据库。这种适用于缓存的值相对简单，和数据库的值一一对应，这样更新比较快。
数据发生变化时，先删除缓存，然后再更新数据库，读数据的时候再设置缓存。这种适用于缓存的值比较复杂的场景。比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据，并进行运算，才能计算出缓存最新的值的。这样更新缓存的代价是很高的。如果你频繁修改一个缓存涉及的多个表，那么这个缓存会被频繁的更新，频繁的更新缓存代价很高。而且这个缓存的值如果不是被频繁访问，就得不偿失了。

大部分情况下，建议适用删除更新的方式。其实删除缓存，而不是更新缓存，就是一个lazy计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。

举个例子，一个缓存涉及的表的字段，在1分钟内就修改了20次，或者是100次，那么缓存跟新20次，100次; 但是这个缓存在1分钟内就被读取了1次，有大量的冷数据。28黄金法则，20%的数据，占用了80%的访问量。实际上，如果你只是删除缓存的话，那么1分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低。每次数据过来，就只是删除缓存，然后修改数据库，如果这个缓存，在1分钟内只是被访问了1次，那么只有那1次，缓存是要被重新计算的。

3）数据库与缓存双写不一致问题的解决方案

问题：并发请求的时候，数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改。另一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中。

方案：数据库与缓存更新与读取操作进行异步串行化。（引入队列）

更新数据的时候，将相应操作发送到一个jvm内部的队列中。读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据的操作也发送到同一个jvm内部的队列中。队列消费者串行拿到对应的操作，然后一条一条的执行。这样的话，一个数据变更的操作，先执行删除缓存，然后再去更新数据库，但是还没完成更新。此时如果一个读请求过来，读到了空的缓存，那么可以先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成。

这里有两个可以优化的点：

一个队列中，其实多个读缓存，更新缓存的请求串在一起是没意义的，而且如果读同一缓存的大量请求到来时，会依次进入队列等待，这样会导致队列最后一个的请求响应时间超时。因此可以做过滤，如果发现队列中已经有一个读缓存，更新缓存的请求了，那么就不用再放个新请求操作进去了，直接等待前面的更新操作请求完成即可。如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回; 如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的旧值。
如果请求量特别大的时候，可以用多个队列，每个队列对应一个线程。每个请求来时可以根据请求的标识id进行hash路由进入到不同的队列。

最后，一定要做根据实际业务系统的运行情况，去进行一些压力测试，和模拟线上环境，去看看最繁忙的时候，内存队列可能会挤压多少更新操作，可能会导致最后一个更新操作对应的读请求，会hang多少时间，如果读请求在200ms返回，如果你计算过后，哪怕是最繁忙的时候，积压10个更新操作，最多等待200ms，那还可以的。如果一个内存队列可能积压的更新操作特别多，那么你就要加机器，让每个机器上部署的服务实例处理更少的数据，那么每个内存队列中积压的更新操作就会越少。其实根据之前的项目经验，一般来说数据的写频率是很低的，因此实际上正常来说，在队列中积压的更新操作应该是很少的。

举个例子：一秒就100个写操作。单台机器，20个内存队列，每个内存队列，可能就积压5个写操作，每个写操作性能测试后，一般在20ms左右就完成，那么针对每个内存队列中的数据的读请求，也就最多hang一会儿，200ms以内肯定能返回了。如果把写QPS扩大10倍，但是经过刚才的测算，就知道，单机支撑写QPS几百没问题，那么就扩容机器，扩容10倍的机器，10台机器，每个机器20个队列，200个队列。大部分的情况下，应该是这样的，大量的读请求过来，都是直接走缓存取到数据的，少量情况下，可能遇到读跟数据更新冲突的情况，如上所述，那么此时更新操作如果先入队列，之后可能会瞬间来了对这个数据大量的读请求，但是因为做了去重的优化，所以也就一个更新缓存的操作跟在它后面。

4）大型缓存全量更新问题的解决方案

问题：缓存数据很大时，可能导致redis的吞吐量就会急剧下降，网络耗费的资源大。如果不维度化，就导致多个维度的数据混合在一个缓存value中。而且不同维度的数据，可能更新的频率都大不一样。拿商品详情页来说，如果现在只是将1000个商品的分类批量调整了一下，但是如果商品分类的数据和商品本身的数据混杂在一起。那么可能导致需要将包括商品在内的大缓存value取出来，进行更新，再写回去，就会很坑爹，耗费大量的资源，redis压力也很大

方案：缓存维度化。举个例子：商品详情页分三个维度：商品维度，商品分类维度，商品店铺维度。将每个维度的数据都存一份，比如说商品维度的数据存一份，商品分类的数据存一份，商品店铺的数据存一份。那么在不同的维度数据更新的时候，只要去更新对应的维度就可以了。大大减轻了redis的压力。

5）通过多级缓存，达到高并发极致，同时给缓存架构最后的安全保护层。具体可以参照上一篇文章【亿级流量的商品详情页架构分析】。

6）分布式并发缓存重建的冲突问题的解决方案

问题：假如数据在所有的缓存中都不存在了（LRU算法弄掉了），就需要重新查询数据写入缓存。对于分布式的重建缓存，在不同的机器上，不同的服务实例中，去做上面的事情，就会出现多个机器分布式重建去读取相同的数据，然后写入缓存中。

方案：分布式锁：如果你有多个机器在访问同一个共享资源，那么这个时候，如果你需要加个锁，让多个分布式的机器在访问共享资源的时候串行起来。分布式锁当然有很多种不同的实现方案，redis分布式锁，zookeeper分布式锁。

zookeeper分布式锁的解决并发冲突的方案

（1）变更缓存重建以及空缓存请求重建，更新redis之前，都需要先获取对应商品id的分布式锁
（2）拿到分布式锁之后，需要根据时间版本去比较一下，如果自己的版本新于redis中的版本，那么就更新，否则就不更新
（3）如果拿不到分布式锁，那么就等待，不断轮询等待，直到自己获取到分布式的锁

7）缓存冷启动的问题的解决方案

问题：新系统第一次上线，此时在缓存里可能是没有数据的。或者redis缓存全盘崩溃了，数据也丢了。导致所有请求打到了mysql。导致mysql直接挂掉。

方案：缓存预热。

提前给redis中灌入部分数据，再提供服务
肯定不可能将所有数据都写入redis，因为数据量太大了，第一耗费的时间太长了，第二根本redis容纳不下所有的数据，需要根据当天的具体访问情况，实时统计出访问频率较高的热数据，然后将访问频率较高的热数据写入redis中，肯定是热数据也比较多，我们也得多个服务并行读取数据去写，并行的分布式的缓存预热。

8）恐怖的缓存雪崩问题的解决方案

问题：缓存服务大量的资源全部耗费在访问redis和源服务无果，最后自己被拖死，无法提供服务。

方案：相对来说，考虑的比较完善的一套方案，分为事前，事中，事后三个层次去思考怎么来应对缓存雪崩的场景。

事前：高可用架构。主从架构，操作主节点，读写，数据同步到从节点，一旦主节点挂掉，从节点跟上。
事中：多级缓存。redis cluster已经彻底崩溃了，缓存服务实例的ehcache的缓存还能起到作用。
事后：redis数据可以恢复，做了备份，redis数据备份和恢复，redis重新启动起来。

9）缓存穿透问题的解决方案

问题：缓存中没有这样的数据，数据库中也没有这样的数据。由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

方案：有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。