-
缓存穿透
-
什么是缓存穿透？
客户端大量集中恶意访问一些不存在的数据，例如访问id=-1的数据，这样在缓存层就无法查询到该数据，直接击穿缓冲层，到达数据库端，导致数据库压力过大，最终停止服务。
-
解决方案
在代码层面做判断限制非法数据的请求；
使用布隆过滤器，记录key是否存在，不存在则直接返回，使请求不达到数据层面；
-
-
缓存击穿
-
什么是缓存击穿？
缓存击穿是指因并发原因，大量数据请求同一个key值，而该key值刚好过期，导致所有请求都去数据库层面获取数据，最终导致数据库停止服务。
-
解决方案
在代码层面使用并发锁，如果某个key无法获取，则先获取锁，再去数据库层获取数据，回写到缓存层，其他并发请求，如果没有获取到锁，则等待一段时间后再尝试去缓存层获取数据；
将数据设置为一个合理的过期时间，例如永不过期，或并发量低时过期；
-
-
缓存雪崩
-
什么是缓存雪崩？
缓存雪崩是指，大量缓存数据集中过期，导致数据库层的压力过大。与缓存击穿的区别是，缓存击穿是单个key值的过期，同时大量并发请求，而缓存雪崩是大量key值集中过期，同时访问量较大。
-
解决方案
合理设置过期时间，避免同一时刻缓存数据过期；
使用数据库分布式部署，降低单节点数据库读压力过大；
合理选择热点数据，并设置为永不过期；
-
-
如何保证无锁的原子操作
-
将多个操作在Redis中实现成一个操作，例如读取数据、数据增减、写回数据，使用INCRE/DECRE命令操作；
-
将多个操作写在一个Lua脚本中，Redis回将Lua脚本当作一个整体执行，不会被其他命令打断。Lua脚本进来些成复用度高的脚本，并通过Script load命令先把脚本在Redis中加载，避免每次都要将脚本从客户端发送到服务端，减少网络IO的开销；
-
-
分布式锁
使用redis实现分布式锁，需要把获取锁，设置过期时间作为一个原子操作执行，可使用上面介绍的Lua脚本执行，释放锁应只能由获取锁的客户端才能释放，避免别的客户端释放锁。多节点高可用分布式锁采用redlock算法实现分布式锁，java的Redisson就是基于redlock实现的分布式锁。redlock算法流程是
a. 客户端获取当前时间；
b. 客户端顺序依次向N个redis实例执行加锁操作；
c. 判断加锁是否成功，需要满足俩个条件，1是客户端超过半数的redis实例上成功加锁，2是客户端获取锁的总耗时没有超过锁的有效时间；
基于redis实现的分布式锁不是完全可靠的，可能出现死锁获取多个客户端同时获取锁的情况，例如以下情景：
1、SETNX 执行成功，执行 EXPIRE 时由于网络问题设置过期失败
2、SETNX 执行成功，此时 Redis 实例宕机，EXPIRE 没有机会执行
3、SETNX 执行成功，客户端异常崩溃，EXPIRE 没有机会执行
在这个场景中，由于没有设置过期时间，那么如果客户端崩溃，没有释放锁，其他客户端就无法再获取到锁。分布式锁的实现方案对比如下：
方案 优点 缺点 适用场景 基于数据库锁的方式 简单，方便，可靠性高 性能低，并发程度低 小并发量的场景 基于单节点redis实现 性能最优，有比较成熟的客户端框架及方案实现，例如jedis 1. 可靠性不太高，会出现死锁的情况；2. 无法实现公平锁；3. 需客户端轮询获取锁，成本大 高并发，允许部分锁异常的场景 基于多节点的redis实现 解决了redis单节点失效导致不可用的情况 脑裂、客户端阻塞等一场都可能导致锁的异常问题，可靠性不太高 高并发，高可用，允许部分锁异常的场景 基于etcd 1.性能较好，支持并发度高；2.能实现公平锁；3.通过回调通知客户端获取锁，不需要轮询；4.可靠性高，基于raft分布式算法实现 没有现成的集成框架，需要自研 高并发、高可用场景 基于zookeeper实现 1能实现公平锁；2.通过回调通知客户端获取锁，不需要轮询；3.可靠性高 性能较etcd和redis较低 并发量不太大，锁的可靠性要求高