redis入门

跟着尚硅谷记的笔记

redis 数据类型

字符串（string）

简介

String类型是二进制安全的。意味着Redis的string可以包含任何数据。比如jpg图片或者序列化的对象。字符串最大长度为512M。

常用命令

命令	描述
set key value	设置指定key的值
get key	获取指定key的值
del key	删除key
exists key	检查key是否存在
expire key seconds	给key设置过期时间，单位秒
ttl key	显示key的剩余过期时间
type key	返回key的类型
getset key value	将给定 key 的值设为 value ，并返回 key 的旧值(old value)
mset key value [key value …]	同时设置一个或多个key - value
mget key1 [key2 …]	获取一个或多个key的值
incr key	将key中存储的数字加一
decr key	将key中存储的数字减一
incrby key increment	将 key 所储存的值加上给定的增量值（increment）
decrby key decrement	将 key 所储存的值减去给定的减量值（decrement）
append key value	将指定的value追加到key的原value值后
setex key seconds value	将值 value 关联到 key ，并将 key 的过期时间设为 seconds (以秒为单位)
setnx key value	只有在key不存在时设置key的值

数据结构

String的数据结构为简单动态字符串(Simple Dynamic String,缩写SDS)。是可以修改的字符串，内部结构实现上类似于Java的ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配。
当字符串长度小于1M时，扩容都是加倍现有的空间，如果超过1M，扩容时一次只会多扩1M的空间。需要注意的是字符串最大长度为512M。

哈希（hash）

简介

Redis hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，hash 特别适合用于存储对象。
Redis 中每个 hash 可以存储 232 - 1 键值对（40多亿）。

常用命令

命令	描述
hset key field value	将哈希表 key 中的字段 field 的值设为 value
hget key field	获取存储在哈希表中指定字段的值
hmget key field1 [field2]	获取所有给定字段的值
hmset key field1 value1 [field2 value2]	同时将多个 field-value (字段-值)对设置到哈希表 key 中
hdel key field1 [field2]	删除一个或多个字段
hgetall key	获取key的所有字段
hincrby key field increment	为哈希表 key 中的指定字段的整数值加上增量 increment
hlen key	获取哈希表中字段的数量
hexists key field	查看哈希表 key 中，指定的字段是否存在
hsetnx key field value	只有在字段 field 不存在时，设置哈希表字段的值
hkeys key	获取所有哈希表中的字段
hvals key	获取哈希表中所有值

数据结构

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

列表（list）

简介

Redis列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）
一个列表最多可以包含 232 - 1 个元素 (4294967295, 每个列表超过40亿个元素)。

常用命令

命令	描述
lpush key value1 [value2]	将一个或多个值插入到列表头部
rpush key value1 [value2]	将一个或多个值插入到列表尾部
lpop key	移出并获取列表的第一个元素并返回
rpop key	移除列表的最后一个元素并返回
lrange key start stop	通过索引获取元素
lindex key index	通过指定索引获取对应的元素
llen	获取列表长度
linsert key before/after value newvalue	在指定value 前/后 插入 newvalue
lrem key count value	从头部开始删除count个value元素
lset key index value	将索引为index的元素值替换为value

数据结构

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

集合（set）

简介

Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。
Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。
集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。

常用命令

命令	描述
sadd key value1 [value2]	将一个或多个 member 元素加入到集合 key 中，已经存在的 member 元素将被忽略
smembers key	取出集合中的所有元素
sismember key value	判断集合key是否为含有该value值，有返回1，没有返回0
scard key	返回该集合的元素个数
srem key value1 [value2]	删除集合中的一个或多个元素
spop key	移除并返回集合中的一个随机元素
srandmember key [count]	随机从该集合中取出一个或count个值。不会从集合中删除
sinter key1 key2	返回两个集合的交集元素
sunion key1 key2	返回两个集合的并集元素
sdiff key1 key2	返回两个集合的差集元素(key1中的，不包含key2中的)

数据结构

Set数据结构是dict字典，字典是用哈希表实现的。
Java中HashSet的内部实现使用的是HashMap，只不过所有的value都指向同一个对象。Redis的set结构也是一样，它的内部也使用hash结构，所有的value都指向同一个内部值。

有序集合（sorted set）

简介

Redis 有序集合和集合一样也是 string 类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个 double 类型的分数。redis 正是通过分数来为集合中的成员进行从小到大的排序。
有序集合的成员是唯一的,但分数(score)却可以重复。
集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。 集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。

常用命令

命令	描述
zadd key score1value1 [core2 value2]	向有序集合添加一个或多个成员，或者更新已存在成员的分数
zrange key start stop [withscores]	返回有序集 key 中，下标在start stop之间的元素,带withscores，可以让分数一起和值返回到结果集
zrangebyscore key minmax [withscores] [limit offset count]	返回有序集 key 中，所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。有序集成员按 score 值递增(从小到大)次序排列
zrevrangebyscore key maxmin [withscores] [limit offset count]	同上，改为从大到小排列
zincrby key increment value	有序集合中对指定成员的分数加上增量 increment
zrem key value	删除该集合指定值的元素
zcard key	获取有序集合的成员数
zcount key min max	统计该集合分数区间内的元素个数
zrank key value	返回该值在集合中的排名，从0开始

数据结构

SortedSet(zset)是Redis提供的一个非常特别的数据结构，一方面它等价于Java的数据结构Map<String, Double>，可以给每一个元素value赋予一个权重score，另一方面它又类似于TreeSet，内部的元素会按照权重score进行排序，可以得到每个元素的名次，还可以通过score的范围来获取元素的列表。
zset底层使用了两个数据结构
（1）hash，hash的作用就是关联元素value和权重score，保障元素value的唯一性，可以通过元素value找到相应的score值。
（2）跳跃表，跳跃表的目的在于给元素value排序，根据score的范围获取元素列表。

bitmaps

简介

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

命令

setbit key offset value 设置Bitmaps中某个偏移量的值（0或1） offset:偏移量从0开始
每个独立用户是否访问过网站存放在Bitmaps中， 将访问的用户记做1， 没有访问的用户记做0， 用偏移量作为用户的id。
设置键的第offset个位的值（从0算起） ， 假设现在有20个用户，userid=1， 6， 11， 15， 19的用户对网站进行了访问， 那么当前Bitmaps初始化结果如图

unique:users:20201106 代表 2020-11-06 这天的独立访问用户的Bitmaps

很多应用的用户id以一个指定数字（例如10000） 开头， 直接将用户id和Bitmaps的偏移量对应势必会造成一定的浪费， 通常的做法是每次做setbit操作时将用户id减去这个指定数字。
在第一次初始化Bitmaps时， 假如偏移量非常大， 那么整个初始化过程执行会比较慢， 可能会造成Redis的阻塞。

getbit key offset获取Bitmaps中某个偏移量的值
获取id=8的用户是否在2020-11-06这天访问过， 返回0说明没有访问过：

bitcount key [start end] 统计字符串从start字节到end字节比特值为1的数量
计算2022-11-06这天的独立访问用户数量
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LvKpp8iJ-1625903102584)(https://cdn.nlark.com/yuque/0/2021/png/21889008/1625755891033-5c869757-2032-48af-b442-a33098a16e34.png#align=left&display=inline&height=38&id=sl2wO&margin=%5Bobject%20Object%5D&originHeight=38&originWidth=394&status=done&style=none&width=394)]
bitop and(or/not/xor) destkey key [key…] bitop是一个复合操作， 它可以做多个Bitmaps的and（交集） 、 or（并集） 、 not（非） 、 xor（异或） 操作并将结果保存在destkey中
2020-11-04 日访问网站的userid=1,2,5,9

setbit unique:users:20201104 1 1
setbit unique:users:20201104 2 1
setbit unique:users:20201104 5 1
setbit unique:users:20201104 9 1

2020-11-03 日访问网站的userid=0,1,4,9

setbit unique:users:20201103 0 1
setbit unique:users:20201103 1 1
setbit unique:users:20201103 4 1
setbit unique:users:20201103 9 1

计算出两天都访问过网站的用户数量

bitop and unique:users:and:20201104_03 unique:users:20201103 unique:users:20201104
(integer) 2

Bitmaps与set对比

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

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

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

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

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

set和Bitmaps存储一天活跃用户对比（独立用户比较少）
数据类型	每个userid占用空间	需要存储的用户量	全部内存量
集合类型	64位	100000	64位*100000 = 800KB
Bitmaps	1位	100000000	1位*100000000 = 12.5MB

hyperloglog

简介

在工作当中，我们经常会遇到与统计相关的功能需求，比如统计网站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。 基数估计就是在误差可接受的范围内，快速计算基数。

命令

pfadd key element [element ...] 添加指定元素到 HyperLogLog 中

将所有元素添加到指定HyperLogLog数据结构中。如果执行命令后HLL估计的近似基数发生变化，则返回1，否则返回0。
pfcount key [key ...] 计算HLL的近似基数，可以计算多个HLL，比如用HLL存储每天的UV，计算一周的UV可以使用7天的UV合并计算即可

pfmerge destkey sourcekey [sourcekey ...] 将一个或多个HLL合并后的结果存储在另一个HLL中，比如每月活跃用户可以使用每天的活跃用户来合并计算可得

geospatial

简介

Redis 3.2 中增加了对GEO类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。
两极无法直接添加，一般会下载城市数据，直接通过 Java 程序一次性导入。
有效的经度从 -180 度到 180 度。有效的纬度从 -85.05112878 度到 85.05112878 度。
当坐标位置超出指定范围时，该命令将会返回一个错误。
已经添加的数据，是无法再次往里面添加的。

命令

geoadd key longitude latitude member [longitude latitude member...] 添加地理位置（经度，纬度，名称）

geoadd china:city 121.47 31.23 shanghai
geoadd china:city 106.50 29.53 chongqing 114.05 22.52 shenzhen 116.38 39.90 beijing

geopos key member [member...] 获得指定地区的坐标值

geodist key member1 member2 [m|km|ft|mi ] 获取两个位置之间的直线距离

单位：

• m 表示单位为米[默认值]。
• km 表示单位为千米。
• mi 表示单位为英里。
• ft 表示单位为英尺。

如果用户没有显式地指定单位参数， 那么 GEODIST 默认使用米作为单位
georadius key longitude latitude radius m|km|ft|mi 以给定的经纬度为中心，找出某一半径内的元素

redis 发布订阅

打开一个客户端订阅 channel1
subscribe channel

127.0.0.1:6379> SUBSCRIBE channel1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel1"
3) (integer) 1

打开另一个客户端，给 channel1 发布消息 hello,redis 返回的1是订阅者数量
publish channel message

127.0.0.1:6379> publish channel1 hello,redis
(integer) 1
127.0.0.1:6379>

取消订阅
unsubscribe channel

redis 配置项

redis.conf 配置项说明如下：

序号	配置项	说明
1	daemonize no	Redis 默认不是以守护进程的方式运行，可以通过该配置项修改，使用 yes 启用守护进程（Windows 不支持守护线程的配置为 no ）
2	pidfile /var/run/redis.pid	当 Redis 以守护进程方式运行时，Redis 默认会把 pid 写入 /var/run/redis.pid 文件，可以通过 pidfile 指定
3	port 6379	指定 Redis 监听端口，默认端口为 6379，作者在自己的一篇博文中解释了为什么选用 6379 作为默认端口，因为 6379 在手机按键上 MERZ 对应的号码，而 MERZ 取自意大利歌女 Alessia Merz 的名字
4	bind 127.0.0.1	绑定的主机地址
5	timeout 300	当客户端闲置多长秒后关闭连接，如果指定为 0 ，表示关闭该功能
6	loglevel notice	指定日志记录级别，Redis 总共支持四个级别：debug、verbose、notice、warning，默认为 notice
7	logfile stdout	日志记录方式，默认为标准输出，如果配置 Redis 为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给 /dev/null
8	databases 16	设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id
9	save <seconds> <changes> Redis 默认配置文件中提供了三个条件：save 900 1 save 300 10 save 60 10000 分别表示 900 秒（15 分钟）内有 1 个更改，300 秒（5 分钟）内有 10 个更改以及 60 秒内有 10000 个更改。	指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
10	rdbcompression yes	指定存储至本地数据库时是否压缩数据，默认为 yes，Redis 采用 LZF 压缩，如果为了节省 CPU 时间，可以关闭该选项，但会导致数据库文件变的巨大
11	dbfilename dump.rdb	指定本地数据库文件名，默认值为 dump.rdb
12	dir ./	指定本地数据库存放目录
13	slaveof <masterip> <masterport>	设置当本机为 slave 服务时，设置 master 服务的 IP 地址及端口，在 Redis 启动时，它会自动从 master 进行数据同步
14	masterauth <master-password>	当 master 服务设置了密码保护时，slav 服务连接 master 的密码
15	requirepass foobared	设置 Redis 连接密码，如果配置了连接密码，客户端在连接 Redis 时需要通过 AUTH 命令提供密码，默认关闭
16	maxclients 128	设置同一时间最大客户端连接数，默认无限制，Redis 可以同时打开的客户端连接数为 Redis 进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis 会关闭新的连接并向客户端返回 max number of clients reached 错误信息
17	maxmemory <bytes>	指定 Redis 最大内存限制，Redis 在启动时会把数据加载到内存中，达到最大内存后，Redis 会先尝试清除已到期或即将到期的 Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis 新的 vm 机制，会把 Key 存放内存，Value 会存放在 swap 区
18	maxmemory-policy	设置最大内存策略, volatile-lru：使用LRU算法移除key，只对设置了过期时间的键；（最近最少使用） allkeys-lru：在所有集合key中，使用LRU算法移除key volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键 allkeys-random：在所有集合key中，移除随机的key volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key noeviction：不进行移除。针对写操作，只是返回错误信息
19	appendonly no	指定是否在每次更新操作后进行日志记录，Redis 在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis 本身同步数据文件是按上面 save 条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为 no
20	appendfilename appendonly.aof	指定更新日志文件名，默认为 appendonly.aof
21	appendfsync everysec	指定更新日志条件，共有 3 个可选值：no：表示等操作系统进行数据缓存同步到磁盘（快）always：表示每次更新操作后手动调用 fsync() 将数据写到磁盘（慢，安全）everysec：表示每秒同步一次（折中，默认值）
22	vm-enabled no	指定是否启用虚拟内存机制，默认值为 no，简单的介绍一下，VM 机制将数据分页存放，由 Redis 将访问量较少的页即冷数据 swap 到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析 Redis 的 VM 机制）
23	vm-swap-file /tmp/redis.swap	虚拟内存文件路径，默认值为 /tmp/redis.swap，不可多个 Redis 实例共享
24	vm-max-memory 0	将所有大于 vm-max-memory 的数据存入虚拟内存，无论 vm-max-memory 设置多小，所有索引数据都是内存存储的(Redis 的索引数据 就是 keys)，也就是说，当 vm-max-memory 设置为 0 的时候，其实是所有 value 都存在于磁盘。默认值为 0
25	vm-page-size 32	Redis swap 文件分成了很多的 page，一个对象可以保存在多个 page 上面，但一个 page 上不能被多个对象共享，vm-page-size 是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page 大小最好设置为 32 或者 64bytes；如果存储很大大对象，则可以使用更大的 page，如果不确定，就使用默认值
26	vm-pages 134217728	设置 swap 文件中的 page 数量，由于页表（一种表示页面空闲或使用的 bitmap）是在放在内存中的，，在磁盘上每 8 个 pages 将消耗 1byte 的内存。
27	vm-max-threads 4	设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
28	glueoutputbuf yes	设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
29	hash-max-zipmap-entries 64 hash-max-zipmap-value 512	指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
30	activerehashing yes	指定是否激活重置哈希，默认为开启
31	include /path/to/local.conf	指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件

redis 事务

简介

Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：

• 批量操作在发送 EXEC 命令前被放入队列缓存。
• 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
• 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

一个事务从开始到执行会经历以下三个阶段：

• 开始事务。
• 命令入队。
• 执行事务。

Redis 事务命令

命令	描述
discard	取消事务，放弃执行事务块内的所有命令。
exec	执行所有事务块内的命令。
multi	标记一个事务块的开始。
unwatch	取消 unwatch 命令对所有 key 的监视。
watch key	监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

测试事务

成功执行事务

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
127.0.0.1:6379> keys *
1) "k2"
2) "k1"
127.0.0.1:6379>

模拟入队时错误，整个事务中的命令都不会成功

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> keys *
(empty array)

模拟执行时错误，只有执行错误的命令不会成功，其他的命令还是会被执行的

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> incr k1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
127.0.0.1:6379> keys *
1) "k2"
2) "k1"
127.0.0.1:6379>

乐观锁

乐观锁(Optimistic Lock) 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

悲观锁

悲观锁(Pessimistic Lock) 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

测试乐观锁

127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incrby money 10
QUEUED

再开启一个客户端，修改 money 的值

127.0.0.1:6379> decrby money 50
(integer) 50

提交事务

127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> unwatch
OK

在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

事务的三特性

• 单独的隔离性
  事务中的所有命令都会被序列化、顺序的执行。在事务执行的过程中，不会被其他的客户端的命令打断
• 没有隔离级别
  队列中的命令在没有提交之前都不会被执行，因为事务提交之前任何命令都不会执行
• 不保证原子性
  事务中如果有命令执行失败，其他的命令任然会执行，不会回滚

使用 Jedis 连接 Redis

使用jedis远程连接redis需要在redis配置文件 关闭ip绑定和保护模式
注释 bind 127.0.0.1
protected-mode yes 改为 no
防火墙也要关闭 systemctl stop/disable firewalld.service

• 创建 maven 项目导入依赖

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

• 测试 方法和redis中的命令一样

public static void main(String[] args) {
    Jedis jedis = new Jedis("192.168.137.3",6379);
    String pong = jedis.ping();
    System.out.println("连接成功："+pong);
    jedis.close();
}
public class RedisStringJava {
    public static void main(String[] args) {
        //连接本地的 Redis 服务
        Jedis jedis = new Jedis("192.168.137.3",6379);
        System.out.println("连接成功");
        //设置 redis 字符串数据
        jedis.set("runoobkey", "www.runoob.com");
        // 获取存储的数据并输出
        System.out.println("redis 存储的字符串为: "+ jedis.get("runoobkey"));
        // 关闭连接
        jedis.close();
    }
}

模拟手机验证码功能

/**
 * @author starry
 * 模拟手机发送验证码
 * 限制：
 *      每个手机号一天只能发送3次验证码
 *      发送6位数字的验证码，每次验证码有限时间为3分钟
 *      输入验证码判断是否正确
 */
public class PhoneCode {
    private static final String SEND_CODE_KEY_SUFFIX = ":code";
    private static final String SEND_NUM_KEY_SUFFIX = ":sendNum";
    private static final Integer SEND_MAX_NUM = 3;
    private static final Integer CODE_MAX_LENGTH = 6;
    private static final Long CODE_MAX_SECONDS = 3 * 60L;
    private static final Long CODE_SEND_MAX_SECONDS = 24 * 60 * 60L;
    private static final String HOST = "192.168.83.128";
    private static final int PORT = 6379;
    
    public static void main(String[] args) {
        String code = getCode();
        sendCode("13333333333", code);
        inputCode("13333333333","111111");
        inputCode("13333333333",code);
    }
    /**
     * @return 返回验证码
     */
    public static String getCode(){
        String code = "";
        Random random = new Random();
        for (int i = 0; i < CODE_MAX_LENGTH; i++) {
            int randomInt = random.nextInt(9);
            code += randomInt;
        }
        return code;
    }
    /**
     * 模拟发送验证码，将手机号对于的验证码存放到redis中，并设置过期时间为3分钟
     * @param phone
     * @param code
     */
    public static void sendCode(String phone,String code){
        Jedis jedis = new Jedis(HOST, PORT);
        // 验证码存储到redis的key
        String sendCodeKey = phone + SEND_CODE_KEY_SUFFIX;
        // 手机发送次数存储到redis的key
        String sendNumKey = phone + SEND_NUM_KEY_SUFFIX;
        String num = jedis.get(sendNumKey);
        if (num == null){
            jedis.setex(sendCodeKey, CODE_MAX_SECONDS, code);
            jedis.setex(sendNumKey, CODE_SEND_MAX_SECONDS, "1");
        }else if(Integer.parseInt(num) < SEND_MAX_NUM){
            jedis.setex(sendCodeKey, CODE_MAX_SECONDS, code);
            jedis.incr(sendNumKey);
        }else if(Integer.parseInt(num) > SEND_MAX_NUM){
            System.out.println("今日发送短信次数达上限，请24小时后重试！");
        }
        jedis.close();
    }
    /**
     * 判断输入的验证码是否正确
     * @param phone
     * @param code
     */
    public static void inputCode(String phone, String code){
        Jedis jedis = new Jedis(HOST, PORT);
        String sendCodeKey = phone + SEND_CODE_KEY_SUFFIX;
        String phoneCode = jedis.get(sendCodeKey);
        if (code.equals(phoneCode)){
            System.out.println("successful");
            // 验证成功就删除验证码
            jedis.del(sendCodeKey);
        } else {
            System.out.println("failed");
        }
        jedis.close();
    }
}

springboot整合redis

• 新建 springboot 项目，导入依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

• 编写配置

spring.redis.host=192.168.83.128
spring.redis.port=6379

• 编写 controller

@RestController
public class MyController {
    @Autowired
    private RedisTemplate redisTemplate;
    @RequestMapping("/set/{name}")
    public String setName(@PathVariable("name") String name) {
        redisTemplate.opsForValue().set("name",name);
        System.out.println(redisTemplate.opsForValue().get("name"));
        return "ok";
    }
}

• 测试 http://localhost:8080/set/starry
  控制台输出 starry
  使用命令行查看并没有 name

127.0.0.1:6379> keys *
1) "\xac\xed\x00\x05t\x00\x04name"
127.0.0.1:6379>

• 由于我们使用的是默认的 RedisTemplate ，默认序列化方式为 JDK序列化 ，我们配置自定义序列化

@EnableCaching
@Configuration
public class RedisConfig extends CachingConfigurerSupport {
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        RedisSerializer<String> redisSerializer = new StringRedisSerializer();
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
//        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        om.activateDefaultTyping(LaissezFaireSubTypeValidator.instance ,
                ObjectMapper.DefaultTyping.NON_FINAL, JsonTypeInfo.As.PROPERTY);
        jackson2JsonRedisSerializer.setObjectMapper(om);
        template.setConnectionFactory(factory);
        //key序列化方式
        template.setKeySerializer(redisSerializer);
        //value序列化
        template.setValueSerializer(jackson2JsonRedisSerializer);
        //value hashmap序列化
        template.setHashValueSerializer(jackson2JsonRedisSerializer);
        return template;
    }
    @Bean
    public CacheManager cacheManager(RedisConnectionFactory factory) {
        RedisSerializer<String> redisSerializer = new StringRedisSerializer();
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
        //解决查询缓存转换异常的问题
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.activateDefaultTyping(LaissezFaireSubTypeValidator.instance ,
                ObjectMapper.DefaultTyping.NON_FINAL, JsonTypeInfo.As.PROPERTY);
        jackson2JsonRedisSerializer.setObjectMapper(om);
        // 配置序列化（解决乱码的问题）,过期时间600秒
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofSeconds(600))
                .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(redisSerializer))
                .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(jackson2JsonRedisSerializer))
                .disableCachingNullValues();
        RedisCacheManager cacheManager = RedisCacheManager.builder(factory)
                .cacheDefaults(config)
                .build();
        return cacheManager;
    }
}

• 再次测试

127.0.0.1:6379> keys *
1) "name"
127.0.0.1:6379> get name
"\"starry\""

模拟秒杀案例

• 创建 springboot 项目，勾选 web，thymeleaf，redis 依赖，编写配置

spring.redis.host=192.168.83.128
spring.redis.port=6379

• 编写简单的秒杀页面

<!DOCTYPE html>
<html lang="en" xmlns:th="https://www.thymeleaf.org">
<head>
    <meta charset="UTF-8">
    <title>秒杀页面</title>
</head>
<body>
<h2>macbook秒杀中</h2><br>
<a href="/seckill">秒杀</a><br>
<span th:text="${msg}" th:if="${msg!=null}"></span>
</body>
</html>

• controller

@Controller
public class MyController {
    @Autowired
    private SeckillService seckillService;
    @RequestMapping("/toIndex")
    public String toIndex(){
        return "index";
    }
    @RequestMapping("/seckill")
    public String seckill(Model model){
        // 随机用户名
        String userId =  new Random().nextInt(10000) + "";
        String prodId = "1000";
        String msg = seckillService.secKill(userId, prodId);
        model.addAttribute("msg", msg);
        return "index";
    }
}

• service

@Service
public class SeckillService {
    @Autowired
    private RedisTemplate redisTemplate;
    final static String PRODUCT_NUM_KEY_PREFIX = "sk:productNumKey:";
    final static String PRODUCT_USER_KEY_PREFIX = "sk:productUserKey:";
    public String secKill(String userId,String prodId){
        /*
        * 判断传入的参数是否为null
        * 从redis中获取库存
        *   库存为null，key不对（传入的产品id不对），活动为开始
        *   库存0，当前商品无货
        *   是否二次下单
        * 成功下单
        *
        * */
        if (StringUtils.isEmpty(userId) || StringUtils.isEmpty(prodId)){
            return null;
        }
        Integer productNum = (Integer) redisTemplate.opsForValue().get(PRODUCT_NUM_KEY_PREFIX + prodId);
        if (productNum == null){
            return "请检查产品id是否正确";
        }
        if (productNum <= 0){
            return "当前商品无库存，请选择其他商品";
        }
        // 使用set保证用户不能重复下单
        if (redisTemplate.opsForSet().isMember(PRODUCT_USER_KEY_PREFIX + prodId, userId)){
            // 如果redis中查询到用户，表明该用户已经参加过秒杀
            return "您已成功购买该商品，看看其他商品吧";
        }
        // 如果上面的条件都不满足就执行秒杀操作，库存减一，秒杀成功添加用户
        redisTemplate.opsForValue().decrement(PRODUCT_NUM_KEY_PREFIX + prodId);
        redisTemplate.opsForSet().add(PRODUCT_USER_KEY_PREFIX + prodId, userId);
        return "恭喜你，抢到商品了";
    }
}

• 再配置之前的自定义 RedisTemplate
• redis中添加商品数量 商品id：1000 数量：10

127.0.0.1:6379> set sk:productNumKey:1000 10
OK

• 启动服务，服务 http://localhost:8080/toIndex ，点击 秒杀
  秒杀成功，点击10次后，显示无库存
  看似一切功能正常，但是这只是访问人数少的情况下，多线程就会出问题

秒杀并发模拟

使用工具ab模拟测试
CentOS6 默认安装
CentOS7 需要手动安装

yum install httpd-tools

controller 添加一个消息输出,方便查看

System.out.println(msg);

设置商品数量 10

127.0.0.1:6379> set sk:productNumKey:1000 10
OK

使用工具模拟多线程
-n 发送请求的总数 -c 线程数

ab -n 1000 -c 200 http://10.223.18.11:8080/seckill

127.0.0.1:6379> get sk:productNumKey:1000
"-183"

可以看到有很多线程都是抢到商品了，商品库存变成负数了（超卖），因为是多个线程进行抢购，获取到商品数量是大于0的，所以进行商品数量减一，但是提交的时候没有再次进行判断

使用乐观锁

@Service
public class SeckillService {
    @Autowired
    private RedisTemplate redisTemplate;
    final static String PRODUCT_NUM_KEY_PREFIX = "sk:productNumKey:";
    final static String PRODUCT_USER_KEY_PREFIX = "sk:productUserKey:";
    public String secKill(String userId,String prodId){
        /*
        * 判断传入的参数是否为null
        * 从redis中获取库存
        *   库存为null，key不对（传入的产品id不对），活动为开始
        *   库存0，当前商品无货
        *   是否二次下单
        * 成功下单
        *
        * */
        if (!StringUtils.hasLength(userId) || !StringUtils.hasLength(prodId)){
            return null;
        }
        Integer productNum = (Integer) redisTemplate.opsForValue().get(PRODUCT_NUM_KEY_PREFIX + prodId);
        if (productNum == null){
            return "请检查产品id是否正确";
        }
        if (productNum <= 0){
            return "当前商品无库存，请选择其他商品";
        }
        // 使用set保证用户不能重复下单
        if (redisTemplate.opsForSet().isMember(PRODUCT_USER_KEY_PREFIX + prodId, userId)){
            // 如果redis中查询到用户，表明该用户已经参加过秒杀
            return "您已成功购买该商品，看看其他商品吧";
        }
        // 如果上面的条件都不满足就执行秒杀操作，库存减一，秒杀成功添加用户
        List execute = (List)redisTemplate.execute(new SessionCallback() {
            @Override
            public Object execute(RedisOperations operations) throws DataAccessException {
                operations.watch(PRODUCT_NUM_KEY_PREFIX + prodId);
                operations.multi();
                operations.boundValueOps(PRODUCT_NUM_KEY_PREFIX + prodId).decrement();
                operations.boundSetOps(PRODUCT_USER_KEY_PREFIX + prodId).add(userId);
                List exec = operations.exec();
                return exec;
            }
        });
        if (execute == null || execute.size() == 0){
            return "未抢到，请重试";
        }
        /*redisTemplate.opsForValue().decrement(PRODUCT_NUM_KEY_PREFIX + prodId);
        redisTemplate.opsForSet().add(PRODUCT_USER_KEY_PREFIX + prodId, userId);
        */
        return "恭喜你，抢到商品了";
    }
}

使用 RedisTemplate 在测试的时候发现使用乐观锁还是不能解决超卖的情况(-3)，但是使用 jedis 测试可以解决，不知道怎么回事…
理论上使用乐观锁可以解决超卖的情况，但是加大库存还是会出现商品没卖完的情况。因为，多个线程获取库存不为0，所以进行商品数量减一，但是使用乐观锁了，提交时还要再次判断库存，提交时的库存和读取到的库存不一致，所以事务不会被执行；多个线程进行库存减一，只有一个线程执行成功，其他的线程都会失败，因为数据不一致

• 还可能出现连接超时的情况，这时需要配置连接池

Lua解决库存遗留

Lua 是一个小巧的脚本语言，Lua脚本可以很容易的被C/C++ 代码调用，也可以反过来调用C/C++的函数，Lua并没有提供强大的库，一个完整的Lua解释器不过200k，所以Lua不适合作为开发独立应用程序的语言，而是作为嵌入式脚本语言。
很多应用程序、游戏使用LUA作为自己的嵌入式脚本语言，以此来实现可配置性、可扩展性。
将复杂的或者多步的redis操作，写为一个脚本，一次提交给redis执行，减少反复连接redis的次数。提升性能。
LUA脚本是类似redis事务，有一定的原子性，不会被其他命令插队，可以完成一些redis事务性的操作。
但是注意redis的lua脚本功能，只有在Redis 2.6以上的版本才可以使用。
利用lua脚本淘汰用户，解决超卖问题。
redis 2.6版本以后，通过lua脚本解决争抢问题，实际上是redis 利用其单线程的特性，用任务队列的方式解决多任务并发问题。

public class SecKill_redisByScript {
		
	static String secKillScript = "local userid=KEYS[1];\n" +
            "local prodid=KEYS[2];\n" +
            "local qtkey=\"sk:productNumKey:\"..prodid;\n" +
            "local usersKey=\"sk:productUserKey:\"..prodid;\n" +
            "local userExists=redis.call(\"sismember\",usersKey,userid);\n" +
            "if tonumber(userExists)==1 then\n" +
            "  return 2;\n" +
            "end\n" +
            "local num= redis.call(\"get\" ,qtkey);\n" +
            "if tonumber(num)<=0 then\n" +
            "  return 0;\n" +
            "else\n" +
            "  redis.call(\"decr\",qtkey);\n" +
            "  redis.call(\"sadd\",usersKey,userid);\n" +
            "end\n" +
            "return 1;";
			 
	public static boolean doSecKill(String uid,String prodid) throws IOException {
		Jedis jedis=new Jedis();
		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 提供了2种不同的数据持久化方式

• RDB (Rdis DataBase)
• AOF (Append Only File)

RBD

在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个_临时文件_中，待持久化过程都结束了，再用这个_临时文件替换上次持久化好的文件_。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于_数据恢复的完整性不是非常敏感_，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

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

配置

rdb的文件保存路径默认是redis的安装路径

默认文件名是 dump.rdb

保存快照的默认配置

3600 秒内至少有 1次key修改 就保存
300 秒内至少有 10次key修改 就保存
60 秒内至少有 10000次key修改 就保存
eg：在300秒内修改了11次，会先保存10次，剩余的1次算作下一次的300秒内

save 和 bgsave

• save: save时只管保存，其它不管，全部阻塞。手动保存。不建议。
• bgsave：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。

可以通过 lastsave 命令获取最后一次成功执行快照的时间

stop-writes-on-bgsave-error yes

当Redis无法写入磁盘的话，直接关掉Redis的写操作。默认 yes

rdbcompression yes

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。默认yes.

rdbchecksum yes

在存储快照后，还可以让redis使用CRC64算法来进行数据校验,检验其完整性
但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。默认yes.

备份和恢复

# 可以先查看redis目录
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"
# 使用 save 备份 dump.rdb，将dump.rdb文件移动到其他文件夹，以防被覆盖
127.0.0.1:6379> save
OK
# 也可以使用 bgsave 在后台备份
127.0.0.1:6379> bgsave
Background saving started

恢复
如果需要恢复数据，只需将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可

# 将 dump.rdb 移动到这个目录
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"

优势与劣势

优势

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

劣势

• fork的子进程的时候，内存中的数据被克隆了一份，内存占用大
• 虽然fork时使用了_写时拷贝技术_，但是如果数据很大还是比较消耗性能
• 在备份时间是一段周期内，如果最后一周期时redis意外down掉，会丢失最后一次快照之后的所有修改

AOF

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

配置

开启 aof 默认关闭,默认文件名是 appendonly.aof
如果rdb和aof都开启的话，将使用aof，redis启动时会读取appendonly.aof

appendonly yes

同步频率

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

Rewrite压缩

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

重写原理，如何实现重写

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

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

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

• auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）
• auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,
如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

重写流程

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

备份和修复

备份
AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
恢复

• 修改默认的appendonly no，改为yes
• 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
  如遇到_AOF文件损坏_，通过 /usr/local/bin/redis-check-aof --fix appendonly.aof 进行恢复
• 恢复：重启redis然后重新加载

优势与劣势

优势

• 备份机制更稳健，丢失几率更低
• 可读的日志文本，通过操作aof文件，可处理错误操作

劣势

• 比rdb占用更多磁盘空间
• 恢复速度更慢
• 每次写都同步的话，服务器有一定的压力

---

总结

• 官方推荐两个都启用。
• 如果对数据不敏感，可以选单独用RDB。
• 不建议单独用 AOF，因为可能会出现Bug。
• 如果只是做纯内存缓存，可以都不用。

官网建议

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
• Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
• 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
• 同时开启两种持久化方式
• 当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
  建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
• 性能建议

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。

代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。
默认超过原大小100%大小时重写可以改到适当的数值。

redis 主从复制

主机数据更新后根据配置和策略， 自动同步到备机的master/slave，Master以写为主，Slave以读为主

#拷贝多个redis.conf文件include(写绝对路径)
#开启daemonize yes
#Pid文件名字pidfile
#指定端口port
#Log文件名字
#dump.rdb名字dbfilename
#Appendonly 关闭

一主多仆

• 新建 /myRedisConf 目录

mkdir /myRedisConf

• 将 redis.conf 复制到此目录

cp /usr/local/redis.conf /myRedisConf/

• 在 /myRedisConf 新建 redis6379.conf 配置文件

cd /myRedisConf
vim redis6379.conf

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

• 新建 redis6380.conf

include /myRedisConf/redis.conf
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb

• 新建 redis6381.conf

include /myRedisConf/redis.conf
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb

• 启动这3台服务器

cd /usr/local/bin
redis-server /myRedisConf/redis6379.conf
redis-server /myRedisConf/redis6380.conf
redis-server /myRedisConf/redis6381.conf

• 查看进程是否正常启动

ps -ef|grep redis
root      31298      1  0 06:52 ?        00:00:01 redis-server *:6379
root      31315      1  0 06:53 ?        00:00:01 redis-server *:6380
root      31321      1  0 06:53 ?        00:00:01 redis-server *:6381
root      31946   2697  0 07:22 pts/2    00:00:00 grep --color=auto redis

• 连接主机进行查看

redis-cli -p 6379
redis-cli -p 6380
redis-cli -p 6381
# 打印主从复制的相关信息
info replication

• 
• 为主(库)配置从(库)

# 成为某个实例的从服务器
slaveof ip port

• 将 6379 作为主库， 6380 和 6381 为从库

slaveof 127.0.0.1 6379

• 
  • 使用主库写入数据正常，使用从库写入数据失败，默认从库是_只读_的
    自从 Redis 2.6 之后， slave 支持只读模式且默认开启。redis.conf 文件中的 replica-read-only 变量控制这个行为，且可以在运行时使用 CONFIG SET 来随时开启或者关闭。replica-read-only

127.0.0.1:6380> hset k1 f1 v1
(error) READONLY You can't write against a read only replica.

• 主机挂掉，重启就行，一切如初
• 从机重启是 master，需重设：slaveof 127.0.0.1 6379
  可以将配置增加到文件中，永久生效

slave-announce-ip 127.0.0.1
slave-announce-port 6379

复制原理

• slave 连接到 master 后会发送一个同步命令
• master 收到同步命令后会在后台开启一个进程把数据进行持久化，生成rdb文件
  • 同时将新接收到的客户端写的指令缓存起来
  • 等持久化完成就将rdb文件传输给 slave
• slave 收到文件将其保存到磁盘上，加载文件到内存
  • 然后 master 将缓存的命令发送给 slave
• 全量复制：所有的数据持久化为rdb文件，发送给 slave
• 增量复制：新的写执行发送给slave

但是只要是重新连接 master，一次完全同步（全量复制)将被自动执行

薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。

slaveof  <ip><port>

中途变更连接:会清除之前的数据，重新建立拷贝最新的
风险是一旦某个slave宕机，后面的slave都没法备份
主机挂了，从机还是从机，无法写数据了

反客为主

当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。

slaveof no one 将使得这个从属服务器关闭复制功能，并从从属服务器转变回主服务器，原来同步所得的数据集不会被丢弃。
利用『slaveof no one 不会丢弃同步所得数据集』这个特性，可以在主服务器失败的时候，将从属服务器用作新的主服务器，从而实现无间断运行。

127.0.0.1:6381> slaveof no one
OK
127.0.0.1:6381> get k1
"v1"

哨兵模式

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

• 调整为一主二仆模式，6379为主，6380和6381为从
• 自定义的 /myRedisConf 目录下新建 sentinel.conf 文件，名字不能错

sentinel monitor mymaster 127.0.0.1 6379 1
# mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。

• 启动哨兵

redis-sentinel  /myRedisConf/sentinel.conf

• 
• 主机挂掉会在从机中选举出新主机(大概10秒左右可以看到哨兵窗口日志，切换了新的主机)
  哪个从机会被选举为主机呢？根据优先级别：replica-priority 默认100，数值约低优先级越高(低版本为 slave-priority)
  原主机重启后会变为从机。

127.0.0.1:6379> shutdown
not connected>

• 复制延迟

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

• 故障恢复
  
  优先级在redis.conf中默认：replica-priority 100，值越小优先级越高
  偏移量是指获得原主机数据最全的
  每个redis实例启动后都会随机生成一个40位的runid
• 主从复制
  jedis 中使用

private static JedisSentinelPool jedisSentinelPool=null;
public static  Jedis getJedisFromSentinel(){
        if(jedisSentinelPool==null){
            Set<String> sentinelSet=new HashSet<>();
            sentinelSet.add("192.168.11.103:26379");
            JedisPoolConfig jedisPoolConfig =new JedisPoolConfig();
            jedisPoolConfig.setMaxTotal(10); //最大可用连接数
            jedisPoolConfig.setMaxIdle(5); //最大闲置连接数
            jedisPoolConfig.setMinIdle(5); //最小闲置连接数
            jedisPoolConfig.setBlockWhenExhausted(true); //连接耗尽是否等待
            jedisPoolConfig.setMaxWaitMillis(2000); //等待时间
            jedisPoolConfig.setTestOnBorrow(true); //取连接的时候进行一下测试 ping pong
            jedisSentinelPool=new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);
            return jedisSentinelPool.getResource();
        }else{
            return jedisSentinelPool.getResource();
        }
}

redis 集群

Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。
Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

制作6个实例

• 新建目录 redisCluster 将redis的配置文件复制到此目录

mkdir redisCluster
cp /myRedisConf/redis.conf /redisCluster

• 每个实例的基本配置

开启daemonize yes
Pid文件名字
指定端口
Log文件名字
Dump.rdb名字
Appendonly 关掉或者换名字

• 实例的集群配置

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

• 修改完6379的配置，复制多个文件

include /redisCluster/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

cp redis6379.conf ./redis6380.conf
cp redis6379.conf ./redis6381.conf
cp redis6379.conf ./redis6382.conf
cp redis6379.conf ./redis6383.conf
cp redis6379.conf ./redis6384.conf

• 在vim中使用查找替换修改另外5个文件

:%s/6379/6380

• 启动6个redis服务

redis-server redis6379.conf
redis-server redis6380.conf
redis-server redis6381.conf
redis-server redis6382.conf
redis-server redis6383.conf
redis-server redis6384.conf
[root@localhost redisCluster]# ps -ef|grep redis
root       2848      1  0 02:36 ?        00:00:00 redis-server *:6379 [cluster]
root       2854      1  0 02:36 ?        00:00:00 redis-server *:6380 [cluster]
root       2860      1  0 02:36 ?        00:00:00 redis-server *:6381 [cluster]
root       2866      1  0 02:36 ?        00:00:00 redis-server *:6382 [cluster]
root       2880      1  0 02:36 ?        00:00:00 redis-server *:6383 [cluster]
root       2886      1  0 02:36 ?        00:00:00 redis-server *:6384 [cluster]
root       2897   2512  0 02:36 pts/2    00:00:00 grep --color=auto redis

• 将6个节点合成一个集群
  查看节点文件是否正常生成

[root@localhost redisCluster]# ll
total 132
-rw-r--r--. 1 root root   114 Jul  7 02:36 nodes-6379.conf
-rw-r--r--. 1 root root   114 Jul  7 02:36 nodes-6380.conf
-rw-r--r--. 1 root root   114 Jul  7 02:36 nodes-6381.conf
-rw-r--r--. 1 root root   114 Jul  7 02:36 nodes-6382.conf
-rw-r--r--. 1 root root   114 Jul  7 02:36 nodes-6383.conf
-rw-r--r--. 1 root root   114 Jul  7 02:36 nodes-6384.conf
-rw-r--r--. 1 root root   186 Jul  7 02:16 redis6379.conf
-rw-r--r--. 1 root root   186 Jul  7 02:19 redis6380.conf
-rw-r--r--. 1 root root   186 Jul  7 02:20 redis6381.conf
-rw-r--r--. 1 root root   186 Jul  7 02:21 redis6382.conf
-rw-r--r--. 1 root root   186 Jul  7 02:22 redis6383.conf
-rw-r--r--. 1 root root   186 Jul  7 02:22 redis6384.conf
-rw-r--r--. 1 root root 83394 Jul  7 02:12 redis.conf

• 创建集群
  进入redis目录 /opt/redis-6.0.6/src ，执行以下命令

redis-cli --cluster create --cluster-replicas 1 192.168.83.128:6379 192.168.83.128:6380 192.168.83.128:6381 192.168.83.128:6382 192.168.83.128:6383 192.168.83.128:6384

此处不要用127.0.0.1， 请用真实IP地址
一个集群至少要有三个主节点。
选项 --cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。采用最简单的方式配置集群，一台主机，一台从机，正好三组。
分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在一个IP地址上。

• 
• 连接集群
  -c 采用集群策略连接，设置数据会自动切换到相应的写主机

# 由于集群是无中心的，我们可以选择任意主机端口进行连接 
redis-cli -c -p 6379

• 查看集群信息

cluster nodes

• 

slots插槽

一个 Redis 集群包含 16384 个插槽（hash slot）， 数据库中的每个键都属于这 16384 个插槽的其中一个，
集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
集群中的每个节点负责处理一部分插槽。 举个例子， 如果一个集群可以有主节点， 其中：
节点 A 负责处理 0 号至 5460 号插槽。
节点 B 负责处理 5461 号至 10922 号插槽。
节点 C 负责处理 10923 号至 16383 号插槽。

• 在redis-cli每次录入、查询键值，redis都会计算出该key应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。
  redis-cli客户端提供了 –c 参数实现自动重定向。
  如 redis-cli -c –p 6379 登入后，再录入、查询键值对可以自动重定向。
  不在一个slot下的键值，是不能使用_mget_ , _mset_等多键操作。

# 当前节点是6379，但是set的key经过计算后应是6387处理，所以重定向到6381
192.168.83.128:6379> set k1 v1
-> Redirected to slot [12706] located at 192.168.83.128:6381
OK
192.168.83.128:6381> 
# 由于set的多个key不是同一插槽，所以报错
192.168.83.128:6381> mset k2 v2 k3 v3
(error) CROSSSLOT Keys in request don't hash to the same slot
192.168.83.128:6381>

• 可以通过_{}_来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去

# 此时计算key是根据组的名称进行计算，也就是user
192.168.83.128:6381> mset k2{user} v2 k3{user} v3
-> Redirected to slot [5474] located at 192.168.83.128:6380
OK
192.168.83.128:6380>

• 查询集群中的值

# key在集群的插槽值
192.168.83.128:6380> cluster keyslot user
(integer) 5474
192.168.83.128:6380> cluster keyslot k1
(integer) 12706
# 返回插槽值中有多少key
# 上面查询k1的值就是12706，但是反过来根据值查询key返回0(为找到)，因为只能在自己的插槽区间进行查找，k1需要在6381进行查找
192.168.83.128:6380> cluster countkeysinslot 12706
(integer) 0
192.168.83.128:6380> cluster countkeysinslot 5474
(integer) 2
# 返回 count 个 slot 槽中的键
192.168.83.128:6380> cluster getkeysinslot 5474 5
1) "k2{user}"
2) "k3{user}"

故障恢复

关闭6380，连接6379查看结点信息，6380的从节点6383变为主节点

启动6380，再次查看信息，6380成为6383的从节点

如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续?

• 如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么 ，整个集群都挂掉
• 如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。

redis.conf 中的参数 cluster-require-full-coverage

集群的Jedis开发

即使连接的不是主机，集群会自动切换主机存储。主机写，从机读。
无中心化主从集群。无论从哪台主机写的数据，其他主机上都能读到数据。

public class JedisClusterTest {
  public static void main(String[] args) { 
     Set<HostAndPort>set =new HashSet<HostAndPort>();
     set.add(new HostAndPort("192.168.83.128",6379));
     JedisCluster jedisCluster=new JedisCluster(set);
     jedisCluster.set("k1", "v1");
     System.out.println(jedisCluster.get("k1"));
  }
}

集群优缺点

优点：

• 实现扩容
• 分摊压力
• 无中心配置相对简单

不足：

• 多键操作是不被支持的
• 多键的Redis事务是不被支持的。lua脚本不被支持
• 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

Redis应用问题解决

缓存穿透

问题描述

key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会压到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库

解决方案

一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义

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

缓存击穿

问题描述

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

解决方案

key可能会在某些时间点被超高并发地访问，是一种非常_热点_的数据。这个时候，需要考虑一个问题：缓存被_击穿_的问题

• 预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长
• 实时调整：现场监控哪些数据热门，实时调整key的过期时长
• 使用锁：
  • 就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。
  • 先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key

SET key value [EX seconds] [PX milliseconds] [NX|XX]
EX seconds – 设置键key的过期时间，单位时秒
PX milliseconds – 设置键key的过期时间，单位时毫秒
NX – 只有键key不存在的时候才会设置key的值
XX – 只有键key存在的时候才会设置key的值
注意: 由于SET命令加上选项已经可以完全取代SETNX, SETEX, PSETEX的功能，所以在将来的版本中，redis可能会不推荐使用并且最终抛弃这几个命令。

  - 当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；
  - 当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。

• 

缓存雪崩

问题描述

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
缓存雪崩与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key

解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕！

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

分布式锁

redis实现分布式锁

set sku:1:info “OK” NX PX 10000

• EX second ：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。
• PX millisecond ：设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。
• NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。
• XX ：只在键已经存在时，才对键进行设置操作。

1. 多个客户端同时获取锁（setnx）
2. 获取成功，执行业务逻辑{从db获取数据，放入缓存}，执行完成释放锁（del）
3. 其他客户端等待重试

编写代码 (SpringBoot)

先给num设置个值，模拟需要操作的业务

set num 10

springboot中自定义RedisTemplate

@GetMapping("testLock")
public void testLock(){
    //1获取锁，setne
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111");
    //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();
        }
    }
}

• 启动服务，使用ab工具进行测试

ab -n 1000 -c 100 http://192.168.3.15:8080/testLock

• 查看redis

127.0.0.1:6379> get num
"1010"

• 基本实现。

优化之设置锁的过期时间

问题：setnx刚好获取到锁，业务逻辑出现异常，导致锁无法释放
解决：设置过期时间，自动释放锁。

Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111",3L, TimeUnit.SECONDS);

问题：可能会释放其他服务器的锁。
场景：如果业务逻辑的执行时间是7s。执行流程如下

1. index1业务逻辑没执行完，3秒后锁被自动释放。
2. index2获取到锁，执行业务逻辑，3秒后锁被自动释放。
3. index3获取到锁，执行业务逻辑
4. index1业务逻辑执行完成，开始调用del释放锁，这时释放的是index3的锁，导致index3的业务只执行1s就被别人释放。
   最终等于没锁的情况。

解决：setnx获取锁时，设置一个指定的唯一值（例如：uuid）；释放前获取这个值，判断是否自己的锁

优化之UUID防误删

@GetMapping("/testLock")
public void testLock(){
    String uuid = UUID.randomUUID().toString();
    //1获取锁，setnx 传入值为uuid
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", uuid,3L, TimeUnit.SECONDS);
    //2获取锁成功、查询num的值
    if(lock){
        Object value = redisTemplate.opsForValue().get("num");
        //2.1判断num为空return
        if(ObjectUtils.isEmpty(value)){
            return;
        }
        //2.2有值就转成成int
        int num = Integer.parseInt(value+"");
        //2.3 具体业务 把redis的num加1
        redisTemplate.opsForValue().set("num", ++num);
        //2.4 释放前先判断锁是不是我自己的锁，del
        if (uuid.equals(redisTemplate.opsForValue().get("locl"))) {
            redisTemplate.delete("lock");
        }
    }else{
        //3获取锁失败、每隔0.1秒再获取
        try {
            Thread.sleep(100);
            testLock();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

问题：删除操作缺乏原子性。

a客户端获得的锁（键key）已经由于过期时间到了被redis服务器删除（在被删除前判断value和加锁的value一致），但是这个时候a客户端还去执行DEL命令。而b客户端已经在a设置的过期时间之后重新获取了这个同样key的锁，（由于之前判断通过了，可以执行删除操作）那么a执行DEL就会释放了b客户端加好的锁。
由于LUA脚本具有原子性，我们这里就采用它

优化之LUA脚本保证删除的原子性

@GetMapping("/testLockLua")
public void testLockLua() {
    String uuid = UUID.randomUUID().toString();
    String skuId = "25";
    String locKey = "lock:" + skuId;
    Boolean lock = redisTemplate.opsForValue().setIfAbsent(locKey, uuid, 3, TimeUnit.SECONDS);
    if (lock) {
        Object value = redisTemplate.opsForValue().get("num");
        if (ObjectUtils.isEmpty(value)) {
            return;
        }
        int num = Integer.parseInt(value + "");
        redisTemplate.opsForValue().set("num", ++num);
        // 定义lua 脚本
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        // 使用redis执行lua执行
        DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
        redisScript.setScriptText(script);
        // 设置一下返回值类型 为Long
        // 因为删除判断的时候，返回的0,给其封装为数据类型。如果不封装那么默认返回String 类型，
        // 那么返回字符串与0 会有发生错误。
        redisScript.setResultType(Long.class);
        // 第一个要是script 脚本 ，第二个需要判断的key，第三个就是key所对应的值。
        redisTemplate.execute(redisScript, Arrays.asList(locKey), uuid);
    } else {
        // 其他线程等待
        try {
            // 睡眠
            Thread.sleep(1000);
            // 睡醒了之后，调用方法。
            testLockLua();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

命令 SET resource-name anystring NX EX max-lock-time 是一种用 Redis 来实现锁机制的简单方法。
如果上述命令返回OK，那么客户端就可以获得锁（如果上述命令返回Nil，那么客户端可以在一段时间之后重新尝试），并且可以通过DEL命令来释放锁。
客户端加锁之后，如果没有主动释放，会在过期时间之后自动释放。
可以通过如下优化使得上面的锁系统变得更加鲁棒：

• 不要设置固定的字符串，而是设置为随机的大字符串，可以称为token。
• 通过脚本删除指定锁的key，而不是DEL命令。

上述优化方法会避免下述场景：a客户端获得的锁（键key）已经由于过期时间到了被redis服务器删除，但是这个时候a客户端还去执行DEL命令。而b客户端已经在a设置的过期时间之后重新获取了这个同样key的锁，那么a执行DEL就会释放了b客户端加好的锁。

解锁脚本的一个例子将类似于以下：

if redis.call("get",KEYS[1]) == ARGV[1]
then
    return redis.call("del",KEYS[1])
else
    return 0
end

value的值必须是随机数主要是为了更安全的释放锁，释放锁的时候使用脚本告诉Redis:只有key存在并且存储的值和我指定的值一样才能告诉我删除成功

总结

使用：

• 加锁（加锁时设置过期时间，value为随机数）
• 使用lua释放锁
• 失败重试

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

• 互斥性。在任意时刻，可以有一个客户端可以获得锁
• 不会发生死锁。即使一个客户端在持有锁的期间崩溃了而没有主动解锁，也能保证其他客户端能正常加锁
• 解铃还须系铃人。加锁和解锁必须是同一客户端，自己的客户端不能把别人的锁给解了
• 加锁和解锁必须具有原子性

Redis6.0新功能

ACL

Redis ACL是Access Control List（访问控制列表）的缩写，该功能允许根据可以执行的命令和可以访问的键来限制某些连接。
在Redis 5版本之前，Redis 安全规则只有密码控制 还有通过rename 来调整高危命令比如 flushdb ， KEYS* ， shutdown 等。Redis 6 则提供ACL的功能对用户进行更细粒度的权限控制 ：
（1）接入权限:用户名和密码
（2）可以执行的命令
（3）可以操作的 KEY
参考官网：https://redis.io/topics/acl

命令

• acl list 用户权限列表
  
• acl cat 查看添加权限指令类别
  
  加参数类型名可以查看类型下具体命令
  
• acl whoami 查看当前用户
  
• 使用aclsetuser命令创建和编辑用户ACL
  • acl setuser user1 创建新用户默认权限
• 
  在上面的示例中，我们没有指定任何规则。如果用户不存在，这将使用just created的默认属性来创建用户。如果用户已经存在，则上面的命令将不执行任何操作。
  • acl setuser user2 on >password ~cached:* +get 设置有用户名、密码、ACL权限、并启用的用户
    
  • 切换用户，验证权限
    

IO多线程

Redis6终于支撑多线程了，告别单线程了吗？
IO多线程其实指客户端交互部分的网络IO交互处理模块多线程，而非执行命令多线程。Redis6执行命令依然是单线程。

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

io-threads-do-reads  yes 
io-threads 4

工具支持 Cluster

之前老版Redis想要搭集群需要单独安装_ruby环境_，Redis 5 将 redis-trib.rb 的功能集成到 redis-cli 。另外官方 redis-benchmark 工具开始支持 cluster 模式了，通过多线程的方式对多个分片进行压测。