一、缓存预热
缓存预热就是系统启动前，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题。用户直接查询事先被预热的缓存数据。
现象：“宕机”，服务器启动后迅速宕机
问题排查：请求数量较高；主从之间数据吞吐量较大，数据同步操作频度较高
二、缓存雪崩
什么是缓存雪崩：缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉
解决办法：
事前：尽量保证整个redis集群的高可用性，发现机器宕机尽快补上。选择合适的内存淘汰策略。
事中：本地ehcache缓存+hystrix限流&降级，避免MySQL崩掉
事后：利用redis持久化机制保存的数据尽快恢复缓存
现象:数据库服务器崩溃
问题排查：
解决方案:
总结:
缓存雪崩就是瞬间过期数据量太大，导致对数据库服务器造成压力。如能够有效避免过期时间集中，可以有效解决雪崩现象的出现（约40%），配合其他策略一起使用，并监控服务器的运行数据，根据运行记录做快速调整。
三、缓存击穿
缓存击穿就是单个高热数据过期的瞬间，数据访问量较大，未命中redis后，发起了大量对同一数据的数据库访问，导致对数据库服务器造成压力。应对策略应该在业务数据分析与预防方面进行，配合运行监控测试与及时调整策略，毕竟单个key的过期监控难度较高，配合雪崩处理策略即可。
四、缓存穿透
缓存穿透说简单点就是大量请求的key根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。
用户查询数据，在数据库没有，在缓存中也没有。这就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空，相当于进行了两次无用的查询。
一般MySQL默认的最大连接数在150左右，这个可以通过show variables like ‘%max_connections%’;命令来查看。
解决办法：
最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库id不能小于0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等
1）缓存无效key：如果缓存和数据库都查不到某个key的数据就写一个到redis中去并设置过期时间，具体命令如下：SET key value EX 10086。这种方式可以解决请求的key变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求key，会导致redis中缓存大量无效的key。
2）布隆过滤器：布隆过滤器可以非常方便地判断一个给定数据是否存在于海量数据中。判断key是否合法。
把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，会先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程
总结：
缓存击穿访问了不存在的数据，跳过了合法数据的redis数据缓存阶段，每次访问数据库，导致对数据库服务器造成压力。通常此类数据的出现量是一个较低的值，当出现此类情况以毒攻毒，并及时报警
五、缓存更新
缓存更新除了缓存服务器自带的缓存失效策略之外，还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有：
定时去清理过期的缓存
当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存
六、缓存降级
当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）
七、性能指标监控
监控指标
性能指标：Performance
内存指标：Memory
基本活动指标：Basic activity
持久性指标：Persistence
错误指标：Error
