【缓存雪崩】
对于一个系统，假设每天高峰期每秒 6000 个请求，那么高峰的时候系统能够抗住5000+的请求。
但是如果Redis宕机发生意外，所有的请求都不走缓存，而直接访问MySQL数据库，这样子就会导致高峰时有5000+哥请求直接请求数据库，直接把数据库拖垮。即使把数据库重启了，也会立即被并发请求再次挂掉。因此这个现象就是Redis的雪崩。
缓存雪崩的事前事中事后的解决方案如下
1. 事前：redis 配置高可用，主从+哨兵，使用 redis cluster 提高集群的可靠用
2. 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死
3. 事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据

当用户发送一个请求访问资源，先访问redis，如果没有数据再搜数据库，然后把结果放一份到redis。
当下一次请求的时候就可以直接从缓存离去数据了
限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，可以返回一些默认的值，或者友情提示，或者空白的值。
好处：
数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来一次

【缓存穿透】
对于系统，假设一秒 6000 个请求，结果其中 5000+ 个请求是黑客发出的恶意攻击。
黑客发出的那 5000 个攻击，缓存中查不到，每次你去数据库里查，也查不到
例如据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数
这样的话，缓存中不会有，请求每次都“视缓存于无物”，直接查询数据库，这种恶意攻击场景的缓存穿透就会直接把数据库给打死
解决方式很简单，每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN。然后设置一个过期时间，这样的话，下次有相同的key来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。

【缓存雪崩】
对于一个系统，假设每天高峰期每秒 6000 个请求，那么高峰的时候系统能够抗住5000+的请求。
但是如果Redis宕机发生意外，所有的请求都不走缓存，而直接访问MySQL数据库，这样子就会导致高峰时有5000+哥请求直接请求数据库，直接把数据库拖垮。即使把数据库重启了，也会立即被并发请求再次挂掉。因此这个现象就是Redis的雪崩。
缓存雪崩的事前事中事后的解决方案如下
1. 事前：redis 配置高可用，主从+哨兵，使用 redis cluster 提高集群的可靠用
2. 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死
3. 事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据

当用户发送一个请求访问资源，先访问redis，如果没有数据再搜数据库，然后把结果放一份到redis。
当下一次请求的时候就可以直接从缓存离去数据了
限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，可以返回一些默认的值，或者友情提示，或者空白的值。
好处：
数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来一次

【缓存穿透】
对于系统，假设一秒 6000 个请求，结果其中 5000+ 个请求是黑客发出的恶意攻击。
黑客发出的那 5000 个攻击，缓存中查不到，每次你去数据库里查，也查不到
例如据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数
这样的话，缓存中不会有，请求每次都“视缓存于无物”，直接查询数据库，这种恶意攻击场景的缓存穿透就会直接把数据库给打死
解决方式很简单，每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN。然后设置一个过期时间，这样的话，下次有相同的key来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。