redis教程

redis

redis缓存雪崩

就是说用户访问某东，这个时候 redis 里面的 key 大量失效，导致这个某东直接访问数据库，把大量的请求都打到来数据库，这种现象就是缓存雪崩。简单来说就是 redis 缓存在同一时间大量失效，就像这个雪崩来了一样。

那么缓存雪崩它的解决方案有几种呢？下面来说下：

• 设置这个缓存的失效时间，不让大量的 key 在同一时间失效，即在设置这个缓存的时候，可以将 key 的失效时间分散开。

• 我们部署 redis 一般是集群部署的，可以把这些热点的 key 放到不同的节点上去，让这些热点的 key 均匀的分布在不同的 redis 节点上。

• 还有就是比较暴力的方法，不设置这个缓存失效的时间，让 key 永不失效。

redis缓存穿透

首先这个恶意用户访问某东，用 id=-1 的数据去请求，然后这个 id=-1 的数据在 redis 缓存里面没有查到，就到数据库里面查询，也没有查到该条数据，只能返回空数据给前端了。

这个恶意用户(黑客)用脚本不断的发这个数据去请求，直接穿透 redis 打到这个数据库上，这就是所谓的缓存穿透。 简单来说，缓存穿透就是指缓存和数据库中都没有这样的数据，一般出现这种情况都不是正常的用户在访问。

那么缓存穿透的解决方案有以下几点：

• 请求如果穿透 redis，直接到数据库，那么数据库无论查出什么结果，都写回到 redis 缓存里面去，这样下次用同一个参数发来请求的时候，就直接被 redis 缓存拦截掉了，就不回打到数据库了。

• 对请求的参数做合法性校验。

• 比较直接、简单粗暴的方法，把这个 IP 拉黑。

• 最后是使用布隆过滤器，这是一个非常好的方式。

redis缓存击穿

用户访问某东，然后去 redis 请求某个拍卖秒杀商品，在缓存没有失效的时候，redis 可以把这个查询到的缓存 key 的结果返回回去，但是当这个缓存的 key 失效了，这个请求就会击穿这个 redis，直接打到数据库上。

这里大家注意的是，这里是某一个热点的 key，大量的用户请求不断的访问这个热点的 key，当这个热点的 key 突然失效，把请求都打到数据库上，这个过程就是叫做缓存击穿了。记住它是击穿某个一个非常热点的 key。

那么这个缓存击穿的解决方案是：

• 让这个热点 key 不过期，即不设置失效时间(不推荐)。

• 使用分布式锁，如果是单体应用的话使用互斥锁

redis总结

缓存雪崩：是指大量的缓存 key，在同一时间大量的失效。

缓存穿透：是指 redis 里没有请求想要的数据，直接穿过 redis 到数据库了。

缓存击穿：是指某个一个非常热点的 key，大量的用户去请求这个缓存热点 key，当这个缓存 key 突然失效的时候，这些请求都会打到数据库上。

分布式锁三种实现方式：

1. 基于数据库实现分布式锁；2. 基于缓存（Redis等）实现分布式锁；3. 基于Zookeeper实现分布式锁；

基于数据库实现分布式锁；

数据库实现的话，总体可以分为悲观锁跟乐观锁

悲观锁是指的可以使用 select … for update 来实现分布式锁。就是先 select … for update 锁住主键 key_resource 那个记录，如果为空，则可以插入一条记录，如果已有记录判断下状态和时间，是否已经超时。这里需要注意一下哈，必须要加事务。

除了悲观锁，还可以用乐观锁实现分布式锁。乐观锁，顾名思义，就是很乐观，每次更新操作，都觉得不会存在并发冲突，只有更新失败后，才重试。它是基于 CAS 思想实现的。

搞个 version 字段，每次更新修改，都会自增加一，然后去更新余额时，把查出来的那个版本号，带上条件去更新，如果是上次那个版本号，就更新，如果不是，表示别人并发修改过了，就继续重试。

这种方式适合并发不高的场景，一般需要设置一下重试的次数。

| 数据库分布式锁实现

优点：简单，使用方便，不需要引入 Redis、Zookeeper 等中间件。

缺点：

• 不适合高并发的场景

• db 操作性能较差

| Redis 分布式锁实现

优点：

• 性能好，适合高并发场景

• 较轻量级

• 有较好的框架支持，如 Redisson

缺点：

• 过期时间不好控制

• 需要考虑锁被别的线程误删场景

| Zookeeper 分布式锁实现

缺点：

• 性能不如 Redis 实现的分布式锁

• 比较重的分布式锁。

优点：

• 有较好的性能和可靠性

• 有封装较好的框架，如 Curator

| 对比汇总

如下：

• 从性能角度（从高到低）Redis > Zookeeper >= 数据库

• 从理解的难易程度角度（从低到高）数据库 > Redis > Zookeeper

• 从实现的复杂性角度（从低到高）Zookeeper > Redis > 数据库

• 从可靠性角度（从高到低）Zookeeper > Redis > 数据库