雪崩

缓存穿透: 查询一个不存在的数据，缓存中没有该数据信息，直接去数据库层进行查询。从整体上看，就仿佛穿透了缓存直接到达数据库，从而称为缓存穿透。没有缓存的保护，这种查询不存在的数据对系统有可能造成危害，如果有人恶意频繁查询不存在的数据攻击系统，请求直接到达数据层会导致db瘫痪引起系统故障。 解决方案： 空值存储： 一种简单的解决办法，在第一次查询完不存在的数据后，可以将该key进行空值存入缓存中，只是设定较短的失效时间。这样可以应对段时间的大量的该key攻击，之所有设置较短时间是因为该至无业务上的意义，因此没有必要过久存储。 bloom filter：（待学习） 类似于哈希表的一种算法，用所有可能的查询条件生成一个bitmap，在进行数据库查询之前会使用这个bitmap进行过滤，如果不在其中则直接过滤，从而减轻数据库层面的压力。guava中有实现BloomFilter算法 缓存雪崩： 缓存一般都有失效时间，如果缓存同一时间失效，那么大量的请求就会直达数据库，db可能无法承受如此大的压力导致系统崩溃。 解决方案 线程互斥： 只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据才可以，每个时刻只有一个线程在执行请求，减轻了db的压力，但缺点也很明显，降低了系统的qps。 交错失效时间： 这种方法时间比较简单粗暴，既然在同一时间失效会造成请求过多雪崩

为什么使用Redis? Redis是一个高性能基于key/value存储数据的分布式缓存数据库，基于内存运行并且支持持久化的NoSQL数据库。 根据CAP理论（强一致性、可用性和分区容错性），一个分布式系统不可能同时很好的满足这三个要求，最多只能较好的满足其中两个要求。那么分布式系统中分区容错性是必不可少的，而且结合当下用户体验至上的理念，系统可用性是任何一个系统都必须要满足的，所以只能让系统放松对某一时刻数据一致性要求来换取系统整体伸缩性和性能上的改观。所以就需要使用redis这样的NOSQL数据库来实现对数据的保存和操作。 Redis的三个重要特点： l Redis支出数据的持久化，可以将内存中的数据写进磁盘，还可以再次加在进磁盘继续使用 l Redis不仅仅支持简单的Key-value类型的数据，还支持list、set、哈希、以及zset等数据结构的存储 l Redis支持Master-Slaver模式的数据备份 Redis的优点与缺点 l 读写速度快，因为数据都是在内存中存放的； l 支持丰富的数据类型； l 所有的操作都是原子操作，部分支持事务 l 丰富的特性：可用于缓存、消息或者按Key设置过期时间等 Redis的数据类型、底层实现以及各种数据类型的使用场景 Redis的数据类型一共有五种： 数据类型 底层实现 特点 String 就是String类型的底层实现

工作中经常会用到redis来做缓存，以防止后台db挂掉。但是db数据一般都在10T以上，不可能把mysql中的数据全部放入redis中，所以一般是将一些热key放入redis中。 缓存击穿 一个请求先去redis中查询数据，如果存在则返回，不存在则去mysql中读取，然后回写到redis中，然后配上过期时间。这大概是redis最典型的用法了。但是如果某个时刻大量key的请求都没有命中缓存，那么这些大量请求就会全部落到mysql中，导致mysql压力过大。这个场景就是典型的缓存击穿。缓存击穿只需要把mysql数据会写到redis中就能得到解决。还有就是在配置过期时间的时候最好使用随机时间，否则大量的热key在同一时间过期，还是会周期性的造成缓存击穿。 但是还有一种场景是如果大量请求去请求同一个redis和mysql中都不存在的key，那么就会造成缓存雪崩。由此可以看出，缓存击穿和缓存雪崩现象是一样的，都是对mysql造成大量的请求和压力。但是解决办法不一样。面对缓存雪崩，常见的做法是把不存在的key会写到redis中，对应的value为空。否则请求还是会无止境的请求mysql的。 来源： https://www.cnblogs.com/howo/p/11363268.html

前言 设计一个缓存系统，不得不要考虑的问题就是：缓存穿透、缓存击穿与失效时的雪崩效应。 缓存穿透 访问一个不存在的key，缓存不起作用，请求会穿透到DB，流量大时DB会挂掉。 大并发的缓存穿透会导致缓存雪崩。 解决方案 1. 布隆过滤 采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。 2. 缓存空对象. 将 null 变成一个值. 如果一个查询返回的数据为空（不管是数据存不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 缓存雪崩 大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。 解决方案 1.用加锁或者队列的方式保证不会同时大量的并发请求落到底层存储系统上。 2.可以给缓存设置过期时间时加上一个随机值，使得每个key的过期时间分布开来，不会集中在同一时刻失效。 缓存击穿 一个存在的key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增。 解决方案 在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。 来源： https://www

缓存穿透 对不存在的 key进行高并发访问，导致数据库压力瞬间增大，这就叫做缓存穿透。 解决方案：对不存在的key也做一个缓存，内容为空，生存时间几秒即可 缓存雪崩 当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候进行高并发访问，也会给后端系统 (比如DB)带来很大压力。 解决方案：对 不同的 key，设置不同的过期时间，让缓存失效的时间点尽量均匀，避免集体失效。 缓存击穿 缓存在某个时间点过期的时候，恰好在这个时间点对这个 Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。 解决方案：添加锁或者采用队列，对不存在的key做缓存 来源： https://www.cnblogs.com/amiezhang/p/10014862.html

互联网开发四大法宝： 多线程，异步，缓存，分布式。 什么是缓存一致性 使用缓存的必要性： 需要从大量数据表进行计算统计 业务计算规则复杂 首页展现，活跃用户并发量较高 缓存信息的本质是硬盘数据的副本，归根究底是一种用空间换时间的技术，数据一致性是不可避免的。 运行期间遇到缓存一致性问题的情况： 更新数据库 -- 更新缓存 之一 失败。 四种解决方法 AOP实现： spring cache框架，加注解就可以实现数据库和redis一致，实时同步更新。 工具类：可以直接用redisTemplate，也可以用cacheManager 缓存雪崩 当缓存服务器重启或者大量缓存集中在某一个时间段失效，在失效的这一瞬间，高并发请求给后端系统(db)带来的巨大压力，甚至瘫痪。 =============== 另一篇全面的文章 缓存穿透，缓存击穿，缓存雪崩解决方案分析 前言 设计一个缓存系统，不得不要考虑的问题就是：缓存穿透、缓存击穿与失效时的雪崩效应。 缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 解决方案 有很多种方法可以有效地解决缓存穿透问题

高并发的情况会给系统带来很高的访问流量，这就给存储这些热点信息的Redis数据造成了一些压力。 热key问题及解决方案 产生原因 用户消费的数据远大于生产的数据 （热卖商品、热点新闻、热点评论、明星直播）等。 在日常工作生活中一些突发的的事件，例如某明星突然宣布恋情，导致某新闻点击量瞬间变大，请求远超过对数据的写入。就会造成热数据问题。 我们 一般采用缓存 + 过期时间的策略来帮助我们加速接口的访问速度，减少了后端负载，同时保证功能的更新，一般情况下这种模式已经基本满足要求了。 但是有两个问题如果同时出现，可能就会对系统造成致命的危害： 1、访问的数据是一个热点key 2、构建缓存需要时间 以上两个问题如果同时出现，就可能会造成缓存失效问题，有大量线程来构建缓存，造成后端负载过大，严重还会导致系统崩溃。 上图简单描述了访问热点key及构建缓存的一个过程。 解决方案 解决热点key问题，可以有以下几种方案， 1、互斥锁 在上图查询数据库的过程，只让一个线程独占，这个线程构建缓存的过程，其他线程都要等待，直到第一个线程构建完成可以从中读取数据。 2、提前使用互斥锁 提前使用互斥锁，和互斥锁差不多，都是让一个线程独占构建缓存，不一样的是，在构建缓存的时候。 在value内部设置一个超时值timeout1，这个过期时间比实际的缓存过期时间短。 当从缓存中读到timeout1已经过期的时候

Redis 经常用于系统中的缓存，可以极大地提高了系统性能和效率，但同时也带来一些问题。一个是数据一致性问题。从严格意义上讲，只要使用缓存，就会出现一致性问题，这是无法解决的。另一个问题是本文将讨论的缓存穿透，缓存击穿和缓存雪崩，这三个问题不仅限于 Redis，其他缓存工具同样需要面对这三个问题。接下来我详细讲解这三个问题以及对应的解决方案。 一、缓存穿透 缓存穿透意味着当用户查询数据库不存在数据时，返回的结果为空，并且结果不会在缓存中存储。假设用户不断发起这样的请求，它将永远不会访问缓存，导致所有查询都落在数据库上，从而导致数据库被打死。 public Object getGoods(Long goodsId) { //从 Redis 获取 goods 信息 Object goodsInfo = redisTemplate.opsForValue() .get(String.valueOf(goodsId)); if (goodsInfo != null) { return goodsInfo; } //从数据库查询 goods 信息，并存入 Redis goodsInfo = goodsDao.selectByGoodsId(goodsId); if (goodsInfo != null) { redisTemplate.opsForValue() .set(String

Hystrix：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。 说到熔断器，先要引入另外一个词，雪崩效应。 雪崩效应，百度百科的解释是这样的： 登山时，决不能顺着山边扔石子儿。一是有击中别人的危险，一枚从数千英尺落下的小石头，破坏力相当惊人；二是有可能引发雪崩，一枚不起眼的小石子儿，顶多只能撞动几块差不多大小的石头；但只要有足够数量的石头翻滚起来，用不了多久，大块大块的岩石也会松动下滑。于是乎，这一颗小小的石子儿，就能引发一场雪崩。这个道理不言自明，好比就是水滴石穿、蝴蝶效应，说的都是一个小因素的变化，却往往有着无比强大的力量，以至于最后改变整体结构、产生意想不到的结果。现在，把这个原理适用于商业和技术领域，它同样能得到类似的效果—商业和技术本身具有一定的结构和体系，当人们适当地拆散其结构，并予以重新组合，便能释放出犹如雪崩般巨大的能量。雪崩把旧有的产业体系打得粉碎，甚至，有时候干脆让整个产业消失。在雪崩的巨大压力下，商业与技术之间固有的联系被彻底中断，不得不接受新的改造和整合，其最终将引爆一系列创新的革命，这就是“雪崩效应”。 以上来自百度百科。 从上面可以看到，造成雪崩效应很可能就是因为一个特别小的原因，比如一个石子。然后让我们在看一下下图： 图中每个字母代表了一个微服务，剪头代表服务的调用。 假设1：

缓存问题 1 缓存穿透 缓存只是为了缓解数据库压力而添加的一层保护层，当从缓存中查询不到我们需要的数据就要去数据库中查询了。如果被黑客利用，频繁去访问缓存中没有的数据，那么缓存就失去了存在的意义，瞬间所有请求的压力都落在了数据库上，这样会导致数据库连接异常。 解决方案： 约定:对于返回为NULL的依然缓存，对于抛出异常的返回不进行缓存,注意不要把抛异常的也给缓存了。采用这种手段的会增加我们缓存的维护成本，需要在插入缓存的时候删除这个空缓存，当然我们可以通过设置较短的超时时间来解决这个问题。 制定一些规则过滤一些不可能存在的数据，小数据用BitMap，大数据可以用布隆过滤器，比如你的订单ID 明显是在一个范围1-1000，如果不是1-1000之内的数据那其实可以直接给过滤掉。 2 缓存雪崩 缓存雪崩是指缓存不可用或者大量缓存由于超时时间相同在同一时间段失效，大量请求直接访问数据库，数据库压力过大导致系统雪崩。 解决方案： 1、给缓存加上一定区间内的随机生效时间，不同的key设置不同的失效时间，避免同一时间集体失效。比如以前是设置10分钟的超时时间，那每个Key都可以随机8-13分钟过期，尽量让不同Key的过期时间不同。 2、采用多级缓存，不同级别缓存设置的超时时间不同，及时某个级别缓存都过期，也有其他级别缓存兜底。 3、利用加锁或者队列方式避免过多请求同时对服务器进行读写操作。 来源