redis 学习笔记

一、Redis 概述

1、Redis 简介

• Redis 是一个开源的 key-value 存储系统。
• 和 Memcached 类似，它支持存储的 value 类型相对更多，包括 string (字符串)、list (链表)、set (集合)、zset (sorted set –有序集合) 和 hash（哈希类型）。
• 这些数据类型都支持 push/pop、add/remove 及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。
• 在此基础上，Redis 支持各种不同方式的排序。
• 与 memcached 一样，为了保证效率，数据都是缓存在内存中。区别是 Redis 会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了 master-slave (主从) 同步。
• redis 总共有16个库（索引为 0-15），连接 redis 后，默认使用的是 0 号库。

2、应用场景

2.1 配合关系型数据库做高速缓存

• 高频次，热门访问的数据，降低数据库 IO。
• 分布式架构，做 session 共享。
  

2.2 多样的数据结构存储持久化数据

二、Redis 数据类型

1、Redis 键(key)

keys * # 查看当前库中的所有 key

set k1 v1 # 往库中存放或修改 key-value(仅适用于单个 value 的情况)
set k2 v2

get k1 # 获取指定 key 的 value(仅适用于单个 value 的情况)

exists k1 # 判断某个 key 是否存在，1表示存在，0表示不存在

type k1 # 查看 key 的类型

# 删除 key（两种方式）
del k1 # 直接删除 key-value，返回1表示删除成功，返回0表示当前 key 不存在
unlink k1 # 仅将 key 从 keyspace 元数据中删除，真正的删除会在后续异步操作

# 给 key 设置过期时间
expire k2 10 # 设置过期时间10s

# 查看指定 key 还有多少秒过期
ttl k2 # -1表示永不过期，-2表示已经过期

其它命令：

# 查看当前库中的 key-value 的数量
dbsize
# 切换数据库
select 1
# 清空当前库（慎用）
flushdb
# 通杀全部库（慎用）
flushall

2、Redis 字符串(String)

2.1 简介

• String 是 Redis 中最基本的类型，一个 key 对应一个 value。
• String 类型是二进制安全的，意味着 Redis 的 string 可以包含任何数据，比如 jpg 图片或者序列化的对象。
• 一个 Redis 字符串 value 最多是512M。

2.2 数据结构

String 的数据结构为简单动态字符串 (Simple Dynamic String, 缩写 SDS)，是可以修改的字符串，内部结构实现上类似于 Java 的 ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配。

如图所示，内部为当前字符串实际分配的空间 capacity 一般要高于实际字符串长度 len。当字符串长度小于 1M 时，扩容都是加倍现有的空间，如果超过 1M，扩容时一次只会多扩 1M 的空间。

2.3 操作命令

append k1 v00 # 将 v00 追加到 k1 对应 value 后面，返回值是新的 value 的长度
strlen k1 # 获取 key 对应 value 的长度
setnx k3 v3 # 只有当 key 不存在时，才能设置成功

set k4 100 # 设置一个数值型 value
incr k4 # 给 k4 对应的 value 加 1
decr k4 # 给 k4 对应的 value 减 1
incrby k4 5 # 给 k4 对应的 value 加 5
decrby k4 3 # 给 k4 对应的 value 减 3

mset k5 v5 k6 v6 # 同时设置多个 key-value
mget k1 k2 k3 # 同时获取多个 key 对应的 value
msetnx k7 v7 k8 v8 # 同时设置多个 key-value，当且仅当所有的 key 都不存在时设置成功，一个失败则全部失败

set name jack
getrange name 0 2 # jac，获取 key 对应 value 的指定范围值
setrange name 1 hhh # jhhh，从指定索引处开始覆盖 key 对应的 value
getset name aaa # aaa，获取 key 的旧值的同时设置新值

setex age 20 v18 # 设置 key-value 的同时设置过期时间，age-v18 的过期时间为20s

Redis 的 加/减 操作都是原子性的，指不会被线程调度打断，因为 Redis 是 单线程+多路IO复用。
多路复用是指使用一个线程来检查多个文件描述符（Socket）的就绪状态，比如调用 select 和 poll 函数，传入多个文件描述符，如果有一个文件描述符就绪，则返回，否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行，也可以启动线程执行（比如使用线程池）。

3、Redis 列表(List)

3.1 简介

单键多值：Redis 列表是简单的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或者尾部（右边）。它的底层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差。

3.2 数据结构

• 在列表元素较少的情况下会使用一块连续的内存存储，这个结构是 ziplist(压缩列表)。它将所有的元素紧挨着一起存储，分配的是一块连续的内存。
• 当数据量比较多的时候会改成 quicklist(快速链表)。因为普通的链表需要的附加指针空间太大，会比较浪费空间。
  
• Redis 将链表和 ziplist 结合起来组成了 quicklist。也就是将多个 ziplist 使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。

3.3 操作命令

lpush k1 v11 v12 v13 # 从左边插入多个值，内部的实际存储状态是 k1 : [v13, v12, v11]
lpush k2 v21 v22 v23 # 从右边插入多个值，内部的实际存储状态是 k2 : [v21, v22, v23]

lrange k1 0 -1 # 从左边开始获取 k1 指定索引范围内的值，-1表示最后一个

# 值在键在，值无键无，即一个 key 对应的 value 都弹出了以后，这个 key 也就不存在了
lpop k1 2 # 从左边开始弹出 k1 的2个 value，弹出数量可不写，默认为1
rpop k2 3 # 从右边开始弹出 k2 的3个 value

rpoplpush k1 k2 # 从 k1 的右边取出一个值插入 k2 的值的左边

lindex k2 1 # 从左边获取 k2 的第1个索引处的值
llen k2 # 获取 k2 对应列表的长度

linsert k2 before v21 newv21 # 在 k2 对应列表中的 v21 前面插入 newv21
linsert k2 after v22 newv22 # 在 k2 对应列表中的 v22 后面插入 newv22

lrem k2 2 newv21 # 从左边删除两个 k2 对应列表中的 newv21，如果只有1个 newv21，则只删除1个
lset k2 2 v00 # 将 k2 对应列表中的第2个索引(从左往右)处的值替换为 v00

4、Redis 集合(Set)

4.1 简介

• Redis 的 Set 对外提供的功能与 List 类似，特殊之处在于 Set 可以自动去重。
• Redis 的 Set 是 string 类型的无序集合。它底层其实是一个 value 为 null 的 hash 表，所以添加、删除、查找的复杂度都是 O(1)。
• Java 中 HashSet 的内部实现使用的是 HashMap，只不过所有的 value 都指向同一个对象。Redis 的 set 结构也是一样，它的内部也使用 hash 结构，所有的 value 都指向同一个内部值。

4.2 操作命令

sadd k1 v11 v12 v11 # 给 k1 添加 v11,v12 两个值，自动去重
smembers k1 # 查看 k1 的所有值
sismember k1 v11 # 判断 v11 是不是 k1 的值，1表示是，0表示不是
scard k1 # 查看 k1 的值的数量
srem k1 v11 v13 # 从 k1 对应的集合中删除 v11,v13 两个值，没有 v13，所以只删除了 v11
spop k1 2 # 从 k1 对应的集合中随机弹出2个值
srandmember k1 2 # 从 k1 对应的集合中随机获取2个值
smove k1 k2 v12 # 把 k1 对应集合中的 v12 移入 k2 对应的集合中
sinter k1 k2 # 返回 k1 和 k2 的交集
sunion k1 k2 # 返回 k1 和 k2 的并集
sdiff k1 k2 # 返回 k1 减 k2 的差集，即属于 k1 但不属于 k2

5、Redis 哈希(Hash)

5.1 简介

• Redis hash 是一个键值对集合。
• Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。
• 存储对象的三种方式：
  方式1：每次修改用户的某个属性需要，先反序列化改好后再序列化回去。开销较大。
  
  方式2：用户数据的存储过于分散，且用户 ID 数据冗余。
  
  方式3：通过 key (用户 ID) + field (属性标签) 就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。(Redis 采用的是方式3)

5.2 数据结构

Hash 类型对应的数据结构是两种：ziplist（压缩列表），hashtable（哈希表）。当 field-value 长度较短且个数较少时，使用 ziplist，否则使用 hashtable。

5.3 操作命令

hset user01 id 1 name Tom # 把 user01 作为 key，将其id设为1，name设为Tom(id和name 都是 field)
hget user01 id # 获取单个 field 的值
hmget user01 id name # 获取多个 field 的值
hexists user01 id # 判断 user01 是否有 id 这个 field
hkeys user01 # 列出 user01 的所有 field
hvals user01 # 列车 user01 的所有 value
hincrby user01 id 2 # 给 user01 的 id 值加2(只有 integer 类型的值才可以)
hsetnx user01 id 5 age 20  # 当 user01 的 id和age 都不存在时，才能设置成功

6、Redis 有序集合(Zset)

6.1 简介

• Zset 的每个成员都关联了一个评分(score)，这个评分被用来按照由低到高的方式对集合中的成员进行排序。
• 集合的成员是唯一的，但评分可以是重复的。

6.2 数据结构

Zset 底层使用了两种数据结构：

• Hash：作用是建立元素 value 和其权重 score 的映射关系，保障元素 value 的唯一性，可以通过元素 value 找到相应的 score 值。
• 跳跃表：跳跃表的目的在于给元素 value 排序，根据 score 的范围获取元素列表。

6.3 跳跃表

6.3.1 简介

有序集合在生活中比较常见，例如根据成绩对学生排名，根据得分对玩家排名等。对于有序集合的底层实现，可以用数组、平衡树、链表等。数组不便元素的插入、删除；平衡树或红黑树虽然效率高但结构复杂；链表查询需要遍历所有效率低。Redis 采用的是跳跃表，跳跃表效率堪比红黑树，实现远比红黑树简单。

6.3.2实例

对比有序链表和跳跃表，从链表中查询出 51：
① 有序链表：
要查找值为 51 的元素，需要从第一个元素开始依次查找、比较才能找到。共需要 6 次比较。
② 跳跃表：

• 从第 2 层开始，1 节点比 51 节点小，向后比较；
• 21 节点比 51 节点小，继续向后比较，后面就是 NULL 了，所以从 21 节点向下到第 1 层；
• 在第 1 层，41 节点比 51 节点小，继续向后，61 节点比 51 节点大，所以从 41 向下；
• 在第 0 层，51 节点为要查找的节点，节点被找到，共查找 4 次。
  由此可以看出跳跃表比有序链表效率要高。

6.3 操作命令

zadd topn 100 java 200 python 300 js # 将多个 member 元素及其 score 值加入到有序集合 topn 中

zrange topn 0 -1 # 返回有序集合 topn 中指定索引范围内的元素
zrange topn 0 -1 withscores # 返回有序集合 topn 中指定索引范围内的元素及其 score 值

zrangebyscore topn 100 200 # 返回有序集合 topn 中指定分数范围内的元素(由小到大)
zrangebyscore topn 100 200 withscores # 返回有序集合 topn 中指定分数范围内的元素及其 score 值

zrevrangebyscore topn 300 200 # 返回有序集合 topn 中指定分数范围内的元素(由大到小)
zrevrangebyscore topn 300 200 withscores # 返回有序集合 topn 中指定分数范围内的元素及其 score 值

zincrby topn 50 java # 给有序集合 topn 中的 java 的 score 值加50
zrem topn js python # 删除有序集合 topn 中的指定元素
zcount topn 100 300 # 统计有序集合 topn 中指定分数区间的元素个数
zrank topn java # 返回 java 在有序集合 topn 中的排名(由小到大，从0开始)

三、Redis6 的发布和订阅

1、什么是发布和订阅？

Redis 发布订阅(pub/sub)是一种消息通信模式：发布者(pub)发送消息，订阅者(sub)接收消息，二者均是通过频道(channel)来进行消息通信的。一个 Redis 客户端可以订阅多个频道。

2、实例演示

客户端1：充当订阅者

subscribe ch1 # 订阅频道 ch1

客户端2：充当发布者

public ch1 hello # 通过频道 ch1 发布消息 hello，返回订阅频道 ch1 的订阅者的数量

客户端1接收到客户端2发来的消息：

四、Redis 新数据类型

1、Bitmaps

1.1 简介

• Bitmaps 本身不是一种数据类型， 实际上它就是字符串(key-value)， 但是它可以对字符串的位进行操作。
• Bitmaps 单独提供了一套命令， 所以在 Redis 中使用 Bitmaps 和使用字符串的方法不太相同。 可以把 Bitmaps 想象成一个以位为单位的数组， 数组的每个单元只能存储 0 和 1， 数组的下标在 Bitmaps 中叫做偏移量。

1.2 Bitmaps VS Set

假设网站有 1 亿用户， 每天独立访问的用户有 5 千万， 如果每天用集合类型和 Bitmaps 分别存储活跃用户可以得到表：

set 和 Bitmaps 存储一天活跃用户对比
数据类型	每个用户 id 占用空间	需要存储的用户量	全部内存量
Set	64 位	50000000	64 位 * 50000000 = 400MB
Bitmaps	1位	100000000	1 位 * 100000000 = 12.5MB

很明显， 这种情况下使用 Bitmaps 能节省很多的内存空间， 尤其是随着时间推移节省的内存还是非常可观的。

set 和 Bitmaps 存储独立用户空间对比
数据类型	一天	一月	一年
Set	400 MB	12GB	144GB
Bitmaps	12.5MB	375MB	4.5GB

但 Bitmaps 并不是万金油， 假如该网站每天的独立访问用户很少， 例如只有 10 万（大量的僵尸用户） ， 那么两者的对比如下表所示， 很显然， 这时候使用 Bitmaps 就不太合适了， 因为基本上大部分位都是 0。

set 和 Bitmaps 存储一天活跃用户对比(用户较少)
数据类型	每个用户 id 占用空间	需要存储的用户量	全部内存量
Set	64 位	100000	64 位 * 100000 = 800KB
Bitmaps	1位	100000000	1 位 * 100000000 = 12.5MB

1.3 操作命令

# setbit <key> <offset> <value>
setbit users 5 1 # 设置 users 的第 5 个偏移量的值为 1

# getbit <key> <offset>
getbit users 5 # 获取 users 的第 5 个偏移量的值

# bitcount <key> [<start> <stop>]
bitcount users # 统计 users 中值为1的偏移量的个数
bitcount users 0 2 # 统计 users 的前3个字节中值为1的偏移量的个数

# bitop and <destkey> <key1> <key2>
bitop and u3 u1 u2 # 将 u1 和 u2 按位与的结果赋值给 u3
# bitop or <destkey> <key1> <key2>
bitop or u4 u1 u2 # 将 u1 和 u2 按位或的结果赋值给 u4

2、HyperLogLog

2.1 简介

在工作当中，我们经常会遇到与统计相关的功能需求，比如统计网站 PV（PageView 页面访问量），可以使用 Redis 的 incr、incrby 轻松实现。但像 UV（UniqueVisitor 独立访客）、独立 IP 数、搜索记录数等需要去重和计数的问题如何解决？这种求集合中不重复元素个数的问题称为基数问题。

解决基数问题有很多种方案：

1. 数据存储在 MySQL 表中，使用 distinct count 计算不重复个数。
2. 使用 Redis 提供的 hash、set、bitmaps 等数据结构来处理。

以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。能否能够降低一定的精度来平衡存储空间？Redis 推出了 HyperLogLog。

• Redis HyperLogLog 是用来做基数统计的，HyperLogLog 的优点是：在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。
• 在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。
• 但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

什么是基数：基数是指一个集合中不同元素的个数。比如数据集 {1, 3, 5, 7, 5, 7, 8}，那么这个数据集的基数集为 {1, 3, 5 ,7, 8}，基数 为 5。 基数估计就是在误差可接受的范围内，快速计算基数。

2.2 操作命令

pfadd k1 1 3 5 7 5 7 8 # 添加元素到 k1 中
pfcount k1 # 统计 k1 的基数
pfmerge k3 k1 k2 # 将 k1 和 k2 合并到 k3

3、Geospatial

3.1 简介

Redis 3.2 中增加了对 GEO 类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的 2 维坐标，在地图上就是经纬度。redis 基于该类型，提供了经纬度设置、查询、范围查询、距离查询、经纬度Hash 等常见操作。

3.2 操作命令

geoadd china:city 121.47 31.23 shanghai 116.38 39.90 beijing # 添加上海和北京的经纬度坐标
geopos china:city beijing # 获取北京的经纬度坐标
geodist china:city beijing shanghai km # 获取北京和上海的直线距离(单位可选：m、km、ft、mi，默认是 m)
georadius china:city 120 30 1000 km # 取出 china:city 中在东经120、北纬30坐标方圆1000km之内的元素

五、springboot 整合 redis

1、新建一个 maven 工程

通过 Spring Initializr 进行创建：

依赖选择：Spring Web 和 Spring Data Redis。

2、填写配置文件

host: 主机的 ip
port: redis服务的端口号，默认是 6379

3、设置 RedisTemplate 的序列化方法

RedisTemplate 默认使用的是 jdk 的序列化组件，如果不进行设置，存入 redis 中的 key 前面会出现类似 \xac\xed\x00\x05t\x00 这样的字符串 。
解决方法：添加一个 redis 配置类，具体代码如下。

@Configuration
public class RedisConfig {
    @Bean
    public RedisTemplate<String,String> redisTemplate(RedisConnectionFactory connectionFactory){
        RedisTemplate<String,String> redisTemplate = new RedisTemplate<>();
        redisTemplate.setConnectionFactory(connectionFactory);
        //字符串序列化方法
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        redisTemplate.setValueSerializer(new StringRedisSerializer());
        redisTemplate.afterPropertiesSet();
        return redisTemplate;
    }
}

六、Redis 事务

1、简介

• Redis 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• Redis 事务的主要作用就是串联多个命令防止别的命令插队。

2、事务指令

• multi：开启事务。输入该指令后，接下来的所有命令都会放入一个命令队列中，不会执行。
• exec：执行命令。输入该指令后，会依次执行命令队列中的命令，执行完毕自动关闭事务。
• discard：取消命令。输入该指令后，命令队列中的命令会全部取消，并且自动关闭事务。
  
  

3、事务的错误处理

3.1 组队阶段出错

如果在组队阶段某个命令出错了，则执行时整个队列的命令都会被取消。

3.2 执行阶段出错

如果在执行阶段某个命令出错了，则只有报错的命令不执行，其他的命令都会执行。

4、事务冲突

如图：加入初始金额是10000，如果三个事务同时发出请求，那么最终会出现金额为负的情况，这就是事务冲突。

4.1 悲观锁 和 乐观锁（用于解决事务冲突）

4.1.1 概念

• 悲观锁：每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 block 直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
• 乐观锁：每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis 就是利用这种 check-and-set 机制实现事务的。

4.1.2 实例演示

redis 中使用 watch 命令监视某个 key 对应的 value 是否更改。

set balance 100 # 让两个客户端都监视 balance

左边的事务先执行，右边的事务被打断。

redis 中使用 unwatch 取消 watch 命令对所有 key 的监视。如果在执行 watch 命令之后，exec 或 discard 先被执行了的话，那么就不需要再执行 unwatch 了。

4.2 Redis 事务的三大特性

• 单独的隔离操作 ：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 没有隔离级别的概念 ：队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。
• 不保证原子性 ：事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚 。

4.3 Redis 事务秒杀案例

例子：多个人同时秒杀一件商品。

秒杀代码：

public class SecKill_redis {

	//秒杀过程
	public static boolean doSecKill(String uid,String prodid) throws IOException {
		//1 uid和prodid非空判断
		if(uid == null || prodid == null) {
			return false;
		}

		//2 连接redis
		Jedis jedis = new Jedis("172.22.109.205",6379);

		//3 拼接key
		// 3.1 库存key
		String kcKey = "sk:"+prodid+":qt";
		// 3.2 秒杀成功用户key
		String userKey = "sk:"+prodid+":user";

		//4 获取库存，如果库存null，秒杀还没有开始
		String kc = jedis.get(kcKey);
		if(kc == null) {
			System.out.println("秒杀还没有开始，请等待");
			jedis.close();
			return false;
		}

		// 5 判断用户是否重复秒杀操作
		if(jedis.sismember(userKey, uid)) {
			System.out.println("已经秒杀成功了，不能重复秒杀");
			jedis.close();
			return false;
		}
		
		//6 判断如果商品数量，库存数量小于1，秒杀结束
		if(Integer.parseInt(kc)<=0) {
			System.out.println("秒杀已经结束了");
			jedis.close();
			return false;
		}

		//7.1 库存-1
		jedis.decr(kcKey);
		//7.2 把秒杀成功用户添加清单里面
		jedis.sadd(userKey,uid);

		System.out.println("秒杀成功了..");
		jedis.close();
		return true;
	}
}

4.3.1 超卖问题 和 连接超时问题

上述代码，在高并发情况下，会出现 超卖问题(即库存数量为负) 和 连接超时问题。

• 解决超卖问题：事务+乐观锁

	//监视库存
	jedis.watch(kcKey);
	
	//4 获取库存，如果库存null，秒杀还没有开始
	.
	.
	.

	//7 秒杀过程，使用事务
	Transaction multi = jedis.multi();
	//组队
	multi.decr(kcKey);
	multi.sadd(userKey,uid);
	//执行
	List<Object> results = multi.exec();
	
	if(results == null || results.size()==0) {
		System.out.println("秒杀失败了....");
		jedis.close();
		return false;
	}

• 解决连接超时问题：使用连接池获取 Jedis 对象
  ① 创建连接池工具类：

public class JedisPoolUtil {
	private static volatile JedisPool jedisPool = null;

	private JedisPoolUtil() {
	}

	public static JedisPool getJedisPoolInstance() {
		if (null == jedisPool) {
			synchronized (JedisPoolUtil.class) {
				if (null == jedisPool) {
					JedisPoolConfig poolConfig = new JedisPoolConfig();
					poolConfig.setMaxTotal(200); //控制一个pool可分配多少个jedis实例，通过pool.getResource()来获取；如果赋值为-1，则表示不限制；如果pool已经分配了MaxTotal个jedis实例，则此时pool的状态为exhausted。
					poolConfig.setMaxIdle(32); //控制一个pool最多有多少个状态为idle(空闲)的jedis实例；
					poolConfig.setMaxWaitMillis(100*1000); //表示当borrow一个jedis实例时，最大的等待毫秒数，如果超过等待时间，则直接抛JedisConnectionException；
					poolConfig.setBlockWhenExhausted(true); //获得一个jedis实例的时候是否检查连接可用性（ping()）；如果为true，则得到的jedis实例均是可用的；
					poolConfig.setTestOnBorrow(true);  // ping  PONG，判断是否还存在
				 
					jedisPool = new JedisPool(poolConfig, "172.22.109.205", 6379, 60000 );
				}
			}
		}
		return jedisPool;
	}

	public static void release(JedisPool jedisPool, Jedis jedis) {
		if (null != jedis) {
			jedisPool.returnResource(jedis);
		}
	}
}

② 通过连接池工具类获取 Jedis 对象：

//2 连接redis
//Jedis jedis = new Jedis("192.168.44.168",6379);
//通过连接池得到jedis对象
JedisPool jedisPoolInstance = JedisPoolUtil.getJedisPoolInstance();
Jedis jedis = jedisPoolInstance.getResource();

4.3.2 库存遗留问题

由于乐观锁的存在，可能存在多个用户同时监视了同一个版本的 库存信息，当第一个用户秒杀成功后会修改库存信息，其他的用户就都会秒杀失败。因此即使参与秒杀的人数多于库存数，最终的库存数量也可能大于0。

• 解决库存遗留问题：lua 脚本。

LUA 脚本在 Redis 中的优势：

• 将复杂的或者多步的 redis 操作，写为一个脚本，一次提交给 redis 执行，减少反复连接 redis 的次数，提升性能。
• LUA 脚本是类似 redis 事务，有一定的原子性，不会被其他命令插队，可以完成一些 redis 事务性的操作。
• 但是注意 redis 的 lua 脚本功能，只有在 Redis 2.6 以上的版本才可以使用。
• 利用 lua 脚本淘汰用户，解决超卖问题，redis 2.6 版本以后，通过 lua 脚本解决争抢问题，实际上是 redis 利用其单线程的特性，用任务队列的方式解决多任务并发问题。
  

lua 脚本代码：

local userid=KEYS[1]; 
local prodid=KEYS[2];
local qtkey="sk:"..prodid..":qt";
local usersKey="sk:"..prodid.":usr'; 
local userExists=redis.call("sismember",usersKey,userid);
if tonumber(userExists)==1 then 
  return 2;
end
local num= redis.call("get" ,qtkey);
if tonumber(num)<=0 then 
  return 0; 
else 
  redis.call("decr",qtkey);
  redis.call("sadd",usersKey,userid);
end
return 1;

将 lua 脚本嵌入 java代码：

public class SecKill_redisByScript {

	static String secKillScript ="local userid=KEYS[1];\r\n" + 
			"local prodid=KEYS[2];\r\n" + 
			"local qtkey='sk:'..prodid..\":qt\";\r\n" + 
			"local usersKey='sk:'..prodid..\":usr\";\r\n" + 
			"local userExists=redis.call(\"sismember\",usersKey,userid);\r\n" + 
			"if tonumber(userExists)==1 then \r\n" + 
			"   return 2;\r\n" + 
			"end\r\n" + 
			"local num= redis.call(\"get\" ,qtkey);\r\n" + 
			"if tonumber(num)<=0 then \r\n" + 
			"   return 0;\r\n" + 
			"else \r\n" + 
			"   redis.call(\"decr\",qtkey);\r\n" + 
			"   redis.call(\"sadd\",usersKey,userid);\r\n" + 
			"end\r\n" + 
			"return 1" ;

	public static boolean doSecKill(String uid,String prodid) throws IOException {
		JedisPool jedispool =  JedisPoolUtil.getJedisPoolInstance();
		Jedis jedis=jedispool.getResource();

		String sha1=  jedis.scriptLoad(secKillScript);
		Object result= jedis.evalsha(sha1, 2, uid,prodid);

		String reString=String.valueOf(result);
		if ("0".equals( reString )  ) {
			System.err.println("已抢空！！");
		}else if("1".equals( reString )  )  {
			System.out.println("抢购成功！！！！");
		}else if("2".equals( reString )  )  {
			System.err.println("该用户已抢过！！");
		}else{
			System.err.println("抢购异常！！");
		}
		jedis.close();
		return true;
	}
}

七、Redis 持久化操作

在 redis.conf 文件中，有关保存策略的配置项，默认是关闭的，如果要开启持久化操作，需要开放保存策略。

save 3600 1 : 表示在3600秒内至少有1个键发生变化时，进行持久化操作。
save 300 100 : 表示在300秒内至少有100个键发生变化时，进行持久化操作。
save 60 10000 : 表示在60秒内至少有10000个键发生变化时，进行持久化操作。

在不修改配置文件的情况下，禁用保存策略：

redis-cli config set save “”  # save 后给空值，表示禁用保存策略。

1、RDB

开放保存策略后，默认开启的是 RDB 持久化方式。

1.1 简介

RDB：即 Redis DataBase，在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的 Snapshot 快照，它恢复时是将快照文件直接读到内存里。

1.2 RDB 是如何备份的

Redis 会单独创建（fork）一个子进程来进行持久化，首先会将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。

RDB 的缺点是最后一次持久化后的数据可能丢失。

Fork

• Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
• 在 Linux 程序中，fork () 会产生一个和父进程完全相同的子进程，但子进程在此后多会 exec 系统调用，出于效率考虑，Linux 中引入了 “写时复制技术”。
• 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

1.3 RDB持久化流程

• RDB 持久化方式会在 redis 的启动目录下创建一个 dump.rdb 文件。
• save 命令：只管保存，其它不管，全部阻塞，手动保存，不建议。
• bgsave 命令：Redis 会在后台异步进行快照操作， 快照同时还可以响应客户端请求。
• lastsave 命令：获取最后一次成功执行快照的时间。

1.4 RDB 的优势 和 劣势

优势：

• 适合大规模的数据恢复；
• 对数据完整性和一致性要求不高更适合使用；
• 节省磁盘空间；
• 恢复速度快；

劣势：

• Fork 的时候，内存中的数据被克隆了一份，大致 2 倍的膨胀性需要考虑；
• 虽然 Redis 在 fork 时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能；
• 在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改；

1.5 RDB 总结

2、AOF

AOF 默认是不开启的，如果开启，需要将 appendonly 改为 yes，其持久化文件是 appendonly.aof，默认保存在 redis 的启动目录。

当 RDB 和 AOF 同时开启，优先 AOF。

2.1 简介

AOF：即 Append Only File，以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来 (读操作不记录)， 只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2.2 AOF 持久化流程

• 客户端的请求写命令会被 append 追加到 AOF 缓冲区内；
• AOF 缓冲区根据 AOF 持久化策略 [always,everysec,no] 将操作 sync 同步到磁盘的 AOF 文件中；
• AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 rewrite 重写，压缩 AOF 文件容量；
• Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的。
  

2.3 AOF 同步频率设置

• appendfsync always：始终同步，每次 Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好。
• appendfsync everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
• appendfsync no：redis 不主动进行同步，把同步时机交给操作系统。

2.4 Rewrite 压缩

AOF 采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令 bgrewriteaof。

2.4.1 重写原理

AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写 (也是先写临时文件最后再 rename)，redis4.0 版本后的重写，是指把 rdb 的快照，以二进制的形式附在新的 aof 头部，作为已有的历史数据，替换掉原来的流水账操作。

no-appendfsync-on-rewrite：

• 如果 no-appendfsync-on-rewrite=yes ，不写入 aof 文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）;
• 如果 no-appendfsync-on-rewrite=no，还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

2.4.2 何时重写

Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发。
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定 Redis 要满足一定条件才会进行重写。

• auto-aof-rewrite-percentage：设置重写的基准值，文件达到 100% 时开始重写（文件是原来重写后文件的 2 倍时触发）
• auto-aof-rewrite-min-size：设置重写的基准值，最小文件 64MB。达到这个值开始重写。
• 系统载入时或者上次重写完毕时，Redis 会记录此时 AOF 大小，设为 base_size
• 如果 Redis 的 AOF 当前大小 >= base_size +base_size*100% (默认) 且当前大小 >=64mb (默认) 的情况下，Redis 会对 AOF 进行重写
• 例如：文件达到 70MB 开始重写，降到 50MB，下次什么时候开始重写？100MB

2.4.3 重写流程

• bgrewriteaof 触发重写，判断是否当前有 bgsave 或 bgrewriteaof 在运行，如果有，则等待该命令结束后再继续执行；
• 主进程 fork 出子进程执行重写操作，保证主进程不会阻塞；
• 子进程遍历 redis 内存中数据到临时文件，客户端的写请求同时写入 aof_buf 缓冲区和 aof_rewrite_buf 重写缓冲区，保证原 AOF 文件完整以及新 AOF 文件生成期间的新的数据修改动作不会丢失；
• 子进程写完新的 AOF 文件后，向主进程发信号，父进程更新统计信息。主进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件；
• 使用新的 AOF 文件覆盖旧的 AOF 文件，完成 AOF 重写。
  

2.5 AOF 的优势 和 劣势

优势：

• 备份机制更稳健，丢失数据概率更低。
• 可读的日志文本，通过操作 AOF 稳健，可以处理误操作。

劣势：

1. 比起 RDB 占用更多的磁盘空间。
2. 恢复备份速度要慢。
3. 每次读写都同步的话，有一定的性能压力。
4. 存在个别 Bug，造成恢复不了。

2.6 AOF总结

3、RDB 和 AOF 总结

3.1 选哪个

官方推荐两个都启用：

1. 如果对数据不敏感，可以选单独用 RDB。
2. 不建议单独用 AOF，因为可能会出现 Bug。
3. 如果只是做纯内存缓存，可以都不用。

3.2 官网建议

1. RDB 持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
2. AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF 命令以 redis 协议追加保存每次写的操作到文件末尾。
3. Redis 还能对 AOF 文件进行后台重写，使得 AOF 文件的体积不至于过大。
4. 只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。
5. 同时开启两种持久化方式：在这种情况下，当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。
6. RDB 的数据不实时，同时使用两者时服务器重启也只会找 AOF 文件。那要不要只使用 AOF 呢？建议不要，因为 RDB 更适合用于备份数据库 (AOF 在不断变化不好备份)，快速重启，而且不会有 AOF 可能潜在的 bug，留着作为一个万一的手段。
7. 性能建议：
   • 因为 RDB 文件只用作后备用途，建议只在 Slave 上持久化 RDB 文件，而且只要 15 分钟备份一次就够了，只保留 save 9001 这条规则。
   • 如果使用 AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单，只 load 自己的 AOF 文件就可以了。
   • AOF 代价：一是带来了持续的 IO，二是 AOF rewrite 的最后，将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
   • 只要硬盘许可，应该尽量减少 AOF rewrite 的频率，AOF 重写的基础大小默认值 64M 太小了，可以设到 5G 以上。默认超过原大小 100% 大小时重写可以改到适当的数值。

八、Redis 主从复制

1、模拟一主两从

1. 在根目录下创建 myredis 文件夹
2. 将 /etc/redis.conf 复制到 /myredis/redis.conf
3. 修改 /myredis/redis.conf，确保其 daemonize yes，appendonly no，且保存策略开启(持久化方法只用 RDB)
4. 在 /myredis 目录下创建3个文件：redis6379.conf、redis6379.conf、redis6379.conf，redis6379.conf 的内容如下，其它两个文件只需修改 pidfile、port、dbfilename 即可：

   include /myredis/redis.conf
   pidfile /var/run/redis_6379.pid
   port 6379
   dbfilename dump6379.rdb
   

5. 先把原来的 redis 服务关闭，再启动以上 3 个 redis 服务，每个服务相当于一台 redis 服务器：

   redis-cli shutdown # 关闭原来的 redis 服务
   
   redis-server /myredis/redis6379.conf
   redis-server /myredis/redis6380.conf
   redis-server /myredis/redis6381.conf
   
   ps -ef | grep redis # 查看 redis 进程信息，用以确认 redis 服务的开启情况
   

6. 打开 3 个终端，分别连接 3 台服务器：

   redis-cli -p 6379
   info replication # 查看主机信息
   

   其他两个是一样的操作，查看主机信息发现，3台都是主机，没有从机。
7. 配从不配主，将 6380、6381 设置为 6379 的从机：

   127.0.0.1:6380> slaveof 127.0.0.1 6379
   

   127.0.0.1:6381> slaveof 127.0.0.1 6379
   

8. 测试读写分离：
   在主机上写（当然主机上也可以读）：
   
   在从机上读（从机只能读，不能写）：
   

如果某台从机(6381)突然挂掉，则该从机重启后会变成主机，需要重新执行 slaveof 127.0.0.1 6379 命令，成为 6379 的从机，这一过程中主机会把所有数据都复制到从机。
需要注意：从机重启时会从命令行目录下寻找 dump6381.rdb 文件，重启后会从该文件恢复数据。

如果主机突然挂掉，则从机仍然是从机，主机仍然是主机。

2、主从复制的原理

1. 从机首次连接上主机之后，会向主机发送一个 sync 命令，告诉主机进行数据同步；
2. 全量复制：主机收到命令后，把主机中的所有数据进行持久化(.rdb)，然后把 .rdb 文件发送给从机，从机拿到 .rdb 文件进行数据同步；
3. 增量复制：主从连接后，每次主机上的数据发生改变时，会主动把修改命令发送给从机，完成同步。

3、薪火相传

类似于接龙，比如把 6380 设为 6379 的从机，6381 设为 6380 的从机，查看信息发现：主机仍然只有一个 6379，6380 仍然是从机，只不过 6380 还有一个从机 6381。这样可以有效减轻主机的写压力,去中心化降低风险；风险是一旦某个从机宕机，后面的从机都没法备份，因为从机没法变成主机。

127.0.0.1:6380> slaveof 127.0.0.1 6379

127.0.0.1:6381> slaveof 127.0.0.1 6380

4、反客为主

假设主机 6379 突然挂了，从机 6380 可以通过以下指令变成主机：

127.0.0.1:6380> slaveof no one

5、哨兵模式

哨兵模式可以看作是反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从机转换为主机。重启后的原主机会成为新主机的从机。

5.1 哨兵模式的实现

1. 在 /myredis 目录下新建 sentinel.conf 文件，文件名绝对不能变，文件内容如下：

   sentinel monitor mymaster 127.0.0.1 6379 1
   

   sentinel：哨兵
   monitor：监控
   mymaster：主机的别名
   127.0.0.1 6379：主机的 ip 和 端口号
   1：至少有多少个哨兵同意迁移。

2. 在 /myredis 目录下启动哨兵模式

   redis-sentinel sentinel.conf
   

5.2 主机选举机制

1. 首先选择优先级靠前的：在 redis.conf文件中，默认replica-priority 100，值越小优先级越高。
2. 然后选择偏移量最大的：偏移量是指获得原主机数据最全的。
3. 最后选择 runid 最小的：每个 redis 实例启动后都会随机生成一个 40 位的 runid。

九、Redis 集群

1、概述

1.1 为什么需要集群？

• 容量不够
• 并发写操作
• 主从模式、薪火相传模式下，主机宕机会导致ip地址发生变化，应用程序中的配置文件需要修改对应的主机地址、端口等信息

1.2 集群的两种模式

• 代理主机模式：即所有的请求都由代理主机接收，代理主机再找对应的业务主机进行处理请求，最后再由代理主机响应给客户端。
• 无中心化集群模式：每个业务主机都可以作为请求入口，如果当前业务主机无法处理请求，就交给其他业务主机进行处理。

Redis 采用的是无中心化集群模式，具体而言：
① Redis 集群（包括很多小集群）实现了对 Redis 的水平扩容，即启动 N 个 redis 节点，将整个数据库分布存储在这 N 个节点中，每个节点存储总数据的 1/N，即一个小集群存储 1/N 的数据，每个小集群里面维护好自己的 1/N 的数据。
② Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。
③ 该模式的 redis 集群特点是：分治、分片。

2、模拟 三主三从 的集群

2.1 搭建步骤

1. 将 /myredis 目录下的所有 .rdb、.aof 文件都删除：

   rm -rf *.rdb
   rm -rf *.aof
   

2. 创建 redis6379.conf、redis6380.conf、redis6381.conf、redis6389.conf、redis6390.conf、redis6391.conf 6个配置文件。redis6379.conf 中的内容如下：

   include /myredis/redis.conf
   pidfile "/var/run/redis_6379.pid"
   port 6379
   dbfilename "dump6379.rdb"
   cluster-enabled yes
   cluster-config-file nodes-6379.conf
   cluster-node-timeout 15000
   

   cluster-enabled yes : 打开集群模式
   cluster-config-file nodes-6379.conf : 设定节点配置文件名
   cluster-node-timeout 15000 : 设定节点失联时间(毫秒)，超过该时间节点自动进行主从切换

   其他文件只需修改 6379 为对应端口号即可。通过 vim 打开配置文件，输入 “shift+:”，然后输入替换命令 “%s/6379/6380”，按下 “enter” 保存并退出即可。

3. 启动 6 个 redis 服务
   
   查看生成的配置文件：
   

4. 将 6 个 redis 节点合为一个集群

   # cd 到 redis 解压目录下的 src 目录，redis-6.2.7/src
   cd /home/**/redis-6.2.7/src
   # 执行以下命令，其中的 ip 是自己电脑的真实 ip，不能是 127.0.0.1 或 localhost
   redis-cli --cluster create --cluster-replicas 1 ip:6379 ip:6380 ip:6381 192.168.0.110:6389 ip:6390 ip:6391
   

   –cluster-replicas 1 : 表示为集群中的每个主节点创建一个从节点。
   一个集群至少要有三个主节点。

   中间会出现下面一句话：Can I set the above configuration? (type ‘yes’ to accept):
   输入 yes 即可，最终会出现以下信息：
   

   如果出错了，就把所有中途生成的文件删除，然后重新从第一步开始。

5. 测试

   # 以集群方式连接
   redis-cli -c -p 6379 # 端口号可从6个里面任选
   # 查看节点信息
   cluster nodes
   

   出现以下信息表示集群搭建成功：
   

6. 关闭集群
   逐一关闭 6 个Redis 服务即可。

7. 重启集群
   ① 若要保留数据，直接重启 6 个 Redis 服务即可。
   ② 若不保留数据，则将所有的 .rdb 文件删除，再重启 6 个 Redis 服务即可。

2.2 什么是 slot

• slot：插槽。一个 redis 集群包含 16384 个插槽，索引是 0-16383，每个主节点包含一部分插槽。
• 如上图所示：主节点 6379 包含 0-5460 号插槽，主节点 63780 包含 5461-10922 号插槽，主节点 6381 包含 10923-16383 号插槽。
• 存储 key-value 时，集群使用公式 CRC16 (key) % 16384 来计算键 key 属于哪个插槽。如果该插槽刚好属于当前主机，就直接存储，否则重定向到该插槽所属主机再进行存储。
• 查询某个 key 时，也是先计算该 key 所在插槽的索引，然后找到该插槽所属主机再进行查询。
• 不能使用 mset、mget 等多键操作。如果非要用，需要将多个键放入同一个组，redis 会计算组名所属插槽，然后将整个组放入该插槽中。

  mset name{user} Tom age{user} 18
  mget name{user} age{user}
  

2.3 集群操作

# cluster keyslot <key> ：查询 key 所属插槽的索引
cluster keyslot k1
# cluster countkeysinslot <slot_index> ：统计第 slot_index 号插槽中 key 的数量(该插槽必须属于当前主机)
cluster countkeysinslot 12706
# cluster getkeysinslot <slot_index> <n> ：返回第 slot_index 号插槽中的 n 个 key
cluster getkeysinslot 449 1

2.4 故障恢复

• 如果某个主节点下线超 15 秒，其从机会自动变成主机，主节点恢复后变成从机。
• 如果某一段插槽的主从都挂掉，而 cluster-require-full-coverage 为 yes，那么整个集群都挂掉。
• 如果某一段插槽的主从都挂掉，而 cluster-require-full-coverage 为 no，那么只有该段插槽不能用。

3、集群的 Jedis 开发

• 引入 Jedis 依赖

  <dependency>
      <groupId>redis.clients</groupId>
      <artifactId>jedis</artifactId>
      <version>4.0.1</version>
  </dependency>
  

• 编写 java 代码

  public class JedisClusterTest {
      public static void main(String[] args) {
          //1、创建 JedisCluster 对象
          // 任选一台服务器都可进入 redis 集群，因为 redis 集群是无中心化模式
          HostAndPort hostAndPort = new HostAndPort("xxx.xxx.x.x", 6379);
          JedisCluster jedisCluster = new JedisCluster(hostAndPort);
  
          //2、测试
          jedisCluster.set("hello","world");
          String hello = jedisCluster.get("hello");
          System.out.println("hello: " + hello);
  
          //3、关闭
          jedisCluster.close();
      }
  }
  

十、应用问题解决

1、缓存穿透

1.1 问题描述

某些 key 对应的数据在数据源中并不存在，当短时间内接收到大量访问这些 key 的请求时，由于缓存中查询不到，就会积压给数据源，从而导致数据源崩溃。
比如，用一个不存在的用户 id 获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

1.2 发生条件

• 应用服务器压力突然变大
• redis 命中率降低
• 一直查询数据库，使得数据库压力太大崩溃

其实 redis 在这个过程中一直平稳运行，崩溃的是我们的数据库（如 MySQL）。
缓存穿透发生的原因：大都是由于黑客或其他非正常用户频繁进行很多非正常的 url 访问，使得 redis 查询不到而积压给数据库。

1.3 解决方案

• 对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。
• 设置可访问的名单（白名单）：使用 bitmaps 类型定义一个可以访问的名单，名单 id 作为 bitmaps 的偏移量，每次访问和 bitmap 里面的 id 进行比较，如果访问 id 不在 bitmaps 里面，进行拦截，不允许访问。
• 采用布隆过滤器：布隆过滤器（Bloom Filter）是 1970 年由布隆提出的。它实际上是一个很长的二进制向量 (位图) 和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
• 进行实时监控：当发现 Redis 的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务。

2、缓存击穿

2.1 问题描述

某些 key 对应的数据在数据源中存在，但在 redis 中过期了，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端数据库加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端数据库压垮。

2.2 发生条件

• redis 中出现个别热门数据的 key 过期的情况
• 数据库访问压力瞬时增加，导致数据库崩溃

整个过程中 redis 正常运行，只是其中某些热门的 key 过期了，恰巧此时有大量的并发请求访问这些 key，导致数据库访问压力瞬间激增而崩溃。

2.3 解决方案

• 预先设置热门数据：在 redis 访问高峰之前，把一些热门数据提前存入 redis 里，加大这些热门数据 key 的时长。

• 实时调整：现场监控哪些数据热门，实时调整 key 的过期时长。

• 使用锁：就是在缓存失效的时候，不是立即去 load db，而是先使用缓存工具的某些带成功操作返回值的操作(比如 Redis 的 setnx)，去 set 一个 mutex key。当操作返回成功时，再进行 load db 的操作，并回设缓存，最后删除 mutex key；当操作返回失败，证明有线程在 load db，当前线程睡眠一段时间再重试整个 get 缓存的方法。

  

3、缓存雪崩

3.1 问题描述

Redsi 中大量 key 同时过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端数据库加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端数据库压垮。

3.2 发生条件

• redis 中出现大量 key 过期的情况
• 数据库访问压力瞬时增加，导致数据库崩溃

缓存正常情况：

缓存失效瞬间：

3.3 解决方案

• 构建多级缓存架构：nginx 缓存 + redis 缓存 + 其他缓存(ehcache 等)。
• 使用锁或队列：用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上，该方法不适用高并发情况。
• 设置过期标志更新缓存：记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际 key 的缓存。
• 将缓存失效时间分散开：比如可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

4、分布式锁

4.1 问题描述

随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程的特点以及分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的 Java API 并不能提供分布式锁的能力。为了解决这个问题就需要一种跨 JVM 的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

4.2 分布式锁主流的实现方案

• 基于数据库实现分布式锁
• 基于缓存（Redis 等）
• 基于 Zookeeper

根据实现方式，分布式锁还可以分为类 CAS 自旋式分布式锁以及 event 事件类型分布式锁：

• 类 CAS 自旋式分布式锁：询问的方式，类似 java 并发编程中的线程获询问的方式尝试加锁，如 mysql、redis。
• 另外一类是 event 事件通知进程后续锁的变化，轮询向外的过程，如 zookeeper、etcd。

不同分布式锁解决方案的优缺点：

• 性能：redis 最高
• 可靠性：zookeeper 最高

4.3 Redis 实现分布式锁

1. 通过 setnx 命令上锁， del 命令解锁；

   setnx k1 v1
   del k1
   

2. 上面需要手动释放锁：可以通过设置过期时间来自动释放锁；

   setnx k1 v1
   expire k1 10
   

3. 如果加了锁后出现了异常，导致过期时间没设置成功：将锁和过期时间一起设置；

   set k1 v1 nx ex 10
   

4.4 Redis 分布式锁的 java 代码实现

@GetMapping("/testLock")
public void testLock(){
    //1获取锁，顺便设置过期时间
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111",3,TimeUnit.SECONDS);
    //2获取锁成功、查询num的值
    if(lock){
        Object value = redisTemplate.opsForValue().get("num");
        //2.1判断num为空return
        if(StringUtils.isEmpty(value)){
            return;
        }
        //2.2有值就转成成int
        int num = Integer.parseInt(value+"");
        //2.3把redis的num加1
        redisTemplate.opsForValue().set("num", ++num);
        //2.4释放锁，del
        redisTemplate.delete("lock");
    }else{
        //3获取锁失败、每隔0.1秒再获取
        try {
            Thread.sleep(100);
            testLock();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

上面的代码可能会出现一个问题：当前线程的锁被其他线程释放了。因此加个 UUID 防止误删，代码如下：

@GetMapping("/testLock")
public void testLock(){
	String uuid = UUID.randomUUID().toString();
	
    //1获取锁，顺便设置过期时间
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", uuid, 3, TimeUnit.SECONDS);
    //2获取锁成功、查询num的值
    if(lock){
        ...
        //2.4释放锁，del
        String lockUuid = (String)redisTemplate.opsForValue().get("lock");
        if(uuid.equals(lockUuid)){
        	redisTemplate.delete("lock");
        }
    }else{
        ...
    }
}

上述代码仍然存在一个线程误删另一个线程的锁的问题：假设线程a已经比对过 uuid 了，即将执行删除操作，但是这时锁过期了，然后线程b拿到了锁，在线程b释放锁之前线程a有可能会把线程b的锁提前释放掉。通过 lua 脚本保证删除操作的原子性，代码如下：

@GetMapping("/testLock")
public void testLock(){
	String uuid = UUID.randomUUID().toString();
	
    //1、获取锁，顺便设置过期时间
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", uuid, 3, TimeUnit.SECONDS);
    //2、获取锁成功、查询num的值
    if(lock){
        ...
        //2.4释放锁
        // 定义lua 脚本内容
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        // 创建脚本对象
        DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
        redisScript.setScriptText(script);
        // 设置返回值类型为Long，因为 redis.call('del', KEYS[1]) 默认返回的数据类型是String
        redisScript.setResultType(Long.class);
        // 执行脚本：第一个参数是script脚本，第二个参数是需要判断的key，第三个参数是key所对应的值。
        redisTemplate.execute(redisScript, Arrays.asList(locKey), uuid);
    }else{
        ...
    }
}

4.5 总结

为了确保分布式锁可用，至少要确保锁的实现同时满足以下四个条件：

1. 互斥性：在任意时刻，只有一个客户端能持有锁。(setnx 命令)
2. 不会发生死锁：即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。(expire 命令)
3. 加锁和解锁必须是同一个客户端。(UUID)
4. 解锁必须具有原子性。(lua 脚本)

十一、Redis 6 新功能

1、ACL

1.1 简介

ACL：即 Access Control List (访问控制列表)，该功能允许根据可以执行的命令和可以访问的键来限制某些连接。

​在Redis 5版本之前，Redis 安全规则只有密码控制 还有通过rename 来调整高危命令比如 flushdb ， KEYS* ， shutdown 等。

Redis 6 则提供ACL的功能对用户进行更细粒度的权限控制：

1. 接入权限:用户名和密码
2. 可以执行的命令
3. 可以操作的 key

1.2 常用的 ACL 命令

acl list # 显示所有的用户信息列表
acl whoami # 查看当前用户是谁
acl set user # 创建新用户
acl cat # 查看添加权限指令类别

2、IO 多线程

2.1 简介

IO 多线程：指客户端交互部分的网络 IO 交互处理模块 多线程，而非执行命令多线程。Redis6 执行命令依然是单线程。

2.2 原理

Redis 6 加入了多线程，但跟 Memcached 这种从 IO 处理到数据访问多线程的实现模式有些差异。Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂，需要去控制 key、lua、事务，LPUSH/LPOP 等等的并发问题。

Redis 6 中，多线程IO默认也是不开启的，需要在 redis.conf 中开启以下配置项：

io-threads 4

io-threads-do-reads yes