0.bug

1、RedisDesktopManager连接Linux中的redis的问题：

连接失败，在redis解压包下有redis.conf配置文件，其中bind配置是远程连接服务。设置为bind=0.0.0.0，即允许所有ip地址连接该linux下的redis。注意，在配置好后，使用ps -ef | grep redis 查看对应ip地址和端口号。

如果还是显示127.0.0.1等本机ip地址，则重启Linux即可

2、使用VPN之后导致Linux服务器无法远端连接：

关闭VPN即可，还有什么办法吗？是否可以通过固定ip地址的方法来解决？

暂待解决

3、关于本地localhost中的Redis 和Linux下的Redis

3.1本地的Locahost需要直接登录即可，设置密码123456

Linux下redis密码为123456

redis-cli -p 6379 登录后，输入AUTH 123456 进行登录

3.2 Linux下redis

redis-5.0.4安装包和安装路径在/usr/local/src/redis-5.0.4/src下，

启动程序redis-server和redis-cli在/usr/local/bin下

**运行：**在安装完redis后，自带启动redis命令

Shell

redis-cli -h 192.168.200.131 -p 6379 -a 123456
# 其中-h 192.168.200.131为连接的redis节点的IP地址，默认是127.0.0.1
# -p 6379 端口号
# -a 123456 为登录密码。初始无密码

初始设置（问题）：

1.默认端口号为6379，在公司中，肯定不是默认端口号

2.默认密码
Shell
# 初始登录无密码，只需要redis-cli -p 6379即可
# 进入后通过config get requirepass 查看命令。config set requirepass *** 修改密码
3.redis保存文件的目录：保存日志，命令，持久化的目录路径

4.日志文件

5.先启动redis-server 后台服务，再启动redis-cli脚手架。（但是在Linux系统命令端下，启动了后台服务，退出就是退出了的）

在基础上做的修改（解决上述问题）：

后台启动：前提是必须修改配置文件(/usr/local/src/redis-5.0.4/redis.conf)

问题1~4等问题有两种解决方案：

**解决方法一：**进入redis-cli后，config get xxx ？？？，config set xxx ？？？

初学不推荐，因为这是直接修改，无备份

**解决方法二：**先备份，再进入redis.conf中进行修改

(1) 先备份一份（在安装目录下：/usr/local/src/redis-5.0.4/redis.conf)）

Shell

cp redis.conf redis.conf.bak

(2) 修改redis.conf

Shell

vi redis.conf

在进入vi模式后。按/进入查找模式，按i进行查找

(3) 运行

Shell

cd /usr/local/src/redis-6.2.6
redis-server redis.conf

(4) 查看是否启动

TEXT

ps -ef | grep redis

(5) 停止redis -9:强制但是不安全

TEXT

kill -9 进程号

问题5、修改自启动：

(1) 新建系统服务文件

Shell

vi /etc/systemd/system/redis.service

内容：

Shell

[Unit]
Description=redis-server
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/bin/redis-server /usr/local/src/redis-6.2.6/redis.conf
PrivateTmp=true

[Install]
WantedBy=multi-user.target

(2) 重新加载系统服务

Shell

systemctl daemon-reload

(3)启动

Shell

systemctl start redis

(4)查看状态

Shell

systemctl status redis

(5) 设置开机自启

Shell

systemctl enable redis

4、在vim模式下，总是喜欢按Ctrl+S保存，但是在Linux下，这是锁定命令。按住ctrl+q退出锁定模式

4、无法访问yum源问题：

在安装yum源时，报错如下：

TEXT

 yum install -y wget && wget -O install.sh https://download.bt.cn/install/install_6.0.sh && sh install.sh 12f2c1d72

ImportError: /lib64/libcrypto.so.10: version `OPENSSL_1.0.2' not found (required by /www/server/panel/pyenv/lib/python3.7/lib-dynload/_ssl.cpython-37m-x86_64-linux-gnu.so)

Loaded plugins: fastestmirror, langpacks
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os error was
14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Name or service not known"


 One of the configured repositories failed (Unknown)

Loaded plugins: fastestmirror, langpacks
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os error was
14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Name or service not known"


 One of the configured repositories failed (Unknown),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:
 
 1. Contact the upstream for the repository and get them to fix the problem.
                                                                                                    
 2. Reconfigure the baseurl/etc. for the repository, to point to a working
    upstream. This is most often useful if you are using a newer
    distribution release than is supported by the repository (and the
    packages for the previous distribution release still work).
                                                                                                    
 3. Disable the repository, so yum won't use it by default. Yum will then
    just ignore the repository until you permanently enable it again or use
    --enablerepo for temporary usage:
                                                                                                    
        yum-config-manager --disable <repoid>
                                                                                                    
 4. Configure the failing repository to be skipped, if it is unavailable.
    Note that yum will try to contact the repo. when it runs most commands,
    so will have to try and fail each time (and thus. yum will be be much
    slower). If it is a very temporary problem though, this is often a nice
    compromise:
                                                                                                    
        yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
Cannot find a valid baseurl for repo: base/7/x86_64

解决方法：换源

看到报错日志中加粗的字体，命令行ping mirrorlist.centos.org 不通。试着ping www.baidu.com是正常的，说明DNS解析没问题。基本确认是yum源的问题。

CentOS7更换镜像源 1、先安装wget

Bash

yum install -y wget

2、打开阿里镜像http://mirrors.aliyun.com/ 点击，帮助，查看详情：

3、下载CentOS 7的对应的repo文件

Bash

wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
#或者
curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo

4、更新镜像源

Bash

yum clean all

yum makecache

yum -y update

执行完上面三行命令就好了

2.安装Redis

任何一个window或Linux的安装都是让人要死。在初学中学到了大师的命令，那样要死要活的安装命令

==Redis的命令为原子性，单线程==

2.1 安装redis过程

1、window端准备安装包

redis-5.0.4.tar.gz

2、使用FinalShell连接服务器并上传安装包

Redis是基于C编写，所以需要先安装Redis所需的gcc依赖

Bash

yum install -y gcc 
# 如果报错重启一下网络
sudo systemctl restart network
#或者更新一下yum源

安装包上传到usr/local/src

3、解压并安装

cd usr/local/src

解压命令：

tar -zxvf redis-5.0.4.tar.gz

cd到redis的目录：

cd redis-5.0.4/

编译和运行

make && make install

4、配置redis信息

前提是必须修改配置文件(/usr/local/src/redis-5.0.4/redis.conf)

(1) 先备份一份

cp redis.conf redis.conf.bak

(2) 修改

vi redis.conf

修改内容为：

port xxxx # 端口号要确认

dir . # 工作目录（默认即可）

database 1 # （默认即可）

maxmemory 512mb # 设置redis使用内存

logfile “redis.log”

bind 0.0.0.0 # （设置路由地址，这是必须的。为方便设置为全局可访问）

daemonize yes # 开启守护线程

requirepass 123456 # 开启密码

(3) 运行

Bash

cd /usr/local/src/redis-5.0.4
redis-server redis.conf

(4) 查看是否启动

ps -ef | grep redis

（5）停止redis -9:强制但是不安全

kill -9 进程号

注意：

Redis daemonize介绍 1、daemonize介绍

A、redis.conf配置文件中daemonize守护线程，默认是NO。
B、daemonize是用来指定redis是否要用守护线程的方式启动。

2、daemonize 设置yes或者no区别

daemonize:yes:redis采用的是单进程多线程的模式。当redis.conf中选项daemonize设置成yes时，代表开启守护进程模式。在该模式下，redis会在后台运行，并将进程pid号写入至redis.conf选项pidfile设置的文件中，此时redis将一直运行，除非手动kill该进程。
daemonize:no: 当daemonize选项设置成no时，当前界面将进入redis的命令行界面，exit强制退出或者闭连接工具(putty,xshell等)都会导致redis进程退出。

5.redis设置成系统服务（可开机启动）

(1) 新建系统服务文件

vi /etc/systemd/system/redis.service

内容：

[Unit] Description=redis-server After=network.target

[Service] Type=forking ExecStart=/usr/local/bin/redis-server /usr/local/src/redis-5.0.4/redis.conf PrivateTmp=true

[Install] WantedBy=multi-user.target

(2) 重新加载系统服务

TEXT

systemctl daemon-reload

(3)启动

TEXT

systemctl start redis

(4)查看状态

TEXT

systemctl status redis

(5) 设置开机自启

systemctl enable redis

2.2 redis在Linux下的基本命令

启动Redis服务

Redis服务的启动方式有两种：通过命令行手动启动和作为系统服务启动。

手动启动Redis

手动启动Redis，可以使用以下命令：

Shell

redis-server /etc/redis/redis.conf

在这个命令中，/etc/redis/redis.conf是Redis的配置文件路径。通过这个命令，Redis将会按照配置文件中的设置启动。

作为系统服务启动

在大多数Linux发行版中，Redis会作为一个systemd服务运行。可以使用以下命令启动Redis服务：

Shell

sudo systemctl start redis

使用这条命令后，Redis服务将在后台运行，并会遵循配置文件中的设置。

验证Redis是否在运行

你可以通过以下命令检查Redis的状态：

Shell

sudo systemctl status redis

若Redis正在运行，你会看到类似以下的输出：

● redis.service - Advanced key-value store Loaded: loaded (/lib/systemd/system/redis.service; enabled; vendor preset: enabled) Active: active (running) ...

此外，也可以使用Redis的命令行客户端进行验证：

Shell

redis-cli ping

若返回结果为 PONG，则表明Redis服务正常运行。

停止Redis服务

在需要停止Redis服务时，有同样的两种方式。

手动停止Redis

如果你手动启动了Redis，可以使用 CTRL+C 在命令行界面中停止它，或者使用以下命令：

Shell

redis-cli shutdown

这个命令会优雅地关闭Redis服务器。

作为系统服务停止

如果Redis作为系统服务运行，可以使用以下命令停止它：

Shell

sudo systemctl stop redis

同样，你可以通过再次执行 sudo systemctl status redis 来确认Redis是否已经成功停止。

Redis的管理命令

除了启动和停止Redis，Redis还提供了一些管理命令，可以帮助你更好地维护和监控服务。

常用管理命令

查看当前的连接数：

Shell

redis-cli info clients

查看内存使用情况：

Shell

redis-cli info memory

获取当前数据库的大小：

Shell

redis-cli dbsize

1.Redis基础命令篇：

1.1 通用命令

1.查看指定的key

语法：keys pattern

匹配查询：

符号	含义
？	匹配一个字符
*	匹配0到任意一个字符
[]	区间匹配，使用“-”表示范围。如a[a-c]可以匹配到aa,ab,ac
\	转义符，如匹配？，则使用“\？”，代表？

示例：

keys * (查询所有的键)

缺点：该命令在大规模使用的时候，很明显不如于可视化界面。

2.exists：判断一个键是否存在（存在返回1，反正为0）

**语法：**exists key

3.删除键del

语法：del key [key ...]

返回值是删除成功的数量。

示例：

删除k1,k2,k3,k4 (k4是不存在)

Shell

del k1,k2,k3,k4
结果：3

del 删除可以去保证删除的健壮性

4.type：获取键值的数据类型

语法：type key [key ...]

5.help :查看语法

语法：help 空格 tab键

示例：

6.expire ：设置（或更新）key的生存时间

语法：expire key seconds （以秒为单位）

示例：

Shell

expire name  2（key为name的生存时间为2s）

注：永久创建的k-v生存时间为-1（永久，即未设置生存期）

语法：pexpire key milliseconds（和第1个区别在于可以设置毫秒级）

语法：expireat key timestamp(也是设置过期时间，秒为单位)

语法：pexpireat key milliseconds-timestamp（设置过期时间，毫秒为单位)

上述命令即可以设置生存时间，也可以更新生存时间

7.ttl：查看生存时间

语法：ttl key

返回生存时间seconds

大于0的数字：剩余生存时间，单位为秒

-1 ：没有生存时间，永久存储

-2 ：数据已经被删除

语法：pttl key

返回生存时间毫秒为单位

8. 清除生存时间

语法：persist key

将key的失效性改为永久

9.为key改名

rename key newkey
renamenx key newkey （如果新名称已存在则不修改）

nx= not exist

10.对所有key排序

sort （排list、set、sorted_set中的元素）

11.数据库通用操作：

一共有16个数据库，0-15

切换数据库（不切换则默认使用0号数据库）
- select index
其他操作
- quit （退出当前数据库）
- ping （测试服务器是否连通）
- echo message （输出信息）
数据移动（将当前数据库的指定数据移动到目标数据库）
- move key db
数据清除
- dbsize （查看当前数据库有多少个key）
- flushdb （清除当前数据）
- flushall （清除所有数据）

12.key的重复问题

key是由程序员定义的
redis在使用过程中，伴随着操作数据量的增加，会出现大量的数据以及对应的key
数据不区分种类，类别混杂在一起，极易出现重复或冲突

解决方案

redis为每个服务提供有16个数据库，编号从0到15
每个数据库之间的数据相互独立

Redis 事务命令

下表列出了 redis 事务的相关命令：序号命令及描述

1 DISCARD

取消事务，放弃执行事务块内的所有命令。

2 EXEC

执行所有事务块内的命令。

3 MULTI

标记一个事务块的开始。

4 UNWATCH

取消 WATCH 命令对所有 key 的监视。

5 WATCH key [key …]

监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

Redis五大数据类型

redis自身是一个Map，其中所有的数据都是采用key：value的形式存储
数据类型指的是存储的数据的类型，也就是value部分的类型，key部分永远都是字符串

在这里插入图片描述

1.2.String基本命令

定义：

存储的数据:单个数据，最简单的数据存储类型，也是最常用的数据存储类型

存储数据的格式:一个存储空间保存一个数据

存储内容:通常使用字符串，如果字符串以整数的形式展示，可以作为数字操作使用

存储大小：一个字符串类型键允许存储的数据最大容量是512MB。

基本命令：

`set key value`

添加或者修改已经存在的一个String类型的键值对

`get key`

根据key获取String类型的value

`del key`

删除

`mset key1 value1 value2 ...`

批量添加多个String类型的键值对

`mget key1 key2 ....`

根据多个key获取多个String类型的value

`incr key` :自增整型的value，步长为1

让一个整型的key自增1

`incrby key num`:自增整型的value，步长为num（自定义）

`incrbyfloat key num`：自增浮点型的value，步长为num（自定义）

`decr key ：`

自减整型的value，步长为1

`decrby key num ：`

自减整型的value，步长为num（自定义）

`setnx`：添加一个String类型的键值对，前提是这个key不存在，否则不执行

`setex`：添加一个String类型的键值对，并且指定有效期

`strlen key:`

获取数据字符个数

`append key value`

追加信息到原始信息后部（如果原始信息存在就追加，否则新建）

总结版命令

下表列出了一些用于在Redis中管理字符串的基本命令。

编号命令描述说明

SET key value 此命令设置指定键的值。
GET key 获取指定键的值。
GETRANGE key start end 获取存储在键上的字符串的子字符串。
GETSET key value 设置键的字符串值并返回其旧值。
GETBIT key offset 返回在键处存储的字符串值中偏移处的位值。
MGET key1 [key2…] 获取所有给定键的值
SETBIT key offset value 存储在键上的字符串值中设置或清除偏移处的位
SETEX key seconds value 使用键和到期时间来设置值
SETNX key value 设置键的值，仅当键不存在时
SETRANGE key offset value 在指定偏移处开始的键处覆盖字符串的一部分
STRLEN key 获取存储在键中的值的长度
MSET key value [key value …] 为多个键分别设置它们的值
MSETNX key value [key value …] 为多个键分别设置它们的值，仅当键不存在时
PSETEX key milliseconds value 设置键的值和到期时间(以毫秒为单位)
INCR key 将键的整数值增加1
INCRBY key increment 将键的整数值按给定的数值增加
INCRBYFLOAT key increment 将键的浮点值按给定的数值增加
DECR key 将键的整数值减1
DECRBY key decrement 按给定数值减少键的整数值
APPEND key value 将指定值附加到键

key的多层结构：

如果Value是一个Java对象，例如一个User对象，则可以将对象序列化为JSON字符串后存储：

KEY	VALUE
heima:user:1	{“id”:1, “name”: “Jack”, “age”: 21}
heima:product:1	{“id”:1, “name”: “小米11”, “price”: 4999}

一旦我们向redis采用这样的方式存储，那么在可视化界面中，redis会以层级结构来进行存储，形成类似于这样的结构，更加方便Redis获

取数据

Shell

set heima:user:1 '{"id":1,"name":"jack","age":21}'

业务场景：1

大型企业级应用中，分表操作是基本操作，使用多张表存储同类型数据，但是对应id必须保证统一性，不能重复。Oracle数据库具有sequence设定，可以解决该问题，但是MYSQL数据库并不具有类似的机制那么如何解决？

在这里插入图片描述

解决方案

设置数值数据增加指定范围的值
- incr key
- incrby key increment
- incrbyfloat key increment
设置数值数据减少指定范围的值
- decr key
- decrby key increment

string作为数值操作

string在redis内部存储默认就是一个字符串，当遇到增减类操作incr，decr时会转成数值型进行计算。

redis所有操作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发带来的数据影响

注意：按数值进行操作的数据，如果原始数据不能转成数值，或超越了redis数值上限范围，将报错。9223372036854775807（java中

long型数据最大值，long.MAX_VALUE）

业务场景2（限时投票）：

在这里插入图片描述

我们为投票的人设置news_id，并为他设置投票倒数时长，时长一到，id擦掉

解决方案：

设置数据具有指定的生命周期
setex key seconds value
psetex key milliseconds value

在这里插入图片描述

如果在时间之内又重新设置数据的生命周期，则之前的设置作废，按照新的生命周期来

我们得到结论 redis控制数据的生命周期，通过数据是否失效控制业务行为，适用于所有具有时效性限定控制的操作

string类型数据操作的注意事项

数据操作不成功的反馈与数据正常操作之间的差异

表示运行结果是否成功

（integer）0->false 失败

（integer）1->true 成功

表示运行结果值

（integer）3->3 3个

（integer）1->1 1个

数据未获取到

（nil）等同于null

数据最大存储量

512MB

数值计算最大范围（java中的long$=2^{63}-1$的最大值）

9223372036854775807

综合案例

主页高频访问信息显示控制，例如新浪微博大V主页显示粉丝数与微博数量

在这里插入图片描述

解决方案：

在redis中为大V用户设定用户信息，以用户主键和属性值作为key，后台设定定时刷新策略即可

在这里插入图片描述

表名+主键名+主键值+属性名来作为它的key

在redis中以json格式存储大V用户信息，定时刷新（也可以使用hash类型）

在这里插入图片描述

在这里插入图片描述

redis应用于各种结构型和非结构型高热度数据访问加速

在这里插入图片描述

1.3 Hash类型

本身Redis就是一个key-value的结构，而hash的value还是一个key-value的结构（Map<String,Map<String,String>>）

Redis hash 是一个string类型的field和value的映射表，hash特别适合用于存储对象。

Redis 中每个 hash 可以存储 $2^{32} - 1$ 键值对（40多亿）。

定义：

关键：每个字段独立存储，可以针对性做CRUD

hash表的结构：key（键）-field（字段）-value（值）

数据操作的注意事项

1.hash类型下的value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为（nil）

2.每个hash可以存储$2^{23}-1$个键值对

3.hash类型十分贴近对象的数据存储形式，并且可以灵活添加对象属性。但hash设计初衷不是为了存储大量对象而设计的，切记不可滥用，更不可以将hash作为对象列表使用

4.hgetall操作可以获取全部属性，如果内部field过多，遍历整体数据效率就会很低，有可能成为数据访问瓶颈

hash基础操作命令

在String类型上加H

添加/修改数据(建立值)
- hset key field value
字段 field 不存在时，设置哈希表字段的值。
- hsetnx key field value
- hsetnx = hash(h) set not exist
获取数据
- hget key field
- hgetall key =hget +all
删除数据
- hdel key field1 [field2]
添加/修改多个数据
- hmset key field1 value1 field2 value2
获取多个数据
- hmget key field1 field2
获取哈希表中字段的数量
- hlen key
获取哈希表中是否存在指定的字段
- hexists key field

hash扩展操作命令

获取哈希表中所有字段名或字段值
- hkeys key (获取所有哈希表中的字段)
- hvals key (获取哈希表中所有值)
- hlen key (获取哈希表中字段的数量)
设置指定字段的数值数据增加指定范围的值
- hincrby key field increment
- hincrbyfloat key field increment
迭代哈希表中的键值对
- HSCAN key cursor [MATCH pattern] [COUNT count]

示例：

Shell

// 插入hash表
hset heima:user:3 name Lucy
hset heima:user:3 age 22
hset heima:user:3 age 17

1.4 list类型

定义:

一个列表最多可以包含 $2^{32} - 1$ 个元素 (4294967295, 每个列表超过40亿个元素)。

数据操作注意事项

list中保存的数据都是string类型的，数据总容量是有限的，最多$2^{32}-1$个元素
list具有索引的概念，但是操作数据时通常以队列的形式进行入队出队操作，或以栈的形式进行入栈出栈操作
获取全部数据操作结束索引设置为-1
list可以对数据进行分页操作，通常第1页的信息来自于list，第2页及更多的信息通过数据库的形式加载

List基本命令

以l带头的基本命令

默认插入是从左边入队，右边出队（可以看成==双向栈==）

添加/修改数据
- lpush key value1 [value2]… （从左边进）
- rpush key value1 [value2]…（从右边进）
- lpushx key value （将一个值插入到已存在的列表头部）
- rpushx key value （为已存在的列表添加值）
获取数据
- lrange key start stop（不知道多少个数据时stop设置为-1，负数代表倒数第一个元素）（获取下标范围内的元素）
- lindex key index（通过索引获取列表中的单个元素）
- llen key（获取列表长度）
获取并移除数据
- lpop key（从左边出一个元素，返回值为key）
- rpop key（从右边出一个元素，返回值为key）

既然有push多个元素，有pop多个元素吗？

移出并获取列表的第一个元素，如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
- blpop key1 [key2 ] timeout
- brpop key1 [key2 ] timeout
列表A从右边出pop值，再将值向左边进push到列表B，如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
- brpoplpush source destination timeout
移除列表的最后一个元素，并将该元素添加到另一个列表并返回
- rpoplpush source destination（destination为需要添加到的列表）
仅移除指定数据
- lrem key count value (l代表list，rem代表为remove，count代表删除几个value)

插入：

在列表的元素前或者后插入元素
- linsert key before|after pivot value（pivot是轴，即前后插入的元素位置，value为值）
通过索引设置列表元素的值
- lset key index value
对一个列表进行修剪(trim)，就是说，让列表只保留指定区间内的元素，不在指定区间之内的元素都将被删除。
- trim key start stop

场景1：

微信朋友圈点赞，要求按照点赞顺序显示点赞好友信息

思路：正常的左进右出即可

业务场景2:

1.5 set

定义：

在这里插入图片描述

set类型数据操作的注意事项

1、类比java中的set

新的存储要求：存储大量的数据，在查询方面提供更高的效率
需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询
set类型：与hash存储结构完全相同，仅存储键，不存储值（nil），并且值是不允许重复的

为什么不用list的原因： list内部的数据结构是链表，查询慢，增删快，虽然能存取大量数据，但是读取效率低下

2、

set类型不允许数据重复，如果添加的数据在set中已经存在，将只保留一份
set虽然和hash的存储结构相同，但是无法启用hash中存储值的空间

3、优点：==set是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。==

缺点：无序，查询制定元素难；

基本操作

添加数据（添加一个或多个成员）
- sadd key member1 [member2]（这里的member本质上就是字段field）
获取全部数据
- smembers key (返回集合中的所有成员)
获取一个或多个随机数
- srandmember key [count] （count可指定获取几个数）
获取集合数据总量
- scard key (获取集合的成员数)
删除数据
- srem key member1 [member2]（删除一个或多个）
- spop key(移除并返回集合中的一个随机元素,因为set集合本身无序，所以pop就是移除随机元素)
迭代集合中的元素
- sscan key cursor [MATCH pattern] [COUNT count]
判断集合中是否包含指定数据
- sismember key member

交、并、差集图示

在这里插入图片描述

求两个集合的交、并、差集

sinter key1 [key2]
sunion key1 [key2]
sdiff key1 [key2]

求两个集合的交、并、差集并存储到指定集合中

sinterstore destination key1 [key2]
sunionstore destination key1 [key2]
sdiffstore destination key1 [key2]

将指定数据从原始集合中移动到目标集合中

smove source destination member

由此我们可以得到

redis应用于同类信息的关联搜索、二度关联搜索、深度关联搜索

练习：

业务场景1：

每位用户首次使用今日头条时会设置3项爱好的内容，但是后期为了增加用户的活跃度，兴趣点。必须让用户对其他信息类别产生兴趣，增加客户留存度，如何实现？

业务分析

系统分析出各个分类的最新或最热点信息条目并组织成set集合
随机挑选其中部分信息
配合用户关注信息分类中的热点信息组织成展示的全信息集合

解决方案

随机获取集合中指定数量的数据
- srandmember key [count]
随机获取集合中的某个数据并将该数据移出集合
- spop key

由此可以得出

redis应用于随机推荐类信息检索，例如热点歌单推荐，热点新闻推荐，热卖旅游线路，应用app，大v推荐等

业务场景2：

在这里插入图片描述

推荐共同关注的好友，提高用户留存率

解决方案

交、并、差集图示

业务场景3：

集团公司共具有12000名员工，内部OA系统中具有700多个角色，3000多个业务操作，23000多种数据，每位员工具有一个或多个角色，如何快速进行业务操作的权限检验？

在这里插入图片描述

这里不考虑其他的，只是用redis作为校验，证明它可以做到这件事，真实开发会有其他框架完成

解决方案

在这里插入图片描述

校验思想1：

我们设定一个用户有两个角色，每个角色有2-3个不同权限，将用户权限通过sunionstore存储到 uid:007中，判断权限可以直接判断uid:007中是否存在，存在则有权限，不存在则无权限

在这里插入图片描述

校验思想2：

通过sismember 命令判断是否具有该权限

在这里插入图片描述

第一种思想是数据存储方提供数据，然后将校验的业务操作放到程序的业务层去进行

第二种思想是直接把要校验的数据放在数据这一端校验，直接把结果给你

第一种形式耦合度较低，分工明确，数据和业务分散开来，而第二种把业务校验的工作糅合到数据中去了，对于redis，还是提供基础数据而非提供校验结果比较好

由此我们可以得出

==redis应用于同类型不重复数据的合并操作==

1.6 sorted_set（zset）

需求：

新的存储需求：数据排序有利于数据的有效展示，需要提供一种可以根据自身特征进行排序的方式
需要的存储结构：新的存储模型，可以保存可排序的数据
sorted_set类型：在set的存储结构基础上添加可排序字段

解决方案：

Redis的Sorted_set是一个可排序的set集合，与java中的Treeset有些类似，但底层数据结构却差别很大。Sortedset中的每一个元素都带

有一个score属性，可以基于score属性对元素排序，底层的实现是一个跳表(SkipList)加 hash表Sortedset具备下列特性:

可排序（每个元素都会关联一个double类型的score分数，而且可重复）
元素（key）不重复（和set一样）
查询速度快（和set一样，有序集合的成员是唯一的）

==集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。集合中最大的成员数为 $2^{32} - 1$ (4294967295, 每个集合可存储40多亿个成员)。==

==而对应socre/rank 操作对应跳表实现（查/删/插），为O(log n)==

==范围查询为O（log n +m）即定位（跳表遍历相当于二分查找）+遍历==

在这里插入图片描述

因为Sortedset的可排序特性，经常被用来实现排行榜这样的功能。

基本操作：

添加数据
- zadd key score1 member1 [score2 member2]（添加一个或多个元素到sorted set，如果已经存在则更新其score值）
获取全部数据
- zrange key start stop [WITHSCORES] （按从小到大的顺序展示）
- zrevrange key start stop [WITHSCORES] （按从大到小的顺序展示）
删除数据
- zrem key member [member …]（删除sorted set中的一个指定元素）
按条件获取数据
- zrangebyscore key min max [WITHSCORES] [LIMIT]（按照score排序后，获取指定score范围内的元素）
- zrevrangebyscore key max min [WITHSCORES]（返回有序集中指定分数区间内的成员，分数从高到低排序）
- zscore key member:获取sorted set中的指定元素的score值
- zrank key member:获取sortedset 中的指定元素的增序排名（索引）
- zrevrank key member 获取sortedset 中的指定元素的降序排名（索引）
- zrange key min max [WITHSCORES] (按照score排序后，获取指定排名范围内的元素)
- zrangebylex key min max [limit offsert count ] (通过字典区间返回有序集合的成员)
- zlexcount key min max (在有序集合中计算指定字典区间内成员数量)
rev代表逆序（单词应该是反转的意思）

lex代表字典序（lexicographical order）

比如：ZRANGEBYLEX key min max [LIMIT offset count]是按照字典序进行范围查询的，而不是按照分数（score）进行范围查询。这使得它非常适合用于需要按字母顺序检索数据的场景。
按条件删除数据
- zremrangebyrank key start stop （按索引删除）
- zremrangebyscore key min max （按范围删除）
- zremrangebylex key min max(移除有序集合中给定的字典(分数)区间的所有成员)
自增
- zincrby key increment member（让sorted set中的指定元素自增，步长为指定的increment值）
迭代（遍历）
- zscan key cursor [MATCH pattern] [COUNT count ]
获取集合数据总量
- zcard key（获取sorted set中的元素个数）
- zcount key min max（统计score值在给定范围内的所有元素的个数）
集合交、并、差操作
- zinterstore destination numkeys key [key …]（计算给定的一个或多个有序集的交集并将结果集存储在新的有序集合 key 中）
- zunionstore destination numkeys key [key …]
- zdiffstore destination numkeys key [key …]

注意

min与max用于限定搜索查询的条件
start与stop用于限定查询范围，作用于索引，表示开始和结束索引
offset与count用于限定查询范围，作用于查询结果，表示开始位置和数据总量

即offset 表示跳过前面多少个元素，count 表示返回多少个元素。

sorted_set类型数据操作的注意事项

score保存的数据存储空间是64位，如果是整数范围是-9007199254740992~9007199254740992
score保存的数据也可以是一个双精度的double值，基于双精度浮点数的特征，可能会丢失精度，使用时候要慎重
sorted_set底层存储还是基于set结构的，因此数据不能重复，如果重复添加相同的数据，score值将被反复覆盖，保留最后一次修改的结果。

由此可知

redis应用于基于时间顺序的数据操作，而不关注具体时间

业务场景1：

票选广东十大杰出青年，各类综艺选秀海选投票

各类资源网站TOP10（电影，歌曲，文档，电商，游戏等）

聊天室活跃度统计

**分析：**为所有参与排名的资源建立排序依据

解决方案：

获取数据对应的索引（排名）
- zrank key member
- zrevrank key member
score值获取与修改
- zscore key member
- zincrby key increment member

我们设置电影aa,bb,cc并对其票数进行排名，并对aa票数进行+1操作

Shell

zadd movies 143 a 97 bb 201 cc
zrank movies bb #(默认从小到大排序，且下标初始为0)
# 0
zrevrank movies bb
# 2
zsorce movies aa #查询分数 
# "143"
zincrby movies 1 aa
# 设置自增为1，为成员aa中的values+1
#所以结果为“144”

1.7 Redis位图(bitmap)

由 0 和 1 表示的二进制位的 bit 数组

介绍

用String类型作为底层数据结构实现的一种统计二值状态的数据类型
位图本质是数组，它是基于String数据类型的按位的操作。该数组由多个二进制位组成，每个二进制位都对应一个偏移量(我们称之为一个索引)
Bitmap支持的最大位数是$2^{32}$位，它可以极大的节约存储空间，使用512M内存就可以存储多达42.9亿的字节信息(2的32次方 = 4294967296)
基本命令

Bash

SETBIT key offset value    // 将第offset的值设为value  value只能是0或1  offset 从0开始
GETBIT key offset        // 获得第offset位的值
STRLEN key              // 得出占多少字节 超过8位后自己按照8位一组一byte再扩容
BITCOUNT key         // 得出该key里面含有几个1
BITOP and destKey key1 key2 // 对一个或多个 key 求逻辑并，并将结果保存到 destkey 
BITOP or destKey key1 key2 // 对一个或多个 key 求逻辑或，并将结果保存到 destkey 
BITOP XOR destKey key1 key2 // 对一个或多个 key 求逻辑异或，并将结果保存到 destkey 
BITOP NOT destKey key // 对key 求逻辑非，并将结果保存到 destkey

应用

做签到很适合位图
- 每天使用1个1亿位的Bitmap约占12MB的内存（10^8/8/1024/1024），10天的Bitmap的内存开销约为120MB，内存压力不算太高。
- 在实际使用时，最好对Bitmap设置过期时间，让Redis自动删除不再需要的签到记录以节省内存开销。
对于电影和广告是否被点击播放过也可以用位图

1.8 Redis基数统计(HyperLogLog)

介绍

去重复统计功能的基数估计算法就是 HyperLogLog

基数
- 是一种数据集，去重复后的真实个数
基数统计
- 用于统计一个集合中不重复的元素个数，就是对集合去重复后剩余元素的计算
- 只需要花费12KB内存，就能记录 2的64次方=18446744073709551616 个不同元素的基数

基本命令

在这里插入图片描述

在这里插入图片描述

应用

统计某个网页的UV、某个文章的UV
- UV Unique Visitor 独立访客，一般理解为客户端IP，需要去重
用户搜索网站关键词数量
统计用户每天搜索不同词条个数

1.9Redis地理空间(GEO)

介绍地球上的地理位置是使用二维的经纬度表示，经度范围 (-180, 180]，纬度范围 (-90, 90]，只要我们确定一个点的经纬度就可以名取得他在地球的位置。

例如滴滴打车，最直观的操作就是实时记录更新各个车的位置
然后当我们要找车时，在数据库中查找距离我们(坐标x0,y0)附近r公里范围内部的车辆

基本命令

经纬度去地图上直接复制

GEOADD添加经纬度坐标

在这里插入图片描述

会出现中文乱码

redis -cli -a 123456 – raw

GEOPOS 返回经纬度

在这里插入图片描述

GEOHASH返回坐标的 geohash 表示（base32编码）

在这里插入图片描述

GEODIST 返回两个位置之间的距离

在这里插入图片描述

GEORADIUS 以给定的经纬度为中心，返回键包含的位置元素当中，与中心的距离不超过给定最大距离的所有位置元素。

在这里插入图片描述

GEORADIUSBYMEMBER 找出指定范围内的元素，中心点是由给定的位置元素决定

在这里插入图片描述

应用

美团附近的饭店、酒店
高德地图附近的店

1.10 Redis流（Stream）

介绍

实现消息队列的三个方式
- List实现消息队列
- Pub/Sub 发布订阅
- Stream流（Redis版的MQ消息中间件+阻塞队列）

Stream流实现消息队列，它支持消息的持久化、支持自动生成全局唯一 ID、支持ack确认消息的模式、支持消费组模式等，让消息队列更加的稳定和可靠

Stream结构

在这里插入图片描述

基本命令

队列指令

在这里插入图片描述

消费组指令

在这里插入图片描述

在这里插入图片描述

消费组里的消费者进行轮询

在这里插入图片描述

1.11 Redis位域(bitfield)

介绍

将很多小的整数存储到一个长度较大的位图中，又或者将一个非常庞大的键分割位多个较小的键来进行储存，从而高效利用内存
也就是将 Redis 字符串看作是一个 由二进制位组成的数组 并能对变长位宽和任意没有字节对齐的指定整型位域进行寻址和修改

基本命令

在这里插入图片描述

溢出控制：

WRAP: 使用回绕 (Wrap around) 方法处理有符号和无符号整数溢出

在这里插入图片描述

Set: 使用饱和计算(saturation arithmetic) 方法处理溢出，下溢计算的结果为最小的整数值，而上溢计算的结果为最大的整数值

在这里插入图片描述

FAIL ：命令将拒绝执行那些会导致上溢或者下溢情况出现的计算，并向用户返回空值表示计算未被执行

在这里插入图片描述

2.redis集成

在Redis官网中提供了各种语言的客户端，地址：https://redis.io/docs/clients/

其中jedis是将redis基本命令（名字都一样）打包到方法中，直接使用即可

其次是SpringDataRedis

SpringData是Spring中数据操作的模块，包含对各种数据库的集成，其中对Redis的集成模块就叫做SpringDataRedis，官网地址：https://spring.io/projects/spring-data-redis

2.1 jedis

**优点：**操作简单

**缺点：**线程不安全

2.1.1 单独连接（不建议使用）

1、创建Maven 工程：

2、导入jar包依赖：

Xml

<dependencies>
	<!--jedis对应依赖-->
    <dependency>
        <groupId>redis.clients</groupId>
        <artifactId>jedis</artifactId>
        <version>2.9.0</version>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
    </dependency>
</dependencies>

3、对redis中的String进行操作

Java

@Test
public void testJedis(){
    private Jedis jedis;
    //连接redis
    Jedis jedis = new Jedis("127.0.0.1", 6379);
    //2.设置密码
    jedis.auth("123456");
    //3.选择库
    jedis.select(0);
    //操作redis的String数据结构
    jedis.set("name","helloworld");
    String name = jedis.get("name");
    System.out.println(name);
    //关闭连接
    jedis.close();
}

4.对redis中的list进行操作

Java

public class Jedis_list {

    private Jedis jedis;
    @Test
    public void test_list() {
        jedis = new Jedis("127.0.0.1", 6379);
        jedis.auth("123456");
        //------对list操作的start---
        jedis.lpush("list1","a","b","c","d");
        jedis.rpush("list1","x");
        List<String> list = jedis.lrange("list1", 0, -1);
        for (String s : list) {
            System.out.println(s);
        }
        //------对list操作的end---

        jedis.close();
    }
}

结果：

d

c

b

a

x

5.对redis中的hash进行操作

Java

@Test
    public void testHash(){
        //连接redis
        Jedis jedis = new Jedis("127.0.0.1", 6379);
        //操作redis
        jedis.hset("hash1","a1","a1");
        jedis.hset("hash1","a2","a2");
        Map<String, String> hash1 =
                jedis.hgetAll("hash1");
        System.out.println(hash1);
        //关闭连接
        jedis.close();
    }

结果：{a1= a1 , a2 = a2}

业务场景：

在这里插入图片描述

案例：需求分析

在这里插入图片描述

代码实现

Java

package com.wql;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.exceptions.JedisDataException;

/**
 * Description
 * User:
 * Date:
 * Time:
 */
//服务的方法，
public class service {
    private String id;//用户id
    private int num;//用户总共的使用次数
    public service(String id,int num){
        this.id = id;
        this.num = num;
    }

    //控制单元（控制business的调用）
    public void ss(){
        //连接redis
        Jedis jedis = new Jedis("127.0.0.1", 6379);

        //业务操作
        String value = jedis.get("compid:"+id);//获取剩余使用次数
        try {
            if (value==null){
            jedis.setex("compid:"+id,5,Long.MAX_VALUE-num+"");
            }else {
                Long val = jedis.incr("compid:"+id);//已经使用次数
                business(id,num-(Long.MAX_VALUE-val));//剩下使用次数
            }
        }catch (JedisDataException e){
            System.out.println("使用已经达到次数上限，请升级会员级别");
            return;
        }finally {
            //关闭jedis
            jedis.close();
        }

    }

    //业务操作
    public void business(String id,Long val){
        System.out.println("用户:"+id+"业务操作执行第"+val+"次");
    }
}

class MyThread extends Thread{
    service sc;
    public MyThread(String id,int num){
        sc = new service(id,num);
    }
    @Override
    public void run() {
        while (true){
            sc.ss();
            try {
                Thread.sleep(300L);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }

    }
}

class Main{
    public static void main(String[] args) {
        MyThread mt1 = new MyThread("1",10);
        MyThread mt2 = new MyThread("2",30);
        mt1.start();
        mt2.start();
    }
}

2.1.2 连接池

Jdeis本身已经提供了连接池JedisPool

JedisPool：Jedis提供的连接池技术
- poolConfig：连接池配置对象
- host:redis服务地址
- port:redis服务端口号

①在unit包下创建工具类，将连接的配置写好

Java

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

/**
 * @author 
 */
public class JedisPoolUnit {
    private static final JedisPool jedispool;
    static{ 
        // 构建连接池配置信息
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        // 设置最大连接数
        jedisPoolConfig.setMaxTotal(50);
        // 最大空闲连接
        jedisPoolConfig.setMaxIdle(8);
        // 最大空闲连接
        jedisPoolConfig.setMinIdle(0);
        // 最长等待时间ms
        jedisPoolConfig.setMaxWaitMillis(200);
        // 构建连接池
        JedisPool jedisPool = new JedisPool(jedisPoolConfig, "127.0.0.1", 6379,"123456");
    }
       
        public static Jedis getJedis(){
            return jedisPool.getResource();
        }
       
}

②在实现方法中获取

Java

public class service{
	public void method1{
		// 从连接池中获取连接
        Jedis jedis = jedisPool.getResource();
        //------可以开启对redis的操作了-------
        // 读取数据
        System.out.println(jedis.get("name"));
        //------操作末尾-------
        
        // 将连接还回到连接池中或者使用jedis.close()
        jedisPool.returnResource(jedis);	
	}
}

注意：在使用redispool时，要知道returnResource（）和clos()操作都是将线程归还给线程池，而不是关闭线程

这个点，也是导致Jedis线程不安全的原因。

2.1.3 分布式集群

Java

import redis.clients.jedis.JedisPoolConfig;
import redis.clients.jedis.JedisShardInfo;
import redis.clients.jedis.ShardedJedis;
import redis.clients.jedis.ShardedJedisPool;

import java.util.ArrayList;
import java.util.List;

/**
 * 集群式的连接池
 */
public class ShardedJedisPoolDemo {

    public static void main(String[] args) {
        // 构建连接池配置信息
        JedisPoolConfig poolConfig = new JedisPoolConfig();
        // 设置最大连接数
        poolConfig.setMaxTotal(50);

        // 定义集群信息
        List<JedisShardInfo> shards = new ArrayList<JedisShardInfo>();

        shards.add(new JedisShardInfo("127.0.0.1", 6379));
        //shards.add(new JedisShardInfo("192.168.48.22", 6379));

        // 定义集群连接池
        ShardedJedisPool shardedJedisPool = new ShardedJedisPool(poolConfig, shards);
        ShardedJedis shardedJedis = null;
        try {
            // 从连接池中获取到jedis分片对象
            shardedJedis = shardedJedisPool.getResource();
            // 从redis中获取数据
            String value = shardedJedis.get("name");
            System.out.println(value);
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (null != shardedJedis) {
                // 关闭，检测连接是否有效，有效则放回到连接池中，无效则重置状态
                shardedJedis.close();
            }
        }
        // 关闭连接池
        shardedJedisPool.close();
    }
}

2.2 Lettuce

1.介绍以及和Jedis的区别

Lettuce是一个Redis的Java驱动包，Lettuce翻译为生菜，没错，就是吃的那种生菜，所以它的Logo就是生菜

在这里插入图片描述

2.步骤

改POM(导包)

Xml

 <!--lettuce-->
        <dependency>
            <groupId>io.lettuce</groupId>
            <artifactId>lettuce-core</artifactId>
            <version>6.2.1.RELEASE</version>
        </dependency>

2.业务类

Java

import io.lettuce.core.RedisClient;
import io.lettuce.core.RedisURI;
import io.lettuce.core.api.StatefulRedisConnection;
import io.lettuce.core.api.sync.RedisCommands;

import java.util.List;

/**
 * @Author:晓风残月Lx
 * @Date: 2023/3/13 22:13
 */
public class LettuceDemo {

    public static void main(String[] args) {
        // 1 使用构建器链式编程来builder我们的RedisURI
        RedisURI uri = RedisURI.builder()
                .withHost("192.168.238.111")
                .withPort(6379)
                .withAuthentication("default", "123456")
                .build();
        // 2 连接客户端
        RedisClient redisClient = RedisClient.create(uri);
        StatefulRedisConnection<String, String> conn = redisClient.connect();

        // 3 创建操作的command, 通过conn 创建
        RedisCommands<String, String> commands = conn.sync();

        // string
        commands.set("k1","v1");
        System.out.println("==========================="+commands.get("k1"));
        System.out.println("==========================="+commands.mget("k1","k2"));
        List<String> keys = commands.keys("*");
        for (String key : keys) {
            System.out.println("========================="+key);
        }

        // list
        commands.lpush("list01","1","2","3");
        List<String> list01 = commands.lrange("list01", 0, -1);
        for (String s : list01) {
            System.out.println("================"+s);
        }
        System.out.println("===================="+ commands.rpop("list01", 2));

        // hash
        commands.hset("hash","k1","v1");
        commands.hset("hash","k2","v2");
        commands.hset("hash","k3","v3");
        System.out.println("======================="+commands.hgetall("hash"));
        Boolean hexists = commands.hexists("hash", "v2");
        System.out.println("------"+hexists);

        // set
        commands.sadd("s1","1","2");
        System.out.println("=================================" + commands.smembers("s1"));
        System.out.println(commands.sismember("s1", "1"));
        System.out.println(commands.scard("s1"));

        // zset
        commands.zadd("a1",100,"v1");
        commands.zadd("a1",80,"v2");
        System.out.println(commands.zrange("a1", 0, -1));
        System.out.println("======================"+commands.zcount("a1", "90", "100"));

        // 4 各种关闭释放资源  先开后关
        conn.close();
        redisClient.shutdown();

    }
}

2.3 SpringDataRedis（RedisTemplate ）

定义：

SpringData是Spring中数据操作的模块，包含对各种数据库的集成，其中对Redis的集成模块就叫做SpringDataRedis，

官网地址：https://spring.io/projects/spring-data-redis

提供了对不同Redis客户端的整合（Lettuce和Jedis）
提供了RedisTemplate统一API来操作Redis
支持Redis的发布订阅模型
支持Redis哨兵和Redis集群
支持基于Lettuce的响应式编程(Lettuce之前实在es那里有)
支持基于JDK.JSON.字符串.Spring对象的数据序列化及反序列化

集成的redis在使用时，提供byte和String类型的封装，但是对象并不属于这两种，所以需要把对象序列化

支持基于Redis的JDKCollection实现

SpringDataRedis中提供了RedisTemplate工具类，其中封装了各种对Redis的操作。并且将不同数据类型的操作API封装到了不同的类型中：

API命名为opsForxxx()返回值为对应的xxx对象，该对象包含对xxx数据类型的各种操作

测试：

①创建Springboot项目，默认整合了redis

在选择Springboot依赖的时候，在NOSQL里面就有redis的默认依赖

写入依赖：

Xml

		<!--redis依赖-->
		<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis-reactive</artifactId>
        </dependency>
		<!--连接池依赖-->
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-pool2</artifactId>
        </dependency>

②配置application.yml，将redis注册到服务器中

Yml

spring:
  redis:
    host: 127.0.0.1
    port: 6379
    password: 123456
    database: 0
    lettuce: # 连接池pool
      pool:
        max-active: 8 #最大连接数
        max-idle: 8 # 最大空闲数
        min-idle: 0 #最小空闲数
        max-wait: 100 # 最大等待时间

③正式的使用（使用测试的方式来验证）

Java

@SpringBootTest
class SpringDataRedisApplicationTests {

    @Autowired
    private RedisTemplate redisTemplate;
    
    @Test
    public void contextLoads() {
        //  使用set写入数据
        redisTemplate.opsForValue().set("name", "wms");

        // 获取数据
        Object name = redisTemplate.opsForValue().get("name");
        System.out.println(name);

    }
}

在执行程序之后发现，其实成功了，但是在实际的redis数据库中，是==jdk字节码形式==的。

为什么呢？

由于我们使用的是String-Object的话，你value的值如果传入一个字符串或者其他类型的话，并没有序列化，就会造成以下情况：get key

这是由于key和value会被当成对象，被redis底层的默认序列化方法：jdk序列化工具jdkSerializationRedisSerialliszer

而jdk序列化采用的是objectOutputStream(把java对象转成字节[object->byte])，我们需要的是将java对象转换成String类型展示出来

如果需要转换成json格式，也同样的需要自定义序列化工具。

TEXT

RedisTemplate源码部分

Java

 public void afterPropertiesSet() {
        super.afterPropertiesSet();
        boolean defaultUsed = false;
     // 没有制定序列化策略，默认使用jdk序列化
        if (this.defaultSerializer == null) {
            this.defaultSerializer = new JdkSerializationRedisSerializer(this.classLoader != null ? this.classLoader : this.getClass().getClassLoader());
        }

        if (this.enableDefaultSerializer) {
            if (this.keySerializer == null) {
                this.keySerializer = this.defaultSerializer;
                defaultUsed = true;
            }

            if (this.valueSerializer == null) {
                this.valueSerializer = this.defaultSerializer;
                defaultUsed = true;
            }

            if (this.hashKeySerializer == null) {
                this.hashKeySerializer = this.defaultSerializer;
                defaultUsed = true;
            }

            if (this.hashValueSerializer == null) {
                this.hashValueSerializer = this.defaultSerializer;
                defaultUsed = true;
            }
        }

        if (this.enableDefaultSerializer && defaultUsed) {
            Assert.notNull(this.defaultSerializer, "default serializer null and not all serializers initialized");
        }

        if (this.scriptExecutor == null) {
            this.scriptExecutor = new DefaultScriptExecutor(this);
        }

        this.initialized = true;
    }

==自定义序列化==

在config文件下写一个RedisConfig.java

目的：自定义序列化

主动将Object中Key—>String，Value—>josn类型

缺点：在序列化和反序列化的工程中，机器需要类名识别内容，所以实际的内容会有类名（占空间）

Java

@Configuration
public class redisConfig {
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);
        // 设置key的序列化
        template.setKeySerializer(RedisSerializer.string());

        //  设置value的序列化方式
        template.setValueSerializer(RedisSerializer.json());
        // 设置hash中key的序列化
        template.setHashKeySerializer(RedisSerializer.string());

        // 设置hash的value的序列化方式
        template.setHashValueSerializer(RedisSerializer.json());
        template.afterPropertiesSet();
        return template;

    }
}

PS：记得引入json依赖，否则会报错

Caused by: java.lang.ClassNotFoundException: com.fasterxml.jackson.databind.JsonSerializer

Xml

  		<!--jackson依赖-->
		<dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
        </dependency>s

结果：

接下里试试实体类的序列化

Java

@Data
@AllArgsConstructor
@NoArgsConstructor
public class User {
   private String name;
   private Integer age;
}

Java

@Test
public void testSaveUser(){
   User user = new User();
   user.setName("阿廖莎");
   user.setAge(21);
   redisTemplate.opsForValue().set("user:100",user);
   System.out.println(redisTemplate.opsForValue().get("user:100"));
}

控制台打印：

为了在反序列化时知道对象的类型，JSON序列化器会将类的class类型写入json结果中，存入Redis，会带来额外的内存开销。

==spring中提供的第二种序列化StringRedisTemplate==

优点：节省空间

缺点：需要在使用redis时，手动将Object类型转换成String类型或Json类型（使用对应的json工具包依赖了）==时间复杂度就高了==

实现：

不需要自定义RedisConfig工具

在实现时，

注入StringRedisTemplate
使用其他Object—>json格式的工具包
在存入redis或读取redis时，都使用一次该工具包

Java

@Autowired
private StringRedisTemplate stringRedisTemplate;

//JSON工具类ObjectMapper,或者可以用fastjson:JSON.toJSONString(), JSON.parseObject()
private static final ObjectMapper mapper = new ObjectMapper();

@Test
    public void testSaveUser() throws JsonProcessingException {
        User user = new User();
        user.setName("阿廖莎");
        user.setAge(21);
        //手动序列化
        String json = mapper.writeValueAsString(user);

        stringRedisTemplate.opsForValue().set("user:100",json);
        //手动反序列化
        User user1 = mapper.readValue(stringRedisTemplate.opsForValue().get("user:100"), User.class);
        System.out.println("user1 = " + user1);
    }

相对而言就多了两步，换来了空间上的提升

在SpringDataRedis中的hash结构函数

PS：在java语言下，Redis中的hash为了更加符合java习惯，修改了对应原生的语句

Java

@Test
void testHash(){
    stringRedisTemplate.opsForHash().put("user:200","name","张三");
    stringRedisTemplate.opsForHash().put("user:200","age","21");

    Object name = stringRedisTemplate.opsForHash().get("user:200", "name");
    System.out.println("属性name: " + name);
    Map<Object, Object> entries = stringRedisTemplate.opsForHash().entries("user:200");//获取全部的hashkey-hashvalue
    System.out.println("所有属性: " + entries);
}

集群下连接

启动的集群
改写YML（注意IP和端口）

Yml

server.port= 7070
spring.application.name=redis7_study01

# ========================logging=====================
logging.level.root=info
logging.level.com.atguigu.redis7=info
logging.pattern.console=%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger- %msg%n 

logging.file.name=D:/mylogs2023/redis7_study.log
logging.pattern.file=%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger- %msg%n

# ========================swagger=====================
spring.swagger2.enabled=true
#在springboot2.6.X结合swagger2.9.X会提示documentationPluginsBootstrapper空指针异常，
#原因是在springboot2.6.X中将SpringMVC默认路径匹配策略从AntPathMatcher更改为PathPatternParser，
# 导致出错，解决办法是matching-strategy切换回之前ant_path_matcher
spring.mvc.pathmatch.matching-strategy=ant_path_matcher

# ========================redis单机=====================
#spring.redis.database=0
## 修改为自己真实IP
#spring.redis.host=192.168.238.111
#spring.redis.port=6379
#spring.redis.password=123456
#spring.redis.lettuce.pool.max-active=8
#spring.redis.lettuce.pool.max-wait=-1ms
#spring.redis.lettuce.pool.max-idle=8
#spring.redis.lettuce.pool.min-idle=0

spring.redis.password=123456
#获取失败，最大重定向次数
spring.redis.clusterspring.redis.cluster.nodes=192.1.max-redirects=3
spring.redis.lettuce.pool.max-active=8
spring.redis.lettuce.pool.max-wait=-1ms
spring.redis.lettuce.pool.max-idle=8
spring.redis.lettuce.pool.min-idle=0
# 重点
spring.redis.cluster.nodes=192.238.111:6381,192.168.238.111:6382,192.168.238.112:6383,192.168.238.112:6384,192.168.238.113:6385,192.168.238.113:6386
#支持集群拓扑动态感应刷新,自适应拓扑刷新是否使用所有可用的更新，默认false关闭
spring.redis.lettuce.cluster.refresh.adaptive=true
#定时刷新
spring.redis.lettuce.cluster.refresh.period=2000

==注意==

如果redis端宕机之后，在yml文件中没有加入定时刷新，则服务器会出现短时间断开，无法读写

3.redis特性

3.1 持久化（persistence）

说人话，就是数据的恢复与保存

注意持久化，要使用两台以上的数据进行，否则一台机器会导致数据记录的覆盖与混乱

3.1.1 持久化机制

redis有两种持久化机制：RDB和AOF。每种持久化机制各有优缺点，了解每种持久化机制的原理对我们使用Redis有很大的帮助。Redis4.0后支持RDB和AOF两种持久化机制混合使用，所以存在三种持久化策略。

RDB redis data base
AOF
混合机制

3.1.2 RDB持久化

定义：

RDB（Redis DataBase）是基于快照一次的全量备份，即周期性的把redis当前内存中的全量数据写入到一个快照文件中(周期时间可以通过配置来调整)快照文件就称为RDB文件(dump.rdb)，其中。redis是单线程程序，这个线程负责多个客户端的读写请求，还有RDB持久化操作。很明显这两个过程不可能同步进行的，甚至可能导致线程阻塞的。

解决方法：使用OS中的**多进程COW(Copy On Write)机制来实现快照的持久化，在持久化过程中调用 glibc(Linux下的C函数库) 的函数fork()产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端的读写请求。**子进程刚刚产生时，和父进程共享内存里面的代码段和数据段，这是Linux操作系统的机制，为了节约内存资源，所以尽可能让父子进程共享内存，这样在进程分离的一瞬间，内存的增长几乎没有明显变化。

注意：

#1、linux中若父进程退出,子进程尚未结束，子进程不会立即退出。在linux中，所有进程都有一个共同的祖父进程systemd，如果父进程退出了，子进程还没运行结束，子进程会被祖父进程systemd（老版本的linux是initd）收养。

#2、RDB持久化时，Redis会fork()一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端的读写请求

问题：

fork()产生的子进程进行持久化时，每次是单纯的全覆盖复制还是其他方式？这样复制的方式，导致内存是原来的2倍吗？有机制减少内存增加吗？

答案：子进程对当前内存中的数据进行持久化时，并不会修改当前的数据结构，如果父进程收到了读写请求，那么会把处理的那一部分数据复制一份到内存，对复制后的数据进行修改（写时复制Copy-On-Write）。所以即使对某个数据进行了修改，redis持久化到RDB中的数据也是未修改的数据，这也是把RDB文件称为"快照"文件的原因，子进程所看到的数据在它被创建的一瞬间就固定下来了，父进程修改的某个数据只是该数据的复制品。

实际上，内存中的全量数据由一个个的"**数据段页面"**组成，每个数据段页面的大小为4K，客户端要修改的数据在哪个页面中，就会复制一份这个页面到内存中，这个复制的过程称为"页面分离"，在持久化过程中，随着分离出的页面越来越多，**内存就会持续增长，但是不会超过原内存的2倍，**因为在一次持久化的过程中，几乎不会出现所有的页面都会分离的情况，读写请求针对的只是原数据中的小部分，大部分redis数据还是"冷数据"。RDB过程整个过程如下图：

热点数据和冷数据是什么

热点数据：读取频率高，如果不做缓存，给数据库造成很大的压力，可能被击穿。
冷数据：读取频率低，数据设置缓存后有可能没有被访问就被挤出内存(超时dele)。

触发机制：

RDB有两种触发方式：自动触发和手动触发。

（1）自动触发：

在 redis.conf 配置文件中的 SNAPSHOTTING 下配置save参数，来触发Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如**“save m n”：表示m秒内数据集存在n次修改时，自动触发bgsave。**

语法： save m1 n1 m2 n2 m3 n3 s

//默认如下配置： save 900 1：每隔900s(15min)，如果有超过1个key发生了变化，就写一份新的RDB文件 save 300 10：每隔300s(5min)，如果有超过10个key发生了变化，就写一份新的RDB文件 save 60 10000：每隔60s(1min)，如果有超过10000个key发生了变化，就写一份新的RDB文件（配置多种策略可以同时生效，无论满足哪一种条件都会写一份新的RDB文件）

即 save 900 1 300 10 60 10000 等价于上面3个命令

（2）手动触发：手动生成新的RDB文件，执行Redis的save、bgsave命令。

命令：save：阻塞主进程，直到生成新的RDB文件；执行save命令期间，Redis不能处理其他命令。(不推荐)
命令：bgsave：（默认）异步生成RDB文件，fork子进程去生成新的RDB文件，主进程不阻塞。
命令：lastsave：获取最后一次成功执行快照的时间

其他命令：

命令：flushdb：用于清空当前数据库中的所有 key。之后默认生成rdb文件

命令：shutdown：停止redis进程，使用quit一样，这样会停止redis，导致进程中断

命令：redis-check-rdb 文件名检查并修复dump.rdp文件

哪些情况会触发RDB快照

配置文件中默认的快照配置
手动 save/bgsave 命令
执行flush / flushdb 命令也会产生 dump.rdb 文件，但里面是空的，无意义
执行 shutdown 且没有设置开启 AOF 持久化
主从复制时，主节点自动触发

（3）修改redis.conf中持久化的相关配置

修改dump.rdb存放地址

·在vi redis-conf中直接修改，默认在./下

·使用redis客户端下，使用congfig get dir获取地址，config set dir 目录名称修改

例子：

修改dump文件名称

同样有两种方法进行修改：vi和config 的方式

如何禁用快照

动态所有停止 RDB 保存规则的方法: redis-cli config set save “”

将下面命令注释删除即可

在这里插入图片描述

数据一致性配置

在这里插入图片描述

存储内容压缩机制

在这里插入图片描述

数据检验算法的开启

在这里插入图片描述

删除未持久化数据的设置

在这里插入图片描述

3.1.3 AOF持久化

定义：

AOF(Append-only file)日志存储的是redis服务器的顺序指令序列，即对内存中数据进行修改的指令记录。当redis收到客户端修改指令后，先进行参数校验，如果校验通过，先把该指令存储到AOF日志文件中，也就是先存到磁盘，然后再执行该修改指令。

redis把操作指令追加（append）到AOF文件这个过程，并不是直接写到AOF文件中，而是先写到操作系统的内存缓存中，这个内存缓存是由操作系统内核分配的，然后操作系统内核会异步地把内存缓存中的redis操作指令刷写到AOF文件中。当redis宕机后重启后，可以读取该AOF文件中的指令，进行数据恢复，恢复的过程就是把记录的指令再顺序执行一次，这样就可以恢复到宕机之前的状态。

这儿存在一个问题，假如内存缓存中的redis指令还没有来得及刷写到AOF文件中就宕机了，那么这部分未刷写的指令就会丢失，不过，**glibc函数库提供了 fsync() 函数，该函数可以将指定文件的内容强制从内存缓存中刷写到磁盘上。**fsync操作的周期对redis的性能有很大影响，如何配置将在本文后续的内容中给出建议。AOF过程如下图：

AOF Rewrite

redis在长期运行过程中，AOF日志会越来越大，如果redis服务重启后根据很大的AOF文件来顺序执行指令，将会非常耗时，导致redis服务长时间无法对外提供服务，所以需要对AOF文件进行"瘦身"。"瘦身"的过程称作AOF重写(rewrite)。

AOF Rewrite 的原理是，主进程fork一个子进程，对当前内存中的数据进行遍历，转换成一系列的redis操作指令，并序列化到一个新的AOF日志中，然后把序列化操作期间新收到的操作指令追加到新的AOF文件中，追加完毕后就立即替换旧的AOF文件，这样就完成了"瘦身"工作，即AOF Rewrite。AOF Rewrite过程如下图：

Shell

#1、AOF持久策略：fsync的策略，默认为everysec。同样是在redis.conf文件中
appendfsync everysec
# 参数：
# everysec：每秒fsync一次，如果Redis宕机，1秒内的指令丢失。
# no：redis不主动fsync，完全交由操作系统决定
# always：1条指令fsync一次，保证数据一条不丢失

AOF 缓冲区三种写回策略

三种写回策略：

always 同步写回，每个写命令执行完立刻同步地将日志写回磁盘 everysec 每秒写回，每个写命令执行完，只是先把日志写到AOF缓冲区，每隔1s把缓存区地数据写入磁盘操作系统控制协会，只是将日志先写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

在这里插入图片描述

在这里插入图片描述

AOF配置、启动、修复、恢复

开启AOF

在这里插入图片描述

AOF文件 --保存路径

在这里插入图片描述

AOF文件 --保存名称

在这里插入图片描述

异常恢复

在网络闪断时，aof文件写了错误的指令，使用

异常修复命令： redis-check-aof --fix 进行修复

在这里插入图片描述

AOF重写机制

启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集

开启重写

在这里插入图片描述

自动触发

满足配置文件中的选项后，Redis会记录上次重写时地AOF大小
默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时

手动触发

客户端向服务器发送 bgrewriteaof 命令

现象：也就是一旦重写就会生成新的base、incr文件，去替换之前的

在这里插入图片描述

结论

在这里插入图片描述

AOF 优化配置项详解

在这里插入图片描述

3.1.4 混合持久化

**redis-4.x后支持了RDB和AOF混合使用。**重启redis时，我们很少使用RDB来恢复内存状态，因为会丢失大量数据。我们通常使用AOF日志重放，但是重放AOF日志性能相对RDB来说要慢很多，这样在redis实例很大的情况下，启动需要花费很长的时间。redis-4.0为了解决这个问题，带来了一个新的持久化选项——==混合持久化。将RDB文件的内容和增量的AOF日志文件存在一起，这里的AOF日志不再是全量的日志，而是RDB久化开始到 RDB持久化结束的这段时间发生的增量AOF日志，通常这部分AOF日志很小==。redis-4.x混合持久化机制如下图：

在这里插入图片描述

3.1.5 redis 持久化机制对比

(1)RDB的优缺点

优点：

RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去。
生成RDB文件的时候，主进程不需要进行**任何磁盘IO操作。**当进行RDB持久化时，对redis服务处理读写请求的影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。生成一次RDB文件的过程就是把当前时刻内存中的数据一次性写入文件中，而AOF则需要先把当前内存中的小量数据转换为操作指令，然后把指令写到内存缓存中，然后再刷写入磁盘。
RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。AOF存放的是指令日志，做数据恢复的时候，要回放和执行所有的指令日志，从而恢复内存中的所有数据；而RDB，就是一份数据文件，恢复的时候，直接加载到内存中即可。

缺点：

RDB方式数据没办法做到实时持久化/秒级持久化，会导致数据丢失。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据。这个问题，也是RDB最大的缺点，**就是不适合做第一优先的恢复方案，**如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多。
RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)。
RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，甚至数秒。所以一般不要让生成RDB文件的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能会有影响。

(2)AOF的优缺点

优点：

AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
AOF日志文件以append-only模式(追加)写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite的时候，会对其中的指令进行压缩，会创建出一份需要恢复数据的最小日志出来。
AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。

缺点：

对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。因为AOF是指令文件，RDB是二进制文件。
AOF的写性能比RDB的写性能低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的，只不过比起RDB来说性能低，如果要保证一条数据都不丢，也是可以的，AOF的fsync设置成每写入一条数据，fsync一次，但是这样，redis的性能会大大下降。
基于AOF文件做恢复的速度不如基于RDB文件做恢复的速度。

(3)混合持久化的优缺点

**优点：**结合了RDB和AOF的优点，使得数据恢复的效率大幅提升
缺点：兼容性不好，redis-4.x新增，虽然最终的文件也是.aof格式的文件，但在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差。

(4)如何选择redis持久化机制

RDB和AOF到底该如何选择

不要仅仅使用RDB，因为那样会导致丢失很多数据。
也不要仅仅使用AOF，一是数据恢复慢，二是可靠性也不如RDB，毕竟RDB文件中存储的就是某一时刻实实在在的数据，而AOF只是操作指令，把数据转换为操作指令不一定是百分百没问题的。
综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; **用RDB来做不同程度的冷备，**在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。

(5)AOF和RDB同时工作

redis在写RDB文件的时候不会执行AOF rewrite；redis在执行AOF rewrite的时候不会生成新的RDB。
如果redis正在生成新的RDB文件，此时用户执行bgrewriteaof命令手动重写AOF文件，那么等RDB快照生成之后，才会去执行AOF rewrite。
同时有RDB文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整。

3.1.6 其他命令

修复AOF文件

Shell

#如果redis在append数据到AOF文件时，机器宕机了，可能会导致AOF文件破损，使用以下命令修复AOF文件
$REDIS_HOME/bin/redis-check-aof --fix

查看持久化信息

Shell

# 查看持久化信息
info Persistence
# 查看状态信息
info stats

一个通用的redis持久化配置：

Shell

######################### 通用 #########################
 
# 持久化文件(包括RDB文件和AOF文件)的存储目录，默认.
dir dir /home/hadoop/data/redis/6379
 
######################### RDB #########################
 
# RDB文件的文件名称，默认dump.rdb
dbfilename dump.rdb
 
# 生成RDB文件的策略，默认为以下3种，意思是：
# 每隔60s(1min)，如果有超过10000个key发生了变化，就写一份新的RDB文件
# 每隔300s(5min)，如果有超过10个key发生了变化，就写一份新的RDB文件
# 每隔900s(15min)，如果有超过1个key发生了变化，就写一份新的RDB文件
# 配置多种策略可以同时生效，无论满足哪一种条件都会写一份新的RDB文件
save 900 1
save 300 10
save 60 10000
 
# 是否开启RDB文件压缩，该功能可以节约磁盘空间，默认为yes
rdbcompression yes
 
# 在写入文件和读取文件时是否开启rdb文件检查，检查是否有无损坏
# 如果在启动时检查发现文件损坏，则停止启动，默认yes
rdbchecksum yes
 
######################### AOF #########################
 
# 是否开启AOF机制，默认为no
appendonly yes
 
# AOF文件的名称，默认为appendonly.aof
appendfilename "appendonly.aof"
 
# fsync的策略，默认为everysec
# everysec：每秒fsync一次
# no：redis不主动fsync，完全交由操作系统决定
# always：1条指令fsync一次
appendfsync everysec
 
# AOF文件rewrite策略
# 当上一次重写后的AOF文件的增长比例达到100%
# 比如上一次重写AOF文件后，新文件大小为128M
# 当新文件再次增长了100%，达到了256M
# 并且增长了100%后的文件的大小大于64M，那么开始重写AOF文件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
 
# 是否加载破损的AOF文件，默认为yes，如果设置为no
# 那么redis启动时如果发现AOF文件破损，就会报错并且拒绝启动redis服务。
aof-load-truncated yes
 
######################### 混合持久化 #########################
 
# 是否开启混合持久化机制，默认为no
aof-use-rdb-preamble no

3.1.7 纯缓存模式

同时关闭RDB + AOF

save “”
- 禁用rdb
- 禁用db持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
appendonly no
- 禁用aof
- 禁用aof持久化模式下，我们仍然可以使用命令 bgrewriteaof生成aof文件

3.2 事务

基本命令：

下表列出了 redis 事务的相关命令：序号命令及描述

1 DISCARD

取消事务，放弃执行事务块内的所有命令。

2 EXEC

执行所有事务块内的命令。

3 MULTI

标记一个事务块的开始。

4 UNWATCH

取消 WATCH 命令对所有 key 的监视。

5 WATCH key [key …]

监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

执行事务步骤：

1**.开启事务（队列）：**MULTI

2.入队:（将命令放入队列）:

3.执行（依次执行队列中的命令）: MULTI

当一个客户端切换到事务状态之后，服务器会根据这个客户端发来的不同命令执行不同的操作：

如果客户端发送的命令为 EXEC 、 DISCARD 、 WATCH 、 MULTI 四个命令的其中一个，那么服务器立即执行这个命令。
与此相反，如果客户端发送的命令是 EXEC 、 DISCARD 、 WATCH 、 MULTI 四个命令以外的其他命令，那么服务器并不立即执行这个命令，而是将这个命令放入一个事务队列里面，然后向客户端返回 QUEUED 回复。

在这里插入图片描述

取消事务

Shell

MULTI     // 事务开始
DISCARD   // 放弃事务

在这里插入图片描述

事务的一致性和回滚（和mysql等事务的区别）：

1.语法错误（编译器错误）

在开启事务后，修改k1值为11，k2值为22，但k2语法错误，最终导致事务提交失败，k1、k2保留原值。(都没执行)

在这里插入图片描述

Redis ==不提供事务回滚==的功能，开发者必须在事务执行出错后，自行恢复数据库状态
注意和传统数据库事务区别，==不一定要么一起成功要么一起失败==

2.Redis类型错误（运行时错误）

在开启事务后，修改k1值为11，k2值为22，但将k2的类型作为List，在运行时检测类型错误，最终导致事务提交失败，此时事务并没有回滚，而是跳过错误命令继续执行，结果k1值改变、k2保留原值

Shell

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k1 v2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 11
QUEUED
127.0.0.1:6379> lpush k2 22
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6379> get k1
"11"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379>

CAS操作实现乐观锁

WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。

悲观锁
- 认为每次去拿数据都很认为别人会修改，所以每次拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁
乐观锁
- 认为每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据
- 提交版本必须大于记录当前版本才能执行更新
CAS
- check-and-set（JUC中CAS操作相似）

为什么 Redis 不支持回滚？

如果你有使用关系式数据库的经验，那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。

以下是这种做法的优点：

Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

有种观点认为 Redis 处理事务的做法会产生 bug ，然而需要注意的是，在通常情况下， 回滚并不能解决编程错误带来的问题。举个例子，如果你本来想通过 INCR 命令将键的值加上 1 ，却不小心加上了 2 ，又或者对错误类型的键执行了 INCR ，回滚是没有办法处理这些情况的。

如何理解Redis与事务的ACID？

一般来说，事务有四个性质称为ACID，分别是原子性，一致性，隔离性和持久性。这是基础，但是很多文章对Redis 是否支持ACID有一些异议，我觉的有必要梳理下：

原子性atomicity

首先通过上文知道运行期的错误是不会回滚的，很多文章由此说Redis事务违背原子性的；而官方文档认为是遵从原子性的。

Redis官方文档给的理解是，Redis的事务是原子性的：所有的命令，要么全部执行，要么全部不执行。而不是完全成功。

一致性consistency

redis事务可以保证命令失败的情况下得以回滚，数据能恢复到没有执行之前的样子，是保证一致性的，除非redis进程意外终结。

隔离性Isolation

redis事务是严格遵守隔离性的，原因是redis是单进程单线程模式(v6.0之前），可以保证命令执行过程中不会被其他客户端命令打断。

但是，Redis不像其它结构化数据库有隔离级别这种设计。

持久性Durability

redis事务是不保证持久性的，这是因为redis持久化策略中不管是RDB还是AOF都是异步执行的，不保证持久性是出于对性能的考虑。

Redis事务其它实现

基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行，其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完
基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成。但这样会需要额外写代码实现，比较繁琐

监控(watch)

watch是如何监视实现的呢？(watch支持回滚)

Redis使用WATCH命令来决定事务是继续执行还是回滚，那就需要在MULTI之前使用WATCH来监控某些键值对，然后使用MULTI命令来开启事务，执行对数据结构操作的各种命令，此时这些命令入队列。

当使用EXEC执行事务时，首先会比对WATCH所监控的键值对，如果没发生改变，它会执行事务队列中的命令，提交事务；如果发生变化，将不会执行事务中的任何命令，同时事务回滚。当然无论是否回滚，Redis都会取消执行事务前的WATCH命令。

注意：是先开启watch再开启事务，所以说事务不支持回滚，而watch支持回滚

watch 命令实现监视

初始化键值（k1 和 balance ），先监控balance，再开启multi，保证两key变动在同一事务内

在这里插入图片描述

有加塞篡改的话

watch 命令是一种乐观锁的实现，Redis 在修改的时候会检测数据是否被更改，如果更改了，则执行失败。
在事务开始前用WATCH监控k1，之后修改k1为11，说明事务开始前k1值被改变，MULTI开始事务，修改k1值为12，k2为22，执行EXEC，发回nil，说明事务回滚；查看下k1、k2的值都没有被事务中的命令所改变。

Shell

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
# 监视k1
127.0.0.1:6379> WATCH k1
OK
# 在执行事务前，篡改k1
127.0.0.1:6379> set k1 11
OK
# 执行事务
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 12
QUEUED
127.0.0.1:6379> set k2 22
QUEUED
# 执行 exec，触发事务，是否发生回滚，（nil）
127.0.0.1:6379> EXEC
(nil)
# k1和k2的值都没变
127.0.0.1:6379> get k1
"11"
127.0.0.1:6379> get k2
"v2"

unwatch放弃对键值监控

Shell

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> WATCH k1
OK
127.0.0.1:6379> set k1 11
OK
# 在执行事务前，取消事务的监控
127.0.0.1:6379> UNWATCH
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 12
QUEUED
127.0.0.1:6379> set k2 22
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
127.0.0.1:6379> get k1
"12"
127.0.0.1:6379> get k2
"22"
127.0.0.1:6379>

小结

一旦执行了 exec 之前加的watch监控锁都会被取消掉
当客户端连接丢失的时候（比如退出连接），所有东西都会被取消监视

总结

开启
- 以 MULTI 开始一个事务
入队
- 将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
执行
- 由EXEC命令触发事务

3.3 管道

定义：

速度不够，管道来凑。

在redis中，由于是单线程命令，在redis server 服务端与client端进行数据交互时，是有传输时间的。

Redis客户端执行一条命令分为以下四个步骤:

1.发送命令 2.命令排队 3.命令执行 4.返回结果

其中,第一步+第四步称为RoundTripTime(RTT,往返时间).

这是操作系统中，存在的弊端了

解决方法：

管道(pipeline)可以一次性发送多条命令给服务端。

服务端依次处理完完毕后，通过一条响应一次性将结果返回，通过减少客户端与redis的通信次数来实现降低往返延时时间。
pipeline实现的原理是队列，先进先出特性就保证数据的顺序性。

==也就是批处理==

Pipeline不仅仅能够降低RRT，实际上它极大的提升了单次执行的操作数。这是因为如果不使用Pipelining，那么每次执行单个命令,从访问数据的结构和服务端产生应答的角度，它的成本是很低的。但是从执行网络IO的角度，它的成本其实是很高的。其中涉及到read()和write()的系统调用，这意味着需要从用户态切换到内核态,而这个上下文的切换成本是巨大的。

当使用Pipeline时，它允许多个命令的读通过一次read()操作，多个命令的应答使用一次write()操作，它允许客户端可以一次发送多条命令，而不等待上一条命令执行的结果。不仅减少了RTT，同时也减少了IO调用次数（IO调用涉及到用户态到内核态之间的切换），最终提

**升程序的执行效率与性能。**如下图：

使用：

要支持Pipeline，其实既要服务端的支持，也要客户端支持。对于服务端来说，所需要的是能够处理一个客户端通过同一个TCP连接发来的多个命令，可以理解为，这里将多个命令切分，和处理单个命令一样，Redis就是这样处理的。而客户端，则是要将多个命令缓存起来，缓冲区满了就发送，然后再写缓冲，最后才处理Redis的应答。

在客户端开启管道模式：

Shell

# 开启管道模式
PIPELINE

# 批量导出数据
DUMP key1
DUMP key2

# 执行管道中的所有命令
EXEC

在java中Jedis开启

Java

import redis.clients.jedis.Jedis;
import redis.clients.jedis.Pipeline;

public class CacheUpdater {
    private Jedis jedis;

    public CacheUpdater() {
        jedis = new Jedis("localhost", 6379);
    }

    public void updateCache(List<String> userIds) {
        // 创建管道对象
        Pipeline pipeline = jedis.pipelined();
       
        for (String userId : userIds) {
            User user = getUserFromDB(userId); // 从数据库获取用户信息
            updateCache(user, pipeline); // 更新缓存信息
        }
        // 最后，通过pipeline.syncAndReturnAll()一次性执行所有的管道命令。
        pipeline.syncAndReturnAll();
    }

    private void updateCache(User user, Pipeline pipeline) {
        String cacheKey = "user:" + user.getId();
         // 循环使用管道中的set命令批量更新缓存信息
        pipeline.set(cacheKey, user.toJson());
    }

    private User getUserFromDB(String userId) {
        // 从数据库中获取用户信息的逻辑
    }
}

总结：

Pipeline 与原生批量

原生批量命令是原子性（如：mset，mget），pipeline是非原子性
原生批量命令一次只能执行一种命令，pipeline支持批量执行不同命令
原生批命令是服务端实现，而pipeline需要服务端与客户端共同完成

Pipeline 与事务对比

事务具有原子性，管道不具有原子性
管道一次性将多条命令发送到服务器，事务是一条一条发的，事务只有在接收到exec命令后才会执行，管道不会
执行事务时会阻塞其他命令的执行，而执行管道中的命令时不会

Pipeline 注意事项

pipeline缓冲的指令只是会依次执行，不保证原子性，如果执行中指令发生异常，将会继续执行后续的指令
使用pipeline组装的命令个数不能太多，不然数据量过大客户端阻塞的时间可能过久，同时服务器也被迫回复一个队列答复，占用很多内存

3.4 发布和订阅

什么是发布订阅？

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

Redis 的 subscribe 命令可以让客户端订阅任意数量的频道，每当有新信息发送到被订阅的频道时，信息就会被发送给所有订阅指定频道的客户端。

☛ 下图展示了频道 channel1 ，以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：

当有新消息通过 publish 命令发送给频道 channel1 时，这个消息就会被发送给订阅它的三个客户端：

为什么要用发布订阅？

熟悉==消息中间件==的同学都知道，针对消息订阅发布功能，市面上很多大厂使用的是kafka、RabbitMQ、ActiveMQ, RocketMQ等这几种，redis的订阅发布功能跟这三者相比，相对轻量，针对数据准确和安全性要求没有那么高可以直接使用，适用于小公司。

redis 的List数据类型结构提供了 blpop 、brpop 命令结合 rpush、lpush 命令可以实现消息队列机制，基于双端链表实现的发布与订阅功能

这种方式存在两个局限性：

不能支持一对多的消息分发。
如果生产者生成的速度远远大于消费者消费的速度，易堆积大量未消费的消息

◇ 双端队列图解如下：

✦ **解析：**双端队列模式只能有一个或多个消费者轮着去消费，却不能将消息同时发给其他消费者

◇ 发布/订阅模式图解如下：

**解析：**redis订阅发布模式，生产者生产完消息通过频道分发消息，给订阅了该频道的所有消费

发布/订阅如何使用？

Redis有两种发布/订阅模式：

基于频道(Channel)的发布/订阅

基于模式(pattern)的发布/订阅

操作命令如下

序号	命令与描述
● 基于频道
subscribe channel [channel ... ]	订阅给定的一个或多个频道
unsubscribe channel [channel ... ]	退订给定的频道。说明：若没有指定channel，则默认退订所有频道
publish channel message	将消息发送给指定频道 channel。返回结果：接收到信息的订阅者数量，无订阅者返回0
pubsub channels [argument [atgument ...] ]	查看订阅与发布系统的状态。说明：返回活跃频道列表（即至少有一个订阅者的频道，订阅模式的客户端除外）
pusub channels	显示由活跃频道组成的列表
pusub numsub channel1 [channel2 ....]	显示某个频道有几个订阅者
pubsub numpat	只统计使用PUBSCRIBE 命令执行的，返回客户端订阅的唯一模式的数量
● 基于模式
psubscribe pattern1 [pattern...]	订阅一个或多个符合给定模式的频道。说明：每个模式以 * 作为匹配符；例如 cn* 匹配所有以cn开头的频道：cn.java、cn.csdn
punsubscribe [pattern [pattern ...] ]	退订所有给定模式的频道。说明：pattern 未指定，则订阅的所有模式都会被退订，否则只退订指定的订阅的模式

PUSUB CHANNELS // 由活跃频道组成的列表 PUSUB NUMSUB channel [channel...] // 某个频道有几个订阅者 PUBSUB NUMPAT // 只统计使用PUBSCRIBE 命令执行的，返回客户端订阅的唯一模式的数量

基于频道(Channel)的发布/订阅

"发布/订阅" 包含2种角色：发布者和订阅者。发布者可以向指定的频道(channel)发送消息；订阅者可以订阅一个或者多个频道(channel)，所有订阅此频道的订阅者都会收到此消息。

订阅者订阅频道 subscribe channel [channel ...]

Shell

--------------------------客户端1（订阅者） ：订阅频道 ---------------------
 
# 订阅 “meihuashisan” 和 “csdn” 频道（如果不存在则会创建频道）
127.0.0.1:6379> subscribe meihuashisan csdn   
# 一旦进行订阅频道，退出则断开连接。
Reading messages... (press Ctrl-C to quit)
 
1) "subscribe"    -- 返回值类型：表示订阅成功！
2) "weixin"       -- 订阅频道的名称
3) (integer) 1    -- 当前客户端已订阅频道的第几个数量
 
1) "subscribe"
2) "csdn"
3) (integer) 2   -- 订阅的第2个频道
 
#注意：订阅后，该客户端会一直监听消息，如果发送者有消息发给频道，这里会立刻接收到消息

发布者发布消息 publish channel message

Shell

--------------------------客户端2（发布者）：发布消息给频道 -------------------
 
 
# 给“weixin”这个频道 发送一条消息：“I am xiaowang”
127.0.0.1:6379> publish weixin "I am xiaowang"
(integer) 1  # 接收到信息的订阅者数量，无订阅者返回0

客户端2 (发布者) 发布消息给频道后，此时我们再来观察 客户端1 (订阅者) 的客户端窗口变化：

Shell

# --------------------------客户端1（订阅者） ：订阅频道 -----------------
 
127.0.0.1:6379> subscribe weixin csdn 
Reading messages... (press Ctrl-C to quit)
 
1) "subscribe"    -- 返回值类型：表示订阅成功！
2) "weixin" -- 订阅频道的名称
3) (integer) 1    -- 当前客户端已订阅频道的数量
 
1) "subscribe"
2) "csdn"
3) (integer) 2
 
 
 
 ---------------------变化如下：（实时接收到了该频道的发布者的消息）------------
 
1) "message"           -- 返回值类型：消息
2) "weixin"            -- 来源（从哪个频道发过来的）
3) "I am xiaowang"     -- 消息内容

命令操作图解如下：

注意：如果是先发布消息，再订阅频道，不会收到订阅之前就发布到该频道的消息！

注意：进入订阅状态的客户端，不能使用除了subscribe、unsubscribe、psubscribe 和 punsubscribe 这四个属于"发布/订阅"之外的命令，否则会报错！

——这里的客户端指的是 jedis、lettuce的客户端，redis-cli是无法退出订阅状态的！

★ 实现原理

底层通过字典实现。pubsub_channels 是一个字典类型，保存订阅频道的信息：字典的key为订阅的频道，字典的value是一个链表，链表中保存了所有订阅该频道的客户端

C

struct redisServer { 
  /* General */ 
  pid_t pid; 
 
  //省略百十行 
 
  // 将频道映射到已订阅客户端的列表(就是保存客户端和订阅的频道信息)
  dict *pubsub_channels; /* Map channels to list of subscribed clients */ 
}

实现图如下：

**频道订阅：**订阅频道时先检查字段内部是否存在；不存在则为当前频道创建一个字典且创建一个链表存储客户端id；否则直接将客户端id插入到链表中。

**取消频道订阅：**取消时将客户端id从对应的链表中删除；如果删除之后链表已经是空链表了，则将会把这个频道从字典中删除。

**发布：**首先根据 channel 定位到字典的键，然后将信息发送给字典值链表中的所有客户端

基于模式(pattern)的发布/订阅

如果有某个/某些模式和该频道匹配，所有订阅这个/这些频道的客户端也同样会收到信息。

模式，其实就是匹配模式。这样我们可以进行分组，然后在进行发布信息。

图解

下图展示了一个带有频道和模式的例子，其中 com.ahead.* 频道匹配了 com.ahead.juc 频道和 com.ahead.thread 频道，并且有不同的客户端分别订阅它们三个，如下图：

当有信息发送到com.ahead.thread 频道时，信息除了发送给 client 4 和 client 5 之外，还会发送给订阅 com.ahead.* 频道模式的 client x 和 client y

✦ **解析：**反之也是，如果当有消息发送给 com.ahead.juc 频道，消息发送给订阅了 juc 频道的客户端之外，还会发送给订阅了 com.ahead.* 频道的客户端： client x 、client y

通配符中?表示1个占位符，*表示任意个占位符(包括0)，?*表示1个以上占位符。

订阅者订阅频道 psubscribe pattern [pattern ...]

Shell

--------------------------客户端1（订阅者） ：订阅频道 ---------------------
 
 
#  1. ------------订阅 “a?” "com.*" 2种模式频道--------------
127.0.0.1:6379> psubscribe a? com.*
# 进入订阅状态后处于阻塞，可以按Ctrl+C键退出订阅状态
Reading messages... (press Ctrl-C to quit) 
 
 
 
# 2. ---------------订阅成功-------------------
 
1) "psubscribe"  -- 返回值的类型：显示订阅成功
2) "a?"          -- 订阅的模式
3) (integer) 1   -- 目前已订阅的模式的数量
 
 
1) "psubscribe"
2) "com.*"
3) (integer) 2
 
 
 
# 3. ---------------接收消息 （已订阅 “a?” "com.*" 两种模式！）-----------------
 
# ---- 发布者第1条命令： publish ahead "hello"
结果：没有接收到消息，匹配失败，不满足 “a?” ，“？”表示一个占位符， a后面的head有4个占位符
 
 
# ---- 发布者第2条命令：  publish aa "hello" （满足 “a?”）
1) "pmessage" -- 返回值的类型：信息
2) "a?"       -- 信息匹配的模式：a?
3) "aa"       -- 信息本身的目标频道：aa
4) "hello"    -- 信息的内容："hello"
 
 
# ---- 发布者第3条命令：publish com.juc "hello2"（满足 “com.*”, *表示任意个占位符）
1) "pmessage" -- 返回值的类型：信息
2) "com.*"    -- 匹配模式：com.*
3) "com.juc"  -- 实际频道：com.juc
4) "hello2"   -- 信息："hello2"
 
# ---- 发布者第4条命令： publish com. "hello3"（满足 “com.*”, *表示任意个占位符）
1) "pmessage" -- 返回值的类型：信息
2) "com.*"    -- 匹配模式：com.*
3) "com."     -- 实际频道：com.
4) "hello3"   -- 信息："hello3"

发布者发布消息 publish channel message

Shell

--------------------------客户端2（发布者）：发布消息给频道 -------------------
 
注意：订阅者已订阅 “a?” "com.*" 两种模式！
 
 
# 1. ahead 不符合“a?”模式，?表示1个占位符
127.0.0.1:6379> publish ahead "hello"  
(integer) 0    -- 匹配失败，0:无订阅者
 
 
# 2. aa 符合“a?”模式，?表示1个占位符
127.0.0.1:6379> publish aa "hello"      
(integer) 1
 
# 3. 符合“com.*”模式，*表示任意个占位符
127.0.0.1:6379> publish com.juc "hello2" 
(integer) 1
 
# 4. 符合“com.*”模式，*表示任意个占位符
127.0.0.1:6379> publish com. "hello3" 
(integer) 1

命令操作图解如下：

★ 实现原理

底层是pubsubPattern节点的链表

C

struct redisServer {
    //...
    list *pubsub_patterns; 
    // ...
}
 
// 1303行订阅模式列表结构：
typedef struct pubsubPattern {
    client *client;  -- 订阅模式客户端
    robj *pattern;   -- 被订阅的模式
} pubsubPattern;

实现图如下：

模式订阅：新增一个pubsub_pattern数据结构添加到链表的最后尾部，同时保存客户端ID。

取消模式订阅：从当前的链表pubsub_pattern结构中删除需要取消的pubsubPattern结构。

使用小结

订阅者(listener)负责订阅频道(channel)；发送者(publisher)负责向频道发送二进制的字符串消息，然后频道收到消息时，推送给订阅者。

✦ 使用场景

电商中，用户下单成功之后向指定频道发送消息，下游业务订阅支付结果这个频道处理自己相关业务逻辑
粉丝关注功能
文章推送

✦ 使用注意

客户端需要及时消费和处理消息。

客户端订阅了channel之后，如果接收消息不及时，可能导致DCS实例消息堆积，当达到消息堆积阈值（默认值为32MB），或者达到某种程度（默认8MB）一段时间（默认为1分钟）后，服务器端会自动断开该客户端连接，避免导致内部内存耗尽。

客户端需要支持重连。

当连接断开之后，客户端需要使用subscribe或者psubscribe重新进行订阅，否则无法继续接收消息。

不建议用于消息可靠性要求高的场景中。

Redis的pubsub不是一种可靠的消息系统。当出现客户端连接退出，或者极端情况下服务端发生主备切换时，未消费的消息会被丢弃。

3.5 主从复制

3.5.1 学习需要掌握的点：

1.基本概念：为什么存在？有什么优点和缺点

2.使用的基本命令和配置

3.使用的策略有什么？主从，树型，中间结点变主结点

4.衍生的方法：哨兵，集群

3.5.2 定义：

主从复制是为了达成==高可用==

为了避免单点Redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的。
即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，同时实现数据冗余备份。

在这里插入图片描述

提供数据方：master
- 主服务器，主节点，主库主客户端
接收数据方：slave
- 从服务器，从节点，从库从客户端
需要解决的问题
- 数据同步
核心工作
- master的数据复制到slave中

主从复制

主从复制即将master中的数据即时、有效的复制到slave中
一个master可以拥有多个slave，一个slave只对应一个master
master职责:
- 写数据
- 执行写操作时，将出现变化的数据自动同步到slave
- 读数据（可忽略）
slave职责:
- 读数据
- 写数据（禁止）

正式的定义：

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower) ; ==数据的复制是单向的，只能由主节点到从节点==。Master以写为主，Slave以读为主。

==默认情况下，每台Redis服务器都是主节点 ;==

且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

优点：

读写分离：主节点写，从节点读，提高服务器的读写负载能力
**数据冗余︰**主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复︰当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复 ; 实际上是一种服务的冗余。
**负载均衡︰**在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载 ; 尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
高可用（集群）基石︰除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

3.5.3基础命令：

主从复制更像一个机制（命令很少），只需要配置即可。

命令：info replication （获取主/从服务器的详细信息）

命令：slaveof/replicaof [ master-ip ] [ master-port ] :可以使正在复制其它节点的 Redis 改为复制新的 hostname 和 port。

这个命令其实就是选择进行复制的ip和端口。在哪台服务器上使用，哪台服务器会变成从机

PS:replicaof是新版本(5.0之后)的命令，旧版本是slaveof命令

（临时的，永久的必须通过 redis.conf 里面的 slaveof设置）

命令：slaveof/replicaof no one 使当前数据库停止与其他数据库的同步，升级为主数据库

停止复制节点，在默认的情况下就是主机（master/leader）

注意防火墙配置命令：

因为主机的防火墙可能不会让从机（其他端口）连接上主机

启动防火墙： systemctl start firewalld 关闭防火墙： systemctl stop firewalld 查看防火墙状态： systemctl status firewalld 开机禁用防火墙： systemctl disable firewalld 开机启用防火墙： systemctl enable firewalld

添加端口为80为白名单：firewall-cmd --zone=public --add-port=80/tcp --permanent
TEXT
  						（--permanent永久生效，没有此参数重启后失效）
在添加设置后，需要重新启动防火墙

重新载入： firewall-cmd --reload

查看指定白名单信息： firewall-cmd --zone= public --query-port=80/tcp

查看所有白名单信息firewall-cmd --zone=public --list-ports

删除指定port白名单： firewall-cmd --zone= public --remove-port=80/tcp --permanent

3.5.4 配置文件配置策略

关键（服务器中redis.conf的配置）：

基本配置（每个服务器根据情况进行修改）：

Bash

# 后台启动服务。默认no 
daemonize yes # 设置为yes
# bind 用来设置服务绑定到的 IP 地址或网络接口
#bind 127.0.0.1 # 给注释掉,暴露在外
# 保护模式。默认yes
protected-mode no
# 指定端口号 port 6379
port 6379
# 指定当前工作目录 dir
dir /xxxx
# pid文件地址  进程配置文件 
pidfile "/var/run/redis_6379.pid"
# log文件名字 logfile
logfile "/myredis/6379.log"
# 设置密码
requirepass  123456
# 设置RDB文件名称
dbfilename dump6379.rdb
# 是否打开AOF配置
appendonly yes 
# 修改AOF文件名称
appendfilename appendonly.aof


# 连接主机的密码，不管是主机还是从机都有可能变成从机，这样还是要设置密码的
masterauth "123456"

ps: 这是虚拟机的基础配置，有些可以不配置。

最重要的区别是：bind和 port配置，bind关闭，则允许其他ip访问，这样就可以建立主从策略。port 每个服务器都不一样的。

==注意：在主机上配置了密码，即授权访问==

授权访问：（需要注意的点）

1.master端设置密码

master客户端在设置密码

Bash

# 在redis.conf中设置密码
requirepass 123456
# 使用命令的形式设置密码
config set requirepass <password>
config get requirepass

2.在slave端使用密码登录

Bash

# 在启动时
redis-server –a <password>
# slave客户端发送命令设置密码(登录时)
auth <password>
# slave配置文件设置密码（在redis.conf中）
masterauth <password>

从机上附加的配置:(这些是在主机redis.conf中没有的)

配置连接上主机的ip、端口、密码

Bash

# 需要复制的ip和端口号(需要连接的主机ip和端口)
replicaof ip地址 端口号
# 连接主机的密码
masterauth "123456"

3.5.5 配置的策略（基于配置文件进行永久性配置）：

1.一个主机，n个从机（2层树型结构）

在这里插入图片描述

角色分布：（举例用1台主机，2台从机）

一台master
- 端口号：6379
- ip：192.168.182

配置细节：

在该虚拟机下redis下的redis.conf 配置文件设置：

Bash

# 指定端口号 port 6379
port 6379
# 设置密码
requirepass  123456

一台slaveA
- 端口号：6380
- ip：192.168.173

配置细节：

在该虚拟机下redis下的redis.conf 配置文件设置：

Bash

# 指定端口号 port 6380
port 6380
# 需要复制的ip和端口号(需要连接的主机ip和端口)
replicaof 192.168.182 6379
# 连接主机的密码
masterauth "123456"

一台slaveB
- 端口号：6382
- ip：192.168.165

Bash

# 指定端口号 port 6380
port 6380
# 需要复制的ip和端口号(需要连接的主机ip和端口)
replicaof 192.168.182 6379
# 连接主机的密码
masterauth "123456"

启动顺序：

先启动master再启动其他从机

1、在master主机6379上

Bash

redis-cli -ip 192.168.173 -p 6379 -a 123456

2、在slaveA主机6380上

Bash

redis-cli  -ip 192.168.173 -p 6380 -a 123456

3、在slaveB主机6382上

Bash

redis-cli  -ip 1192.168.165 -p 6382 -a 123456

查看是否连接成功：

1.日志查看

在之前的配置中，设置了logfile的路径，在这里查看即可

==暂时没有搞懂怎么查看==

Bash

# 查看主机日志信息,显示这个即可
Synchronization with replica 192.168.173:6380 succeeded	
...
Synchronization with replica 192.168.165:6382 succeeded	

# 查看从机日志信息,显示刷新了old data ，重新加载了DB内存即可
MASTER <-> REPLICA sync: receiving 361 bytes from master to disk
2125:S 18 Apr 2025 09:27:01.525 * MASTER <-> REPLICA sync: Flushing old data
2125:S 18 Apr 2025 09:27:01.525 * MASTER <-> REPLICA sync: Loading DB in memory

2.客户端命令查看

语法：info replication

Bash

info replication
# 在主机查看上，显示
# Replication
role:master   			 ----角色为master
connected_slaves:2		 ----连接的从机为2个
# 在从机查看上，显示
# Replication	
role:slave				----角色为slave
master_host:127.0.0.1	----连接主机的ip
master_port:6379		----连接主机的端口

2.薪火相传（3层及以上的结构）

上一个slave可以是下一个slave的master，slave同样可以接收其它slave的连接和同步请求，那么该slave作为了链条中下一个master，可以有效的减轻主master的写压力

中途变更转向，会清除之前的数据，重新建立拷贝最新的数据

怎么变？

关键命令：slaveof/replicaof no one 使当前数据库停止与其他数据库的同步，升级为主数据库

这个命令可以将某个结点主机给断开连接，不再复制master的命令

然后就可以去连接其他主机了

命令：slaveof/replicaof [ master-ip ] [ master-port ] :可以使正在复制其它节点的 Redis 改为复制新的 hostname 和 port。

3.反客为主（将从机变成主机）

使当前数据库停止与其它数据库的同步，转换成主数据库（奴隶翻身成主人了）

3.5.6 基于命令的配置策略

去掉配置文件中配置的从属关系
replicaof/slaveof no one 升级为主机
replicaof/slaveof 主库IP 主库端口称为主库的从机
配置VS命令的区别
- 配置，持久稳定
- 命令，当次生效

3.5.7 复制的原理

**1.保存主节点信息：**从节点保存主节点的 IP + PORT（IP和端口）信息。

**2.主从建立连接：**从节点向主节点发起三次握手，==建立 TCP 连接==。(在系统层面上验证双方通信信道是否正常)

**3.发送 ping 命令：**从节点向主节点发送 ping，主节点返回 pong。(在应用层面上验证主节点能够正常工作)

**4.权限验证：**如果==主节点设置了 requirepass 参数，需要进行密码验证==。

**5.同步数据集：**对于首次建立复制的场景，主节点会把当前持有的所有数据全部发送给从节点，即全量同步；对于断开重连的从节点，会==根据情况进行全量同步或部分同步。==

**6.命令持续复制：**当从节点复制了主节点的所有数据之后，针对之后的修改命令，主节点会持续的把命令发送给从节点，从节点执行修改命令，保证主从数据的一致性。

PSYNC数据同步

==PSYNC（Partial SYNChronization）是Redis复制（Replication）机制中的一种数据同步方式，用于在主从复制场景中高效地同步数据。==PSYNC支持全量同步和增量同步两种方式，以确保主从节点之间的数据一致性。

全量复制：==一般用于初次复制场景==，Redis 早期支持的复制功能只有全量复制，它会把主节点全部数据一次性发送给从节点，当数据量较大时，==会对主从节点和网络造成很大的开销。==
部分复制：==用于处理在主从复制中因网络闪断等原因造成的数据丢失场景==，当从节点再次连上主节点后，如果条件允许，主节点会补发数据给从节点。因为补发的数据远小于全量数据，可以==有效避免全量复制的过高开销。==

从节点在与主节点建立好主从关系后会自动执行 psync 进行数据同步，不需要我们手动执行。

全量复制流程（类比HTTP三次握手）

1.从节点发送 PSYNC 命令给主节点进行数据同步，由于是第一次进行复制，从节点没有主节点的运行 ID 和复制偏移量，所以发送 PSYNC ? -1。

2.主节点根据命令，解析出要进行全量复制，回复 +FULLRESYNC 响应。

3.从节点接收主节点的运行信息进行保存，包括主节点的 replid 与当前的 offset。

4.主节点执行 BGSAVE 进行 RDB 文件的持久化。

5.主节点发送 RDB 文件给从节点，从节点保存 RDB 数据到本地硬盘 (全量数据)。

6.主节点将从生成 RDB 到接收完成期间执行的写命令写入缓冲区中，等从节点保存完 RDB 文件后，主节点再将缓冲区内的数据补发给从节点，补发的数据仍然按照 RDB 的二进制格式追加写入到收到的 RDB 文件中，保持主从一致性 (增量数据)。

7.从节点清空自身原有旧数据。

8.从节点加载 RDB 文件得到与主节点一致的数据。

9.如果从节点加载 RDB 完成之后，并且开启了 AOF 持久化功能，它会进行 BGREWRITE 操作，得到最近的 AOF 文件

部分复制流程

1.当主从节点之间出现网络中断时，如果超过 repl-timeout 时间，主节点会认为从节点故障并终止复制连接。

2.主从连接中断期间主节点依然响应命令，但这些复制命令都因网络中断无法及时发送给从节点，所以暂时将这些命令滞留在复制积压缓冲区 repl-backlog-buffer 中。

3.当主从节点网络恢复后，从节点再次连上主节点。

4.从节点将之前保存的 replicationId 和复制偏移量作为 PSYNC 的参数发送给主节点，请求进行部分复制。 5.主节点接到 PSYNC 请求后，进行必要的验证。然后根据 offset 去 repl-backlog-buffer 查找合适的数据，并响应 +CONTINUE 给从节点。

6.主节点将需要从节点同步的数据发送给从节点，最终完成一致性。

实时复制流程

主从节点在建立复制连接后，会进行实时复制 (实时数据同步)。主节点会把自己收到的修改命令，通过 TCP 长连接的方式，源源不断地传输给从节点==(注意发送的是命令而不是二进制数据)==。从节点会根据这些请求来同时修改自身的数据，以保持和主节点数据的一致性。

另外，这样的长连接，需要通过心跳包的方式来维护连接状态：(这里的心跳是指应用层自己实现的心跳，而不是 TCP 自带的心跳)

主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通信。
主节点默认每隔 10 秒对从节点发送 ping 命令，判断从节点的存活性和连接状态。
从节点默认每隔 1 秒向主节点发送 replconf ack {offset} 命令，==给主节点上报自身当前的复制偏移量。==

如果主节点发现从节点通信延迟超过 repl-timeout 配置的值（默认 60 秒），则判定从节点下线，断开复制客户端连接。从节点恢复连接后，心跳机制继续进行。

slave启动，同步初请

①slave启动成功连接到master后会发送一个sync命令

②slave首次全新连接到master，一次完全同步（全量复制）将会被自动执行，slave自身原有的数据将会被master数据覆盖清除

首次连接，全量复制

①master节点收到sync命令后会开始在后台保存快照（RDB持久化，主从复制时会触发RDB），同时收集所有接收到的用于修改数据库集命令缓存起来，master节点执行RDB持久化后，master将RDB快照文件和所有缓存的命令发送到所有slave，以完成一次完全同步

②而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化

心跳持续，保持通信

master继续将新的所有收集到的修改命令自动依次传给slave，完成同步

进入平稳，增量复制

master继续将新的所有收集到的修改命令自动依次传给slave，完成同步

从机下线，重连续传

master会检查backlog里面的offset，master和slave都会保存一个复制的offset还有一个masterid，offset是保存在backlog中的。master只会把已经复制的offset后面的数据复制给slave，类似断点续传

缺点

①复制延时，信号衰减

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

②主机挂机后，需要手动指定新的主机

参考文献（这个可以当八股文看看）

https://blog.csdn.net/Cantevenl/article/details/115839649

https://blog.csdn.net/2402_88002981/article/details/145132258

3.6 哨兵

哨兵：重在配置，然后就是配置过程中的细节。

学习目标：基础的配置过程，原理（八股文）

介绍：

哨兵巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务，俗称无人值守运维
哨兵是独立的进程，一般有**几台单独的服务器（奇数台）**来建立
作用
- 监控redis运行状态，包括master和slave
- 当master down机，能自动将slave切换成新master
哨兵的四个功能
- 主从监控:
  - 监控主从redis库运行是否正常
- 消息通知:
  - 哨兵可以将故障转移的结果发送到客户端
- 故障转移（failover）:
  - 如果master异常，则会进行主从切换，将其中一个slave作为新master
- 配置中心
  - 客户端通过连接哨兵来获得当前Redis服务的主节点地址

在这里插入图片描述

在这里插入图片描述

3个哨兵
- 自动监控和维护集群，不存放数据，只是监控
- 多个哨兵，不仅同时监控主从Redis，而且哨兵之间互为监控，防止哨兵单点故障。
1主2从
- 用于数据读取和存放

==这个小章节以功能的形式书写，把配置总结放在最后==

监控：

Sentinel 是单独的进程，在默认情况下，Sentinel 每秒一次的频率向所有（包括 Master、Slave、其他 Sentinel 在内）发送 PING 命令，如果 slave 没有在在规定时间内响应「哨兵」的 PING 命令，「哨兵」就认为这哥们可能嗝屁了，就会将他记录为「下线状态」；

假如 master 没有在规定时间响应「哨兵」的 PING 命令，哨兵就判定master下线，开始执行「自动切换 master 」的流程。

PING 命令的回复有两种情况：

有效回复：返回 +PONG、-LOADING、-MASTERDOWN 任何一种；

无效回复：有效回复之外的回复，或者再指定时间内返回任何回复。

为了防止master「假死」，「哨兵」设计了「主观下线」和「客观下线」两种暗号。

主观下线

Sentinel对master和slave进行ping（心脏跳动），对应的master和slave进行回应，当其没有回复时，主观认定下线了。

其中：slave部分停止了，不会进行故障转移（只是备份机停了）。但是master停了，这就需要考虑是否要拿另一个主机做master了

问题：怎么考虑到master停止了，准确吗？拿另一个主机做master，选择的标准是什么?

问题1：怎么考虑到master停止了，准确吗？

因为一个Sentinel发现master停止了，可能是误判，即这个Sentinel自身网络断了等原因，这就需要其他Sentinel一起来投票判断了

这就是投票机制。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。

同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。

客观下线

判断 master 是否下线不能只有一个「哨兵」说了算，只有过半的哨兵判断 master 已经「主观下线」，这时候才能将 master 标记为「客观下线」，也就是说这是一个客观事实，掌门真的嗝屁了，华佗再世也治不好了。

只有 master 被判定为「客观下线」，才会进一步触发哨兵开始主从切换流程。

客观下线

主观下线与客观下线的区别

主观下线（SO）：

哨兵检测到主节点失联（如主节点响应超时、无法连接）。
哨兵认为主节点不可用时，它会将主节点标记为“主观下线”。
这种标记仅对该哨兵有效，其他哨兵可能并未察觉主节点的故障。

客观下线（O）：

当超过半数的哨兵认为主节点失联时（即超过“quorum”数量的哨兵确认主节点不可用），则主节点会被标记为“客观下线”。
此时，触发故障转移操作，进行主节点切换。

对应命令：

Bash

sentinel monitor <master-name> <master-host> <master-port> <quorum>

quorum怎么设置？

一般设置为总哨兵数/2+1，也可以设置为全部哨兵

原因：投票机制（半数以上，这也是为什么有奇数个哨兵）：

这里的「一定数量」是一个法定数量（Quorum），是由哨兵监控配置决定的，解释一下该配置

<quorum>：法定数量，代表只有<quorum>个及以上的哨兵认为主节点不可用的时候，才会把 master 设置为客观下线状态，然后进行 failover 操作。

问题2：拿另一个主机做master，选择的标准是什么?

自动切换主库：(主动触发的机制)

既然判断 master 客观下线了，那就要从选出一个新master了吧。

「哨兵」的第二个任务，选择新 master 。需要从slave中按照一定规则选择一个牛逼人物作为新master，完成选任master后，新 master 带领众弟子一起吃香喝辣。

按照一定的**「筛选条件」 + 「打分」**策略，选出「最强王者」担任master，也就是通过一些条件海选过滤一些「无能之辈」，接着将通过海选的靓仔全都打分排名，将最高者选为新 master。

如图所示：

新master选择

筛选条件

从库当前在线状态，下线的直接丢弃；
评估之前的网络连接状态 down-after-milliseconds * 10：如果从库总是和主库断连，而且断连次数超出了一定的阈值（10 次），我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛掉了。

Bash

# 该哨兵主观下线的时间设置，mymaster为主机名称，5000为ms
sentinel down-after-milliseconds mymaster 5000

打分

过滤掉不合适的 slave 之后，则进入打分环节。打分会按照三个规则进行三轮打分，规则分别为：

slave 优先级，通过 slave-priority 配置项，给不同的从库设置不同优先级（后台有人没办法），优先级高的直接晋级为新 master 。
slave_repl_offset与 master_repl_offset进度差距（谁的武功与之前master的功夫越接近谁就更牛逼），如果都一样，那就继续下一个规则。其实就是比较 slave 与旧 master 复制进度的差距；
slave runID，在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。（论资排辈，根据 runID 的创建时间来判断，时间早的上位）；

消息通知：

这个范围很广，包含哨兵通过pub/sub订阅的方式进行相互通知，通知slave和客户度Client等选择了新的master等

1、pub/sub 实现哨兵间通信和发现 slave

哨兵之间是如何知道彼此的？

哨兵之间可以相互通信约会搞事情，主要归功于 Redis 的 pub/sub 发布/订阅机制。

哨兵与 master 建立通信，利用 master 提供发布/订阅机制发布自己的信息，比如身高体重、是否单身、IP、端口……

master 有一个 __sentinel__:hello 的专用通道，用于哨兵之间发布和订阅消息。这就好比是 __sentinel__:hello 微信群，哨兵利用 master 建立的微信群发布自己的消息，同时关注其他哨兵发布的消息。

当多个哨兵实例都在主库上做了发布和订阅操作后，它们之间就能知道彼此的 IP 地址和端口，从而相互发现建立连接。

Redis 通过频道的方式对消息进行分别管理，这里的频道其实就是不同的微信群。

怎么跟 slave 建立连接？（向master发送INFO命令）

除此之外，如果发生了主从切换也得通知 slave 重新跟新 master 建立连接执行数据同步。关于主从架构数据同步原理可移步《Redis 高可用篇：你管这叫主从架构数据一致性同步》。

关键还是利用 master 来实现，哨兵向 master 发送 ==INFO== 命令， master 掌门自然是知道自己门下所有的 salve 小弟的。所以 master 接收到命令后，便将 slave 列表告诉哨兵。

哨兵根据 master 响应的 slave 名单信息与每一个 salve 建立连接，并且根据这个连接持续监控哨兵。

如图所示，哨兵 2 向 Master 发送 INFO 命令，Master 就把 slave 列表返回给哨兵 2，哨兵 2 便根据 slave 列表连接信息与每一个 slave 建立连接，并基于此连接实现持续监控。

剩下的哨兵也同理基于此实现监控。

INFO命令获取slave信息

2、重新选举新 master（Raft算法选出领导者节点）

重新选举新 master 掌门这种事情，何等大事，怎能不告知天下。再者其他 slave 弟子也要知道新掌门是谁，一起追随新掌门吃香喝辣大保健。

最后一个任务，「哨兵」将新「master 掌门」的连接信息发送给其他 slave 武当弟子，并且让 slave 执行 replacaof 命令，和新「master 掌门」建立连接，并进行数据复制学习新掌门的所有武功。

除此之外，「哨兵」还需要将新掌门的连接信息通知整个武林（客户端），使得让所有想拜访、讨教的人能找到新任掌门，这样诸多事宜才能交给新掌门做决定（将读写请求转移到新 master）。

哨兵执行任务与目标

故障转移：(被动触发的机制)

当master被认定客观下线后，会进行故障转移

语法：

Bash

#表示如果30秒后,mysater仍没活过来，则启动failover，从剩下的slave中选一个升级为master
sentinel failover-timeout mymaster 30000

master 嗝屁了以后，哨兵这么多，那到底让哪一个哨兵来执行新 master 切换呢？

这个跟哨兵判断 master “客观下线”类似，也是通过投票的方式选出来的。

任何一个哨兵判断 master “主观下线”后，就会给其他哨兵基友发送 is-master-down-by-addr 命令，好基友则根据自己跟 master 之间的连接状况分别响应 Y 或者 N ，Y 表示赞成票， N 就是反对。

如果某个哨兵获得了大多数哨兵的“赞成票”之后，就可以标记 master 为 “客观下线”，赞成票数是通过哨兵配置文件中的 quorum 配置项设定。

sentinel monitor <master-name> <ip> <redis-port> <quorum>

比如一共 3 个哨兵组成集群，那么 quorum 就可以配置成 2，当一个哨兵获得了 2 张赞成票，就可以标记 master “客观下线”，当然这个票包含自己的那一票。

获得多数赞成票的哨兵可以向其他哨兵发送命令，申明自己想要执行主从切换。并让其他哨兵进行投票，投票过程就叫做 “Leader 选举”。

想要成为 “Leader”没那么简单，得有两把刷子。需要满足以下条件：

获得其他哨兵基友过半的赞成票；
赞成票的数量还要大于等于配置文件的 quorum 的值。

如果哨兵集群有 2 个实例，此时，一个哨兵要想成为 Leader，必须获得 2 票，而不是 1 票。所以，如果有个哨兵挂掉了，那么，此时的集群是无法进行主从库切换的。因此，通常我们至少会配置 3 个哨兵实例。

这也是为啥哨兵集群部署成单数的原因，双数的话多余浪费。

配置中心：

在安装redis时，有一个专门的sentinel.conf来配置

在虚拟机下sentinel.conf来配置

Bash

#关闭保护模式，使外网能访问。
protected-mode no 
#修改端口。三份文件分别不同。
port 26379 
#修改为后台运行。
daemonize no 
#指定不同pid文件，注意文件夹不存在自己要新建。
pidfile /var/run/redis-sentinel.pid 
#配置哨兵日志文件。
logfile ""
#配置哨兵工作路径。
dir "/tmp"
-------------------------------------------------------------
#配置哨兵需要监控的主节点ip和端口，2表示哨兵数（quorum）
sentinel monitor mymaster 192.167.1.123 6379 2
#配置哨兵连接主节点的认证密码。（主节点配置的requirepass）。
sentinel auth-pass mymaster ibethfy
#配置多少毫秒后没收到主节点的反馈，则主观认为主节点down了。
sentinel down-after-milliseconds mymaster 5000
#表示如果30秒后,mysater仍没活过来，则启动failover，从剩下的slave中选一个升级为master
sentinel failover-timeout mymaster 30000
#parallel-syncs 指定了在执行故障转移时， 最多可以有多少个slave同时对新的master进行同步， 这个数字越小， 完成故障转移所需的时间就越长
sentinel parallel-syncs mymaster 1

语法的详细介绍：

配置需要监控的ip，port和quorum

Bash

sentinel monitor <master-name> <master-host> <master-port> <quorum>
 # 举例如下：
 sentinel monitor mymaster 127.0.0.1 6379 2

这条配置项用于告知哨兵需要监听的主节点：

sentinel monitor：代表监控。
mymaster：代表主节点的名称，可以自定义。
192.168.11.128：代表监控的主节点 ip，6379 代表端口。
2：法定数量，代表只有两个或两个以上的哨兵认为主节点不可用的时候，才会把 master 设置为客观下线状态，然后进行 failover 操作。

2.配置哨兵连接主节点的认证密码。（主节点配置的requirepass）。

Bash

sentinel auth-pass 主机名称 访问主机密码

指定了 Sentinel 判断实例进入主观下线所需的时间长度：单位（ms）

Bash

sentinel down-after-milliseconds mymaster 5000

down-after-milliseconds * 10

down-after-milliseconds 是我们认定主从库断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库。

4.slave给新的master转移数据

Bash

sentinel parallel-syncs mymaster 1

parallel-syncs 并行转移。所以后面的数子越小，转移速度越慢

日志信息说明

master 下线事件

+sdown：进入“主观下线”状态；
-sdown：退出“主观下线”状态；
+odown：进入“客观下线”状态；
-odown：退出“客观下线”状态；
==这里+可以理解为ture，代表down，反之==

slave 重新配置事件

+slave-reconf-sent：哨兵发送 replicaof 命令重新配置从库；
+slave-reconf-inprog：slave 配置了新 master，但是尚未进行同步；
+slave-reconf-done：slave 配置了新 master，并与新 master 完成了数据同步；

新主库切换

+switch-master：master 地址发生了变化

Bash

#主服务器已被重置。
+reset-master:
#一个新的从服务器已经被 Sentinel 识别并关联。
+slave:
----------------------------------------
#故障转移状态切换到了 reconf-slaves 状态。
+failover-state-reconf-slaves: 
#另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。
+failover-detected:
--------------------------------------
#领头（leader）的 Sentinel 向实例发送了 [SLAVEOF](/commands/slaveof.html) 命令，为实例设置新的主服务器。
+slave-reconf-sent:
#实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。
+slave-reconf-inprog:
#从服务器已经成功完成对新主服务器的同步。
+slave-reconf-done:
-------------------------------------------
#对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。
-dup-sentinel: 

#一个监视给定主服务器的新 Sentinel 已经被识别并添加。
+sentinel:
----------------------------------
#给定的实例现在处于主观下线状态。
+sdown:
#给定的实例已经不再处于主观下线状态。
-sdown:
#给定的实例现在处于客观下线状态。
+odown:
#给定的实例已经不再处于客观下线状态。
-odown:
---------------------------
#当前的纪元（epoch）已经被更新。
+new-epoch:
#一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。
+try-failover:

#赢得指定纪元的选举，可以进行故障迁移操作了。
+elected-leader:

#故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
+failover-state-select-slave:

#Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
no-good-slave:

#Sentinel 顺利找到适合进行升级的从服务器。
selected-slave:
#Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
failover-state-send-slaveof-noone:

#故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。
failover-end-for-timeout:
#故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
failover-end:

#配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
--------------------------------------------------
+switch-master
#进入 tilt 模式。
+tilt:
#退出 tilt 模式
-tilt:

哨兵集群工作原理（总结）

「哨兵」部门并不是一个人，多个人共同组成一个「哨兵集群」，即使有一些「哨兵」被老王打死了，其他的「哨兵」依然可以共同协作完成监控、新掌门选举以及通知 slave 、master 以及每一个武林人士（客户端）。

在配置哨兵集群的时候，哨兵配置中只设置了监控的 master IP 和 port，并没有配置其他哨兵的连接信息。

sentinel monitor <master-name> <ip> <redis-port> <quorum>

哨兵之间是如何知道彼此的？如何知道 slave 并监控他们的？由哪一个「哨兵」执行主从切换呢？

总结：

为了避免单个哨兵故障后无法进行主从切换，以及为了减少误判率，又引入了哨兵集群；哨兵集群又需要有一些机制来支撑它的正常运行：

基于 pub/sub 机制实现哨兵集群之间的通信；
基于 INFO 命令获取 slave 列表，帮助哨兵与 slave 建立连接；
通过哨兵的 pub/sub，实现了与客户端和哨兵之间的事件通知。

主从切换，并不是随意选择一个哨兵就可以执行，而是通过投票仲裁，选择一个 Leader，由这个 Leader 负责主从切换。

使用建议

哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
哨兵节点的数量应该是奇数个
各个哨兵节点的配置应该一致
如果哨兵节点部署在Docker等容器里，要注意端口的正确映射
哨兵集群+主从复制，并不能保证数据零丢失

参考文章：

https://segmentfault.com/a/1190000039766545#item-6（核心知识点多）

https://blog.csdn.net/m0_63947499/article/details/142059274（配置信息多）

实践：

==未完成==

3.7 Cluster集群

翻译就是簇集群。

由于数据量过大，单个Master复制集难以承担，因此需要对多个复制集进行集群，形成水平扩展每个复制集只负责存储整个数据集的一部分，这就是Redis的集群，其作用是提供在多个Redis节点间共享数据的程序集。

Redis集群是一个提供在多个Redis节点间共享数据的程序集

Redis集群可以支持多个Master

1. Redis Cluster特点

多主多从，去中心化：从节点作为备用，复制主节点，不做读写操作，不提供服务
不支持处理多个key：因为数据分散在多个节点，在数据量大高并发的情况下会影响性能；
支持动态扩容节点：这是我认为算是Rerdis Cluster最大的优点之一；
节点之间相互通信，相互选举，不再依赖sentinel：准确来说是主节点之间相互“监督”，保证及时故障转移

缺点：

Redis集群不保证 强一致性，这意味着在特定的条件下，Redis集群可能会丢掉一些被系统收到的写入请求命令

比如在三主三从的环境下，其中一个master和slave在一个服务器上，其中一个master宕机，这时client发送请求，这个命令就丢失了。

2. Redis Cluster与其它集群模式的区别

相比较sentinel模式，多个master节点保证主要业务（比如master节点主要负责写）稳定性，不需要搭建多个sentinel实例监控一个master节点；
相比较一主多从的模式，不需要手动切换**，具有自我故障检测，故障转移的特点**；
相比较其他两个模式而言，对数据进行分片（sharding），不同节点存储的数据是不一样的；
从某种程度上来说，Sentinel模式主要针对高可用（HA），而Cluster模式是不仅针对大数据量，高并发，同时也支持HA。

3.独有概念

哈希槽介绍

Redis集群使用一种称作一致性哈希的复合分区形式（组合了哈希分区和列表分袂的特征来计算键的归属实例），键的CRC16哈希值被称为哈希槽。比如对于三个Redis节点，哈希槽的分配方式如下：

第一个节点拥有0-5500哈希槽
第二节点拥有5501-11000哈希槽
第三节点拥有剩余的11001-16384哈希槽

　　一个键的对应的哈希槽通过计算键的CRC16 哈希值，然后对16384进行取模得到：HASH_SLOT=CRC16(key) modulo 16384，Redis提供了CLUSTER KEYSLOT命令来执行哈希槽的计算：

2^14 = 16384

crc16是校验算法

4.Redis集群分布式存储

Redis集群分布式存储有大概有3种解决方法

哈希取余分区
一致性哈希算法分区
哈希槽分区

哈希取余分区

hash(key) % N个机器台数，计算出哈希值，用来决定数据映射到哪一个节点上。

在这里插入图片描述

优点：
- 简单粗暴，直接有效，只需要预估好数据规划节点例如3台、8台、10台，就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡+分而治之的作用。
缺点：
- 直接规划好节点，进行扩容或者缩容会很麻烦，不管扩还是缩，每次数据变动会导致节点有变动，映射关系都要重新计算，在服务器个数固定不变时没有问题。
- 如果需要弹性扩容或故障停机的情况下，原来的取模公式就会发生变化，Hash(key)/3会变成Hash(key) /?。此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。
- 某个redis机器宕机了，由于台数数量变化，会导致hash取余全部数据重新洗牌。

一致性哈希算法分区

提出一致性Hash解决方案。目的是当服务器个数发生变动时，尽量减少影响客户端到服务器的映射关系

三个步骤 1、算法构建一致性哈希环

一致性哈希算法必然有个hash函数并按照算法产生hash值，这个算法的所有可能哈希值会构成一个全量集，这个集合可以成为一个hash空间$[0,2^{32}-1]$，这个是一个线性空间，但是在算法中，我们通过适当的逻辑控制将它首尾相连(0 连接$ 2^{32}$),这样让它逻辑上形成了一个环形空间。

在这里插入图片描述

它也是按照使用取模的方法，前面笔记介绍的节点取模法是对节点（服务器）的数量进行取模。而一致性Hash算法是对$hash(key) % 2^{32}$，简单来说，一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数H的值空间为$0——2^{32}-1$（s即哈希值是一个32位无符号整形），整个哈希环如上图：整个空间按顺时针方向组织，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、……。

2.服务器IP节点映射

将集群中各个IP节点映射到环上的某一个位置。
将各个服务器使用Hash进行一个哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置。假如4个节点NodeA、B、C、D，经过IP地址的哈希函数计算($hash(ip) %2^{32}$)，使用IP地址哈希后在环空间的位置如下：

在这里插入图片描述

3.key 落到服务器的落键规则

当我们需要存储一个kv键值对时，首先计算key的hash值，hash(key)，将这个key使用相同的函数Hash计算出哈希值并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器，并将该键值对存储在该节点上。

优点

采用客户端分片方式：哈希 + 顺时针(优化取余)

假设Node C宕机，可以看到此时对象A、B、D不会受到影响，只有C对象被重定位到Node D。一般的，在一致性Hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。简单说，就是C挂了，受到影响的只是B、C之间的数据，并且这些数据会转移到D进行存储。

相当于C宕机了，原本在B和C之间的数据就受影响了，就会继续顺时针向前找服务器。这样速度就变慢了

节点伸缩时，只影响邻近节点，但是还是有数据迁移

数据量增加了，需要增加一台节点NodeX，X的位置在A和B之间，那受到影响的也就是节点A到节点X之间的数据，重新把A到X的数据录入到X上即可，不会导致hash取余全部数据重新洗牌。

在这里插入图片描述

缺点

一致性哈希算法的数据倾斜问题
翻倍伸缩，保证最小迁移数据和
- Hash环的数据倾斜问题一致性Hash算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）问题，例如系统中只有两台服务器：

在这里插入图片描述

哈希槽分区

$HASH_{SLOT} = CRC16(key) mod 16384$
哈希槽实质就是一个数组，数组$[0,2^{14} -1]$形成hash slot空间。虚拟哈希槽分区是Redis Cluster采用的分区方式预设虚拟槽，每个槽就相当于一个数字，有一定范围。每个槽映射一个数据子集，一般比节点数大
解决均匀分配的问题，在数据和节点之间又加入了一层，把这层称为哈希槽（slot），用于管理数据和节点之间的关系，现在就相当

于节点上放的是槽，槽里放的是数据。

在这里插入图片描述

**槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。**哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配
一个集群只能有16384个槽，编号0-16383$（0-2^{14}-1）$。这些槽会分配给集群中的所有主节点**，分配策略没有要求(系统分配)。**
集群会记录节点和槽的对应关系，解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取模，余数是几key就落入对应的槽里。HASH_SLOT = CRC16(key) mod 16384。以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。
当需要在 Redis 集群中放置一个 key-value时，redis先对key使用crc16算法算出一个结果然后用结果对16384求余数[ CRC16(key) % 16384]，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，也就是映射到某个节点上。如下代码，key之A 、B在Node2， key之C落在Node3上

分片是什么	使用Redis集群时我们会将存储的数据分散到多台redis机器上，这称为分片。简言之，集群中的每个Redis实例都被认为是整个数据的一个分片。
如何找到给定key的分片	为了找到给定key的分片，我们对key进行CRC16(key)算法处理并通过对总分片数量取模。然后，使用确定性哈希函数，这意味着给定的key将多次始终映射到同一个分片，我们可以推断将来读取特定key的位置。

注意：在使用数据分片时，没有用一致性hash，而是引入了hash槽

比如对于三个Redis节点，哈希槽的分配方式如下：

第一个节点拥有0-5500哈希槽

第二节点拥有5501-11000哈希槽

第三节点拥有剩余的11001-16384哈希槽

5.哈希槽分区答疑解惑

在现在的redis集群中，有能力的公司在cluster集群使用比较频繁。

如下图所示

那为什么分配16834$（2^{14}）$个slot呢？而不是使用$2^{16}$.和一致性hash环一样的数据量？

CRC16算法产生的hash值有16bit，该算法可以产生2^16-=65536个值。换句话说，值是分布在0~65535之间。那作者在做mod运算的时候，为什么不mod65536，而选择mod16384？

作者有解答：

作者原版回答如下: The reason is:

Normal heartbeat packets carry the full configuration of a node, that can be replaced in an idempotent way with the old in order to update an old config. This means they contain the slots configuration for a node, in raw form, that uses 2k of space with16k slots, but would use a prohibitive 8k of space using 65k slots.

At the same time it is unlikely that Redis Cluster would scale to more than 1000 mater nodes because of other design tradeoffs.

So 16k was in the right range to ensure enough slots per master with a max of 1000 maters, but a small enough number to propagate the slot configuration as a raw bitmap easily. Note that in small clusters the bitmap would be hard to compress because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.】

作者的回答：

(1)如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。如上所述，在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8]。当槽位为65536时，这块的大小是: 65536÷8÷1024=8kb 因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。 (2)redis的集群主节点数量基本不可能超过1000个。如上所述，集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者，不建议redis cluster节点数量超过1000个。那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。 (3)槽位越小，节点少的情况下，压缩比高 Redis主节点的配置信息中，它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中，会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。

ps：文件压缩率指的是，文件压缩前后的大小比。

综上所述，作者决定取16384个槽，不多不少，刚刚好！

总结就是：在服务器相互通信时，会定时发送信息。使用槽过多，反而将带宽都用在发送信息头上去了

细节：

在这里，我们需要关注三个重点。

(1)交换什么数据信息

(2)数据信息究竟多大

(3)定期的频率什么样

到底在交换什么数据信息？ 交换的数据信息，由消息体和消息头组成。消息体无外乎是一些节点标识啊，IP啊，端口号啊，发送时间啊

消息头，结构如下

注意看红框的内容，type表示消息类型。另外，消息头里面有个myslots的char数组，长度为16383/8，这其实是一个bitmap,每一个位代表一个槽，如果该位为1，表示这个槽是属于这个节点的。

到底数据信息究竟多大？ 在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8]。这块的大小是: 16384÷8÷1024=2kb 那在消息体中，会携带一定数量的其他节点信息用于交换。那这个其他节点的信息，到底是几个节点的信息呢？约为集群总节点数量的1/10，至少携带3个节点的信息。 **这里的重点是:**节点数量越多，消息体内容越大。

消息体大小是10个节点的状态信息约1kb。

那定期的频率是什么样的？ redis集群内节点，每秒都在发ping消息。规律如下

(1)每秒会随机选取5个节点，找出最久没有通信的节点发送ping消息

(2)每100毫秒(1秒10次)都会扫描本地节点列表，如果发现节点最近一次接受pong消息的时间大于cluster-node-timeout/2 则立刻发送ping消息

因此，每秒单节点发出ping消息数量为 数量=1+10*num（node.pong_received>cluster_node_timeout/2）

6.哈希槽配置：

实例：配置三主三从虚拟机。一共6台，但是实际使用3台每台2个服务器。

3台虚拟机配置：

==机器1==

name：Centos 7

端口号1：6379/6382(一台机器两个redis)

ip： 192.168.226.128

redis port：6379

requirepass ：123456

==机器2==

端口号2：6380/6383(一台机器两个redis)

name：Centos 7 192.168.226.130

ip：192.168.226.130

redis port：6380

requirepass ：123456

==机器3==

端口号3：6381/6384(一台机器两个redis)

name：Centos 7 192.168.226.131

ip：192.168.226.131

redis port：6381

requirepass ：123456

步骤1：设置每台虚拟机配置文件

1.准备三台虚拟机，各自新建文件目放配置文件

Bash

mkdir -p /myredis/cluster # 放在根目录下

2.新建6个独立的redis实例服务（一台虚拟机两个）因为多个太过于占内存了，也可以用6个服务器

第一台虚拟机IP: 192.168.226.128 + 端口 6379/6382
- 端口6379(记着将密码改成自己平常用的）

Bash

vim /myredis/cluster/redisCluster6379.conf

Bash

bind 0.0.0.0
daemonize yes
protected-mode no
port 6379
logfile "/myredis/cluster/cluster6379.log"
pidfile /myredis/cluster6379pid
dir /myredis/clusm ter
dbfilename dump6379.rdb
appendonly yes
appendfilename "appendonly6379.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 5000

端口 6382

Bash

vim /myredis/cluster/redisCluster6382.conf

Bash

bind 0.0.0.0
daemonize yes
protected-mode no
port 6382
logfile "/myredis/cluster/cluster6382.log"
pidfile /myredis/cluster6382.pid
dir /myredis/cluster
dbfilename dump6382.rdb
appendonly yes
appendfilename "appendonly6382.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6382.conf
cluster-node-timeout 5000

第二台虚拟机IP: 192.168.226.130 + 端口 6380 / 6383

Bash

mkdir -p /myredis/cluster # 放在根目录下

端口 6380

Bash

vim /myredis/cluster/redisCluster6380.conf

Bash

bind 0.0.0.0
daemonize yes
protected-mode no
port 6380
logfile "/myredis/cluster/cluster6380.log"
pidfile /myredis/cluster6380.pid
dir /myredis/cluster
dbfilename dump6380.rdb
appendonly yes
appendfilename "appendonly6380.aof"
requirepass 123456
masterauth 123456

cluster-enabled yes
cluster-config-file nodes-6380.conf
cluster-node-timeout 5000

端口 6383

Bash

vim /myredis/cluster/redisCluster6383.conf

Bash

bind 0.0.0.0
daemonize yes
protected-mode no
port 6383
logfile "/myredis/cluster/cluster6383.log"
pidfile /myredis/cluster6383.pid
dir /myredis/cluster
dbfilename dump6383.rdb
appendonly yes
appendfilename "appendonly6383.aof"
requirepass 123456
masterauth 123456

cluster-enabled yes
cluster-config-file nodes-6383.conf
cluster-node-timeout 5000

第三台虚拟机IP: 192.168.226.131 + 端口 6381/6384

Bash

mkdir -p /myredis/cluster # 放在根目录下

端口 6381

Bash

vim /myredis/cluster/redisCluster6381.conf

Bash

bind 0.0.0.0
daemonize yes
protected-mode no
port 6381
logfile "/myredis/cluster/cluster6381.log"
pidfile /myredis/cluster6381.pid
dir /myredis/cluster
dbfilename dump6381.rdb
appendonly yes
appendfilename "appendonly6381.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6381.conf
cluster-node-timeout 5000

端口 6384

Bash

vim /myredis/cluster/redisCluster6384.conf

Bash

bind 0.0.0.0
daemonize yes
protected-mode no
port 6384
logfile "/myredis/cluster/cluster6384.log"
pidfile /myredis/cluster6384.pid
dir /myredis/cluster
dbfilename dump6384.rdb
appendonly yes
appendfilename "appendonly6384.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6384.conf
cluster-node-timeout 5000

步骤2：开启虚拟机redis服务

Bash

# 机器1
redis-server /myredis/cluster/redisCluster6379.conf 
redis-server /myredis/cluster/redisCluster6382.conf 
# 机器2
redis-server /myredis/cluster/redisCluster6380.conf 
redis-server /myredis/cluster/redisCluster6383.conf 
# 机器3
redis-server /myredis/cluster/redisCluster6381.conf 
redis-server /myredis/cluster/redisCluster6384.conf

步骤3：通过redis-cli命令构建集群关系

构建主从关系注意用自己的IP

192.168.226.128 + 端口 6379/6382

192.168.226.130 + 端口 6380 / 6383

192.168.226.131 + 端口 6381/6384

Bash

redis-cli -a 123456 --cluster create --cluster-replicas 1 192.168.226.128:6379 192.168.226.128:6382 192.168.226.130:6380 192.168.226.130:6383 192.168.226.131:6381 192.168.226.131:6384

-cluster-replicas 1 表示为每个master创建一个slave节点

步骤4：任意连接一个作为切入点（集群只需要连一个），并检验集群状态

这里连6379端口

Bash

redis-cli -a 123456 -p 6379 -c     // -c表示集群 不加的话不是按照集群启动的，对于在别的机器上的key，会报错

查看节点状态

Bash

cluster nodes       // 查看集群的主从关系

查看集群信息

Bash

cluster info

查看主从

Bash

info replication

查看这个key的槽位值

Bash

cluster keyslot k2

7. 容错

7.1 master掉线

某个master掉线，对应下面的slave会上位，当原始的master上线时，也不会继续上位（和其他机制一样）

如果还是要让master上位呢？

强制上位命令

Bash

CLUSTER FAILOVER   // 让谁上位 就在谁的端口号下执行这个命令

7.2扩容

新建6387、6388 两个服务实例配置文件+启动 (又加了个虚拟机或者直接在三个虚拟机里选一个)

6387端口

Bash

bind 0.0.0.0
daemonize yes
protected-mode no
port 6387
logfile "/myredis/cluster/cluster6387.log"
pidfile /myredis/cluster6387.pid
dir /myredis/cluster
dbfilename dump6387.rdb
appendonly yes
appendfilename "appendonly6387.aof"
requirepass 123456
masterauth 123456

cluster-enabled yes
cluster-config-file nodes-6387.conf
cluster-node-timeout 5000

6388 端口

Bash

bind 0.0.0.0
daemonize yes
protected-mode no
port 6388
logfile "/myredis/cluster/cluster6388.log"
pidfile /myredis/cluster6388.pid
dir /myredis/cluster
dbfilename dump6388.rdb
appendonly yes
appendfilename "appendonly6388.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6388.conf
cluster-node-timeout 5000

启动，此时这两个实例都是master

Bash

redis-server /myredis/cluster/redisCluster6388.conf 
    
redis-server /myredis/cluster/redisCluster6387.conf

将新增的6387节点作为master加入原集群

Bash

redis-cli --cluster add-node <加入集群的ip>:<端口> <主节点IP>:<主节点端口>

例子：

Bash

redis-cli -a 123456  --cluster add-node 192.168.230.114:6387 192.168.238.111:6381

检查集群情况，6381

命令：redis-cli -a 123456 --cluster check ip:端口

Bash

redis-cli -a 123456 --cluster check 192.168.238.111:6381

分配槽号命令：

redis-cli -a 123456 --cluster reshard ip:端口

==注意分配机制==

之前分配的槽号不会重新分配，而是每个服务器匀一部分给新服务（均匀分配）

加入到已有的集群中：

redis-cli -a 123456 --cluster add-node <加入集群的ip>:<端口> <主节点IP>:<主节点端口>

设计规则：为主节点6387分配从节点6388 –cluster-master-id 后跟的是6387的id

Bash

redis-cli -a 123456 --cluster add-node 192.168.238.114:6388 192.168.238.114:6387 --cluster-slave --cluster-master-id b861764cbba16a1b21536a3182349748e56f24cc

7.3 缩容

下线命令：先获得6388的节点id，在集群中将6388删除

Bash

redis-cli -a 123456 --cluster del-node 192.168.238.114:6388  411144d66f28e876de5a6433689c8cbfab10686f

重新分配槽点：

Bash

redis-cli -a 123456 --cluster reshard <被分配的ip>:<被分配的port>

注意：重新分配将是全部分配

bug

1、初始使用端口创建了redis

例如初始使用port：6379端口建立了redis服务器（其他服务器同理）

导致在启动redis-server /myredis/cluster/redisCluster6379.conf 服务时，并不会取消原始redis.conf配置

结果为：启动了port:6379的redis.conf服务

显示：使用ps ef | grep redis,发现对应6379并没有使用到[cluster]服务

解决方法：

Bash

kill -9 进程号
# 再次启动
redis-server /myredis/cluster/redisCluster6379.conf

2、Could not connect to Redis No route to host

问题：在使用构建集群服务命令时，其他服务器无法访问

原因：防火墙阻碍的问题

解决方法：关闭防火墙或将其他服务器端口加入白名单

集群总线 每个Redis集群中的节点都需要打开两个TCP连接。一个连接用于正常的给Client提供服务，比如6379，还有一个额外的端口（通过在这个端口号上加10000）作为数据端口，例如：redis的端口为6379，那么另外一个需要开通的端口是：6379 + 10000，即需要开启 16379。16379端口用于集群总线，这是一个用二进制协议的点对点通信信道。这个集群总线（Cluster bus）用于节点的失败侦测、配置更新、故障转移授权，等等。

补充

在这里插入图片描述

4.Redis单线程和多线程

面试题：

redis到底是单线程还是多线程?

读写请求还是单线程，多IO线程只是用来处理网络请求。技术是IO多路复用非阻塞IO

Redis的工作线程是单线程的，但是整个Redis是多线程的

Redis6/7将网络数据读写、请求协议解析通过多个IO线程来处理，真正执行命令的线程仍然是主线程单独进行操作（单线程），一举两得，既解决网络IO问题（多个IO线程），有保证了线程安全且处理方式简单（单线程执行命令）

在这里插入图片描述

IO多路复用听说过吗?
redis为什么快?

IO多路复用+epoll函数使用，才是redis为什么这么快的直接原因，而不是仅仅单线程命令+redis安装在内存中。

概念：Redis单线程和多线程

详解：

在redis3.x，redis是单线程的。
版本4.x，严格意义来说也不是单线程，而是负责处理客户端请求的线程是单线程，但是开始加了点多线程的东西(异步删除)。
2020年5月版本的6.0.x后及2022年出的7.0版本后，告别了大家印象中的单线程，用一种全新的多线程来解决问题。

Redis工作原理：

Redis采用Reactor模式的网络模型，对于一个客户端请求，主线程负责一个完整的处理过程，如下图：

redis可以理解为一个内存缓冲区，读写是可以在内存中进行的，所以Client在对Redis读写时，自然是需要访问Redis服务器的。这就是IO操作。

补充：

Reactor 模式是一种并发模型，在这种模型中，**主线程（Reactor）**避免了由于等待一或多个并发事件（比如 I/O 操作）的完成而无法继续工作的阻塞。通过使用非阻塞 I/O 操作和事件通知，主线程在并发操作完成时得到通知。

一般来说，Reactor 模式的工作流程如下：

应用程序将需要监听的 I/O 事件（比如 socket 的可读、可写事件注册到 Reactor 中，并且关联对应的处理事件。
Reactor 不断地轮询这些事件，当某个事件到达的时候（比如 socket 中有数据可读），Reactor 将这个事件对应的处理事件唤醒，交由一个工作线程（或者称之为 EventHandler）去处理。

这里的轮询，是Redis利用IO多路复用，使用一个主线程来监听事件是否请求完成，是否可以执行。

反过来，没有IO多路复用，每个事件到达Redis内存中，会导致不停的new线程，导致内存增加。

3.工作线程处理完相应的事件后，通知 Reactor 继续监听这个事件。

这种模型非常适合于大并发，少逻辑的网络程序中，比如 Nginx 中就用到了这种设计模式。通过这种方式，一个线程可以处理很多连接的事件，而不需要为每个连接都创建一个线程，这样就可以避免线程切换的开销，并且可以更有效地使用系统资源。

但Redis的其他功能，比如持久化RDB、AOF、异步删除、集群同步数据等都是由额外的线程执行的，因此整个Redis可以看作是多线程的。

Redis单线程在哪？

Redis的“单线程”主要是指Redis的网络IO和键值对读写是由一个线程来完成的，Redis在处理客户端的请求时包括获取（socket读）、解析、执行、内容返回（socket写）等都由一个顺序串行的主线程处理（第一篇介绍过的那些原子的命令），这也是Redis对外提供键值存储服务的主要流程。

Redis为什么选择单线程？

准确的说，应该是Redis 4.0之前一直采用单线程

主要原因有：

使用单线程模型使Redis的开发和维护更简单
虽然使用的是单线程，但也可以并发处理多客户端的请求（IO多路复用和非阻塞IO）
对于Redis系统来说，主要的性能瓶颈是内存/网络带宽（所以在这设置了多线程），而非CPU

Redis线程的缺陷在哪？

硬件的发展
- CPU并不是Redis的瓶颈，通常Redis要不受内存限制要不受网络限制，但是随着计算机硬件的发展，多核CPU已经成为常态，为了更大限度的利用CPU
单线程的缺点
- Redis使用单线程也是有一定缺点的，比较典型的就是使用del指令删除大key数据时（比如包含了成千上万个元素的hash集合，关于大key的问题我们会在Redis系列的下一篇专门介绍，这里先简单举个例子），del指令就会造成主线程卡顿。
- 由于Redis3.x完全是单线程的，del指令删除时会等待⌛️很久才释放，如果再加上高并发场景(˶‾᷄ ⁻̫ ‾᷅˵)额。。这就是Redis3.x单线程时代最经典的故障，大key删除的头疼问题，于是Redis4.0就新增了多线程模块，也主要是为了解决这个问题。
- 此外例如**flushdb还有flushall在数据量达到一定程度时，也会造成卡顿，因此一开始Redis就是把某些时间复杂度高，**占主线程CPU时间片较高，造成主线程卡顿的操作使用多线程来处理（bio子线程），以减少主线程阻塞时间，从而减少那个诸如del操作导致性能和稳定性的问题。
对此Redis4.0引入惰性删除可以有效避免Redis主线程卡顿

命令：

link key
flushdb async
flushall async
把删除工作交给了后台的小弟（子线程）异步来删除数据了。

因为Redis是单个主线程处理，redis之父antirez一直强调"Lazy Redis is better Redis".

而lazy free的本质就是把某些cost(主要时间复制度，占用主线程cpu时间片)较高删除操作，从redis主线程剥离让BIO子线程来处理，极大地减少主线阻塞时间。从而减少删除导致性能和稳定性问题。

Redis的多线程在哪？

在Redis6/7中，非常受关注的第一个新特性就是多线程。
- 这是因为，Redis一直被大家熟知的就是它的单线程架构，虽然有些命令操作可以用后台线程或子进程执行（比如数据删除、快照生成、AOF重写）。但是，从网络IO处理到实际的读写命令处理，都是由单个线程完成的。
- 随着网络硬件的性能提升，Redis的性能瓶颈有时会出现在网络IO的处理上，也就是说，单个主线程处理网络请求的速度跟不上底层网络硬件的速度
  - 采用多个IO线程来处理网络请求，提高网络请求处理的并行度，Redis6/7就是采用的这种方法。
但是，Redis的多IO线程只是用来处理网络请求的，对于读写操作命令Redis仍然使用单线程来处理。这是因为，Redis处理请求时，网络处理经常是瓶颈，通过多个IO线程并行处理网络操作，可以提升实例的整体处理性能。而继续使用单线程执行命令操作，就不用为了保证Lua脚本、事务的原子性，额外开发多线程互斥加锁机制了(不管加锁操作处理)，这样一来，Redis线程模型实现就简单了
Redis 只是将 I/O 读写变成了多线程，而命令的执行依旧是由主线程串行执行的

主线程和IO线程协作完成请求处理的过程

四个阶段

阶段一：服务端和客户端建立Socket连接，并分配处理线程首先，主线程负责接收建立连接请求，当有客户端请求和实例建立Socket连接时，主线程会创建和客户端的连接，并把Socket放入全局等待队列中，紧接着，主线程通过轮询方法把Socket连接分配给IO线程。
阶设二：IO线程读取并解折请求 主线程一旦把Socket分配给IO线程，就会进入阻塞状态，等待IO线程完成客户端请求的读取和解析，因为有多个IO线程在并行处理，所以，这个过程很快就可以完成。
阶段三：主线程执行请求操作等到IO线程解析完请求，主线程还是会以单线程的方式执行这些命令操作。
阶设四：IO线程回写Socket和主线程清空全局队列当主线程执行完请求操作后，会把需要返回的结果写入缓冲区，然后，主线程会阻塞等待IO线程，把这些结果回写到Socket中，并返回给客户端。和IO线程读取和解析请求一样，IO线程回写Socket时，也是有多个线程在并发执行，所以回写Socket的速度也很快。等到IO线程回写Socket完毕，主线程会清空全局队列，等待客户端的后续请求。

详细过程：

原先redis3.x版本都是单线程，即**获取（socket读）、解析、执行、内容返回（socket写）**等都由一个顺序串行的主线程处理。如图：

现在redis4.x-之后，即主线程的IO读写任务拆分给一组独立的线程去执行,这样就可以使多个socket的读写可以并行化了，**采用多路IO复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络I0的时间消耗)，将最耗时的Socket的读取、请求解析、写入单独外包出去，**剩下的命令执行仍然由主线程串行执行并和内存的数据交互。如图：

IO多路复用

IO多路复用（IO multiplexing）是Unix网络编程的5种IO模型之一。

Unix网络编程的5种IO模型

Blocking IO 阻塞IO

就是单线程阻塞，有线程来了就上锁，执行完成才解锁。如果多个线程同时到达会导致等待

使用系统调用，并一直阻塞直到内核将数据准备好，之后再由内核缓冲区复制到用户态，在等待内核准备的这段时间什么也干不了
下图函数调用期间，一直被阻塞，直到数据准备好且从内核复制到用户程序才返回，这种IO模型为阻塞式IO
阻塞式IO式最流行的IO模型

在这里插入图片描述

NoneBlocking IO 非阻塞IO

时时准备接收线程，浪费cup

内核在没有准备好数据的时候会返回错误码，而调用程序不会休眠，而是不断轮询询问内核数据是否准备好
下图函数调用时，如果数据没有准备好，不像阻塞式IO那样一直被阻塞，而是返回一个错误码。数据准备好时，函数成功返回。
应用程序对这样一个非阻塞描述符循环调用成为轮询。
非阻塞式IO的轮询会耗费大量cpu，通常在专门提供某一功能的系统中才会使用。通过为套接字的描述符属性设置非阻塞式，可使用该功能

在这里插入图片描述

IO multiplexing IO 多路复用（下文会介绍）

signal driven IO 信号驱动IO

首先开启套接字的信号驱动式IO功能，并且通过sigaction(信号处理程序) 系统调用安装一个信号处理函数，该函数调用将立即返回，当前进程没有被阻塞，继续工作；当数据报准备好的时候，内核为该进程产生SIGIO 的信号，随后既可以在信号处理函数中调用recvfrom 读取数据报，并且通知主循环数据已经准备好等待处理；也可以直接通知主循环让它读取数据报；(其实就是一个待读取的通知和待处理的通知)，基本不会用到。

在这里插入图片描述

asynchronous IO 异步IO(AIO)

当代码需要执行一个耗时的IO操作时，他只发出IO指令，并不等待IO结果然后就去执行其他代码，一段时间后，当IO返回结果是，在通知CPU进行处理 我们调用aio_read函数，给内核传递描述符，缓冲区指针，缓冲区大小，和文件偏移量，并且告诉内核当整个操作完成时如何通知我们，该函数调用后，立即返回，不会被阻塞另一方面：从kernel的角度，当他收到一个aio_read之后，首先它立即返回，所以不会对用户进程产生block，然后kernel会等待数据准备完成，然后将数据拷贝到用户内存（copy由内核完成），当着一切完成后，kernel会给用户进程发送一个singal或者执行下一个基于线程回调函数来完成此次IO处理过程，告诉他read操作完成

在Linux中，一切皆文件，这就要提到“文件描述符”这个概念了

文件描述符（FileDescriptor, FD）

文件描述符是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。

文件描述符在形式上是一个非负整数，实际上它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向该进程返回一个文件描述符。

在程序设计中，文件描述符这一概念往往只适用于UNIX或者Linux这样的操作系统。

什么是IO多路复用

一种同步的IO模型，实现一个线程监视多个文件句柄，一旦某个文件句柄就绪，就能通知到对应程序进行相应的读写操作，没有文件句柄就绪时，就会阻塞应用程序，从而释放CPU资源。

我们来介绍几个概念：

I/O
- 网络I/O，尤其在操作系统层面指数据在内核态和用户态之间的读写操作
多路
- 多个客户端连接（连接就是套接字描述符，即socket或者channel）
复用
- 复用一个或者几个线程连接
IO多路复用
- 也就是说一个或者一组线程处理多个TCP，使用单进程就能实现同时处理多个客户端的连接，无需创建或者维护过多的进程/线程

总结

一个服务端进程可以同时处理多个套接字描述符
实现多路复用的模型有3种：可以分select->poll->epoll3个阶段来描述

我们根据模拟情景来简单概括下IO多路复用模型：

将用户Socket对应的文件描述符（FileDescriptor）注册进epoll，然后epoll帮你监听哪些Socket上有消息到达，这样就避免了大量的无用操作，此时的Socket应该采用非阻塞模式，这样整个过程只在调用select、poll、epoll这些函数是才会阻塞，收发客户消息是不会阻塞的，整个进程/线程就会被充分利用起来，这就是事件驱动，所谓的reactor反应模式。

在单个线程通过记录跟踪每一个Socket（I/O流）的状态来同时管理多个I/O流，一个服务端进程可以同时处理多个套接字描述符，以此来提高服务器的吞吐能力。

大家都用过nginx，nginx使用epoll接收请求，ngnix会有很多链接进来，epoll会把他们都监视起来，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。Redis类似同理，这就是IO多路复用原理，有请求就响应，没请求不打扰。

IO多路复用达到的效果就是只使用一个服务端进程可以同时处理多个套接字描述符连接。

客户端请求服务端时，实际就是在服务端的Socket文件中写入客户端对应的文件描述符（FileDescriptor），如果有多个客户端同时请求服务端，为每次请求分配一个线程，类似每次来就new一个太耗费服务端资源，因此，只使用一个线程来监听多个文件描述符，即IO多路复用。

采用IO多路复用技术可以让单个线程高效的处理多个连接请求，一个服务端进程可以同时处理多个套接字描述符。

从Rdis6开始，就新增了多线程的功能来提高I/O的读写性能，他的主要实现思路是将主线程的IO读写任务拆分给一组独立的线程去执行，这样就可以使多个Socket的读写可以并行化了，采用多路I/O复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗)，将最耗时的Socket的读取、请求解析、写入单独外包出去，剩下的命令执行仍然由主线程串行执行并和内存的数据交互。

Redis 7 默认设置是否开启了多线程？

如果你在实际应用中，发现Redis实例的CPU开销不大但吞吐量却没有提升，可以考虑使用Reds7的多线程机制（默认关闭，需手动开启），加速网络处理，进而提升实例的吞吐量。

Redis7将所有的数据放在内存中，内存的响应时长大约为100纳秒，对于小数据，Redis服务器可以处理8W到10W的QPS（实验室数据，极限），但是对于大部分的公司已经够用了，所以在Redis6.0以后，多线程机制默认是关闭的，如果需要使用，则要在redis.conf配置文件中修改，主要改两个地方：

设置io-threads-do-redis配置项为yes，表示启动多线程
设置线程个数，io-threads 个数，关于个数的设置，官方的建议是如果为4核的CPU，建议线程数设置为2或3，如果为8核CPU建议线程数设置为6（线程数一定要小于机器核数，并非越大越好）

在这里插入图片描述

5.BigKey

什么是BigKey

string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。超过即为bigke

bigkey是如何产生的

一般来说，bigkey是由于程序员的程序设计不当，或对数据规模预料不清楚造成的： 1、社交类：粉丝列表，如果某些明显或大V，一定是bigkey 2、统计类：如果按天存储某项功能或网站的用户集合，除非没几个人用，否则必定是bigkey 3、缓存类：作为数据库数据的冗余存储，这种是redis的最常用场景，但有2点要注意： 1）是不是有必要把所有数据都缓存 2）有没有相关关联的数据举个例子，该同学把某明星一个专辑下的所有视频信息都缓存成了一个巨大的json，这个json达到了6MB。

bigkey带来的问题

如果是集群模式下，无法做到负载均衡，导致请求倾斜到某个实例上，而这个实例的QPS会比较大，内存占用也较多；对于Redis单线程模型又容易出现CPU瓶颈，当内存出现瓶颈时，只能进行纵向库容，使用更牛逼的服务器。
涉及到大key的操作，尤其是使用hgetall、lrange 0 -1、get、hmget 等操作时，网卡可能会成为瓶颈，也会到导致堵塞其它操作，qps 就有可能出现突降或者突升的情况，趋势上看起来十分不平滑，严重时会导致应用程序连不上，实例或者集群在某些时间段内不可用的状态。
假如这个key需要进行删除操作，如果直接进行DEL 操作，被操作的实例会被Block住，导致无法响应应用的请求，而这个Block的时间会随着key的变大而变长。

怎么查看bigkey

既然查看bigkey会导致时间复杂度为O（n），使用什么命令查看bigkey避免阻塞

scan 命令代替 keys ，避免卡顿

Scan基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程，以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历，不保证每次执行都返回某个给定数量的元素，支持模糊查询，一次返回的数量不可控，只能是大概率符合count参数

语法：

Bash

SCAN cursor [MATCH pattern] [COUNT count]

MATCH pattern 为模糊匹配
COUNT count 为一次查询的数量，默认为10

结果：

两个数组，（1）游标结束位置（2）查询到的值。当返回游标值为0代表结束。

SCAN 命令代替keys的缺点：并不能完全代替keys命令，反而使得CPU飙升。要去设计底层数据结构

查看文档：https://blog.csdn.net/qq171563857/article/details/111150239

避免keys命令，如何禁用使用

keys * / flushall / flushdb 严禁在线上使用

keys * / flushall / flushdb 会造成阻塞，会导致Redis其他的读写都被延后甚至是超时报错，可能会引起缓存雪崩甚至数据库宕机

通过redis.conf配置禁用危险命令

配置文件中rename-command CONFIG “”(注意有空格)

在这里插入图片描述

查找bigKey的方法

在redis实例上执行bgsave，然后我们对dump出来的rdb文件进行分析，找到其中的大KEY
有个不太推荐的命令，debug object xxx 可以看到这个key在内存中序列化后的大小，当然我们可以通过SCAN+debug object xxx 得到当前实例所有key的大小。
redis-cli 原生自带 –bigkeys 功能，可以找到某个实例 5种数据类型(String、hash、list、set、zset)的最大key。

Bash

redis-cli --bigkeys -i 0.1

4.计算每个键值的字节数

Bash

MEMORY USAGE key [SAMPLES count]

key为键名称
samples 针对嵌套元素，默认count为5，查找所有count=0

如何删除bigkey避免风险

Redis直接删除大的集合键的耗时, 测试估算，可参考；和硬件环境、Redis版本和负载等因素有关

Key类型	Item数量	耗时
Hash	~100万	~1000ms
List	~100万	~1000ms
Set	~100万	~1000ms
Sorted Set	~100万	~1000ms

从Redis2.8版本开始支持SCAN命令，通过m次时间复杂度为O(1)的方式，遍历包含n个元素的大key.这样避免单个O(n)的大命令，导致Redis阻塞。这里删除大key操作的思想也是如此。(即bigkey渐进式的删除，一点点删除小的)

先给键改名（见后面小节）。

java客户端自定义删除

String

一般用del，过于庞大 unlink

Hash删除: hscan + hdel。使用hscan每次获取少量field-value，再使用hdel删除每个field

Java

public void delBigHash(String host, int port, String password, String bigHashKey){
    Jedis jedis = new Jedis(host, port);
    if(password != null &&!"".equals(password)){
        jedis.auth(password);
    }
	ScanParams scanParams =new ScanParams().count(100);String cursor ="”;
	do{
        // 每次获取少量值
        ScanResult<Entry<String,String>>scanResult = jedis.hscan(bigHashKey, cursor, scanParams);
       	List<Entry<String, String>>entrylist = scanResult.getResult();
        if(entryList != null && !entryList.isEmpty()){
            for(Entry<String,String>entry :entryList){
                // 一步步的删除
                iedis.hdel(bigHashKey, entry.getkey());
            }
        }
		cursor =scanResult.getStringCursor();
    }while(!"0".equals(cursor));
	//最后直接删除bigkey
	jedis.del(bigHashKey);
}

List删除：使用 ltrim 渐进式逐步删除，直到全部删除

命令：

在这里插入图片描述

在这里插入图片描述

set

使用sscan 每次获取部分元素，再使用 srem 命令删除每个元素
命令

在这里插入图片描述

在这里插入图片描述

zset

使用zscan每次获取部分元素，再使用ZREMRANGEBYRANK 命令删除每个元素
命令

在这里插入图片描述

在这里插入图片描述

redis后台删除

为了解决redis使用del命令删除大体积的key，或者使用flushdb、flushall删除数据库时，造成redis阻塞的情况，在redis 4.0引入了lazyfree机制，可将删除操作放在后台，让后台子线程(bio)执行，避免主线程阻塞。

lazy free的使用分为2类：第一类是与DEL命令对应的主动删除，第二类是过期key删除、maxmemory key驱逐淘汰删除

主动删除

UNLINK命令:

是与DEL一样删除key功能的lazy free实现。唯一不同时，UNLINK在删除集合类键时，如果集合键的元素个数大于64个(详细后文），会把真正的内存释放操作，给单独的bio来操作。

Bash

127.0.0.1:7000> UNLINK mylist
(integer) 1
FLUSHALL/FLUSHDB ASYNC
127.0.0.1:7000> flushall async //异步清理实例数据

注意：DEL命令，还是阻塞的删除操作。

FLUSHALL/FLUSHDB ASYNC

通过对FLUSHALL/FLUSHDB添加ASYNC异步清理选项，redis在清理整个实例或DB时，操作都是异步的。

Bash

127.0.0.1:7000> DBSIZE
(integer) 1812295
127.0.0.1:7000> flushall //同步清理实例数据，180万个key耗时1020毫秒
OK
(1.02s)
127.0.0.1:7000> DBSIZE
(integer) 1812637
127.0.0.1:7000> flushall async //异步清理实例数据，180万个key耗时约9毫秒
OK
127.0.0.1:7000> SLOWLOG get
 1) 1) (integer) 2996109
 2) (integer) 1505465989
 3) (integer) 9274 //指令运行耗时9.2毫秒
 4) 1) "flushall" 
 2) "async"
 5) "127.0.0.1:20110"
 6) ""

过期(被动)删除

lazy free应用于被动删除中，目前有4种场景，每种场景对应一个配置参数；默认都是关闭。

Bash

lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
slave-lazy-flush no
lazyfree-lazy-user-del no # 如果设置为yes，那么del命令就等价于unlink，也是非阻塞删除。

lazyfree-lazy-eviction

针对redis内存使用达到maxmeory，并设置有淘汰策略时；在被动淘汰键时，是否采用lazy free机制；

因为此场景开启lazy free, 可能使用淘汰键的内存释放不及时，导致redis内存超用，超过maxmemory的限制。此场景使用时，请结合业务测试。

lazyfree-lazy-expire

针对设置有TTL的键，达到过期后，被redis清理删除时是否采用lazy free机制；

此场景建议开启，因TTL本身是自适应调整的速度。

lazyfree-lazy-server-del

针对有些指令在处理已存在的键时，会带有一个隐式的DEL键的操作。如rename命令，当目标键已存在,redis会先删除目标键，如果这些目标键是一个big key,那就会引入阻塞删除的性能问题。此参数设置就是解决这类问题，建议可开启。

slave-lazy-flush

针对slave进行全量数据同步，slave在加载master的RDB文件前，会运行flushall来清理自己的数据场景，

参数设置决定是否采用异常flush机制。如果内存变动不大**，建议可开启**。可减少全量同步耗时，从而减少主库因输出缓冲区爆涨引起的内存使用增长。

expire及evict优化

redis在空闲时会进入activeExpireCycle循环删除过期key，每次循环都会率先计算一个执行时间，在循环中并不会遍历整个数据库，而是随机挑选一部分key查看是否到期，所以有时时间不会被耗尽（采取异步删除时更会加快清理过期key），剩余的时间就可以交给freeMemoryIfNeeded来执行。

参考文章：https://blog.csdn.net/ldw201510803006/article/details/126093439

键值设计

key名设计

可读性和可管理性(建议)

以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:id

Bash

set trade:order:1//业务名:表名:id

简洁性(建议)

保证语义的情况下,减低key长度,key过长也占用内存空间

Css

user:{uid}:friends:messages:{mid} 简化为 u:{uid}:fr:m:{mid}

不要包含特殊字符(强制)

反例：包含空格、换行、单双引号以及其他转义字符

value设计

拒绝bigkey

在Redis中，一个字符串最大512MB，一个二级数据结构（例如hash、list、set、zset）可以存储大约40亿个(2^32-1)个元素，但实际中如果下面两种情况，我就会认为它是bigkey。

1.字符串类型：

它的big体现在单个value值很大，一般认为超过10KB就是bigkey。

2.非字符串类型:(hash,list,set,zset等)

哈希、列表、集合、有序集合，它们的big体现在元素个数太多。一般来说hash、list、set、zset元素个数不要超过5000。反例：一个包含200万个元素的list。

3.bigkey的删除

非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，如果没有使用Redis 4.0的过期异步删除(lazyfree-lazy-expire yes)，就会存在阻塞Redis的可能性）

优化bigkey

1.一个字拆,大拆小

hash结构比如一个big hash中有100万的数据可以通过key的名称做定义将100万的数据进行拆分成200个key,每个key中存放5000个数据 list结构也是同样操作,一个list的key存放5000个集合,拆开来存

2.避开危险操作

如果必须使用bigkey的话,那操作的时候避开hgetall、lrange、smembers、zrange、sinter等全数据查询的命令,有遍历的需求可以使用hscan、sscan、zscan代替(例如有时候仅仅需要hmget，而不是hgetall)，删除也是一样，尽量使用优雅的方式来处理。

3.合理使用数据类型(推荐)

例如：实体类型(要合理控制和使用数据结构，但也要注意节省内存和性能之间的平衡) 正例:

Sql

hmset user:1 name tom age 19 favor football

反例:

Sql

set user:1:name tom
set user:1:age 19
set user:1:favor football

4.控制key的生命周期，redis不是垃圾桶(推荐)

建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)。

命令使用

1.O(N)命令关注N的数量

例如hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替。

2.禁用命令

禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁掉命令，或者使用scan的方式渐进式处理。

3.合理使用select

redis自带的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰。

4.使用批量操作提高效率

Undefined

原生命令：例如mget、mset。
非原生命令：可以使用pipeline提高效率。

但要注意控制一次批量操作的元素个数(例如500以内，实际也和元素字节数有关)。注意两者不同：

Undefined

原生命令是原子操作，pipeline是非原子操作。
pipeline可以打包不同的命令，原生命令做不到
pipeline需要客户端和服务端同时支持。

5.Redis事务功能较弱，不建议过多使用，可以用lua替代

6.Redis中的缓存双写一致性

在这里插入图片描述

在实际的环境中，Client端先查询redis端的数据，如果没有最后再查mysql

6.1、缓存双写一致性

机制介绍：

如果redis中有数据
- 需要和mysql数据库中的值相同
如果redis中无数据
- mysql数据库中的值是最新值，且准备回写redis
缓存按照操作分
- 只读缓存
- 读写缓存：同步和异步
  - 同步直写策略
    - 写数据库后也同步写 redis 缓存，缓存中的数据和数据中的一致
    - 对于读写缓存来说，要想保证缓存和数据库中的数据一致
  - 异步缓写策略
    - 正常业务运行中，mysql数据变动了，但是可以在业务上容许出现一定时间后才作用于redis，比如仓库、物流系统
    - 异常情况出现了，不得不讲失败的动作重新修补，有可能需要借助kafka或者RabbitMQ等消息中间件，实现重写重试

如下图所示，如何用java逻辑写出下面code

在这里插入图片描述

采用双检加锁策略

多个线程同时去查询数据库的这条数据，就在第一个查询数据的请求上使用一个互斥锁来锁住他。
其他线程获取不到锁就一直等待，等第一个线程查询到了数据，然后做了缓存
后面的线程进来发现已经有了缓存，就直接走缓存

本质就是1.查数据2.线程加锁3.查数据

缺点：加锁后，后续查询操作会阻塞

Java

package com.lv.service.impl;

import com.baomidou.mybatisplus.extension.service.impl.ServiceImpl;
import com.lv.User;
import com.lv.mapper.UserMapper;
import com.lv.service.UserService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;

import javax.annotation.Resource;
import java.util.concurrent.TimeUnit;

/**
 * @author 晓风残月Lx
 * @date 2023/3/27 12:39
 */
@Slf4j
@Service
public class UserServiceImpl extends ServiceImpl<UserMapper, User> implements UserService {

    public static final String CACHE_KEY_USER = "user:";
    @Resource
    private UserMapper userMapper;
    @Resource
    private RedisTemplate redisTemplate;


    /**
     *  业务逻辑没有写错，对于小厂中厂(QPS《=1000)可以使用，但是大厂不行
     * @param id
     * @return
     */
    public User findUserById1(Long id){
        User user = null;

        String key = CACHE_KEY_USER + id;

        // 1.先从redis中查询，如果有直接返回结果，没有再去查询 mysql
        user = (User) redisTemplate.opsForValue().get(key);

        if (user == null){
            // 2. redis中没有,查询mysql
             user = userMapper.selectById(id);
             if (user == null){
                 // 3.1 redis + mysql 都无数据
                 // 具体细化，防止多次穿透，业务规定，记录下导致穿透的这个key回写redis
                 return user;
             }else {
                 // 3.2 mysql有，需要回写到redis，保证下一次的缓存命中率
                 redisTemplate.opsForValue().set(key,user);
             }
        }
        return user;
    }

    /**
     * 加强补充，避免突然key失效了，打爆mysql，做一下预防，尽量不出现击穿的情况
     * @param id
     * @return
     */
    public User findUserById2(Long id){
        User user = null;
        String key = CACHE_KEY_USER + id;

        // 1.先从redis里面查询，如果有直接返回结果，如果没有再去查询mysql
        // 第一次查询redis，加锁前
        user = (User) redisTemplate.opsForValue().get(key);
        if (user == null){
            // 2.对于高QPS的优化，进来就先加锁，保证一个请求操作，让外面的redis等待一下，避免击穿mysql
            synchronized (UserServiceImpl.class){
                // 第二次查询redis，加锁后
                user = (User) redisTemplate.opsForValue().get(key);
                // 3. 二次查redis还是null，可以去查mysql了(mysql默认有数据)
                if (user == null) {
                    //4 查询mysql拿数据(mysql默认有数据)
                    user = userMapper.selectById(id);
                    if (user == null) {
                        return null;
                    } else {
                        // 5. mysql里面有数据的，需要回写redis，完成数据一致性的同步工作
                        redisTemplate.opsForValue().setIfAbsent(key, user, 7L, TimeUnit.DAYS);
                    }
                }
            }
        }
        return user;
    }
}

6.2 数据库和缓存一致性的几种更新策略

目的

达到最终一致性
- 给缓存设置过期时间，定期清理缓存并回写，是保证最终一致性的解决方案。
- 我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存，达到一致性，切记，要以mysql的数据库写入库为准。

两种情况：可停机，不可停机。其中不可停机又分成4种：1、先更新databbase，再更新缓存2、先更新缓存，再更新database 3、先删除缓存，再更新数据库 4、先更新数据库，再删除缓存

注意：上述都有一定的问题，但是现有公司一般以database为最终一致性，其中方案4为大多数的最佳方案。

可停机的情况

基本上怎么处理都可以

挂牌报错
凌晨升级
服务降级
温馨提示
最好单线程操作（对于重量级的数据操作）

不可停机的情况,四种更新策略（推荐最后一种，看场景）

1.先更新数据库，在更新缓存

异常问题1：当redis更新失败，会导致redis数据是脏数据
异常问题2：多并发情况下，导致线程数据不一致，使用一致性的操作，反而违反了多并发的特性

2.先更新缓存，再更新数据库

不建议使用该·方案：一般业务会将mysq作为底单数据库，有最终解释权
异常问题：多并发问题，但是会导致database数据不一致（问题很大）

3.先删除缓存，再更新数据库

异常问题总结：
- 多并发下，database没有更新完成，这时线程B读取缓存会导致读取旧值。
- 线程B读取旧值后，线程A将database更新好了，线程B又会写回缓存，导致整个过程失败了

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

解决方案**（延时双删策略）**
手动休眠读取数写的时间，（这个时间怎么确定？要自己测试或使用工具）

注意：关键点，我更新完数据库的时间 + sleep的时间大于读取数据并写入换的时间即可（多个100ms即可）

在这里插入图片描述

关于延时双删的细节问题
- 这个线程休眠时间（线程A sleep的时间，就需要大于线程B读取数据再写入缓存的时间）
  - **第一种：**在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，自行评估自己的项目的读数据业务逻辑的耗时，以此为基础来进行估算。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上加百毫秒即可。
  - 第二种： 新启动一个后台监控程序，比如WatchDog监控程序，会加时
- 这种同步淘汰策略，吞吐量降低怎么办
  - 第二次删除缓存使用异步删除

在这里插入图片描述

4.先更新数据库，再删除缓存

优点：比方案3可以保证database中的一致性
异常问题：

在这里插入图片描述

订阅binlog程序再mysql中有现成的中间件叫canal，可以完成订阅binlog日志的功能（下一章具体实现）
解决方法

在这里插入图片描述

分布式的事务问题一定要遵守最终一致性，可以允许短暂的信息滞后

6.3、总结

先删除缓存值再更新数据库
- 有可能导致请求因缓存缺失而访问数据库，给数据库带来压力导致打满mysql 如果业务应用中读取数据库和写缓存的时间不好估算，那么，延迟双删中的等待时间就不好设置
先更新数据库，再删除缓存
- 如果业务层要求必须读取一致性的数据，那么我们就需要在更新数据库时，先在Redis缓存客户端暂停并发读请求，等数据库更新完、缓存值删除后，再读取数据，从而保证数据一致性，这是理论可以达到的效果，但实际，不推荐，因为真实生产环境中，分布式下很难做到实时一致性，一般都是最终一致性。

7. 如何监听mysql数据

Canal介绍

是什么

官网地址：https://github.com/alibaba/canal/wiki

canal [ka'nael]，中文翻译为水道/管道/沟渠/运河，主要用途是于MySQL数据库增量日志数据的订阅、消费和解析，是阿里巴巴开发并开源的，采用Java语言开发;

历史背景是早期阿里巴巴因为杭州和美国双机房部署，存在跨机房数据同步的业务需求，实现方式主要是基于业务trigger (触发器)获取增量变更。从2010年开始，阿里巴巴逐步尝试采用解析数据库日志获取增量变更进行同步，由此衍生出了canal项目;

能干嘛

基于日志增量订阅和消费的业务包括

数据库镜像
数据库实时备份
索引构建和实时维护(拆分异构索引、倒排索引等)
业务 cache 刷新
带业务逻辑的增量数据处理

去哪下

下载地址：https://github.com/alibaba/canal/releases/tag/canal-1.1.6

工作原理，面试回答

根据传统mysql主从复制原理，进行改进

传统的MySQL主从复制工作原理

MySQL的主从复制将经过如下步骤:

1、当master主服务器上的数据发生改变时，则将其改变写入二进制事件日志文件中（二进制偏移量）；

2、salve 从服务器会在一定时间间隔内对master主服务器上的二进制日志进行探测，探测其是否发生过改变；如果探测到master主服务器的二进制事件日志发生了改变,则开始一个I/O Thread请求master二进制事件日志（是否已经改变的日志）；

3、同时master主服务器为每个I/0 Thread启动一个dump Thread, 用于向其发送二进制事件日志；

4、slave 从服务器将接收到的二进制事件日志保存至自己本地的中继日志文件中；

5、salve 从服务器将启动SQL Thread从中继日志中读取二进制日志，在本地重放，使得其数据和主服务器保持一致；

6、后I/O Thread和SQL Thread将进入睡眠状态，等待下一次被唤醒。

canal工作原理

工作原理

canal 模拟MySQL slave的交互协议，伪装自己为MySQL slave，向MySQL master发送dump协议
MySQL master收到dump请求，开始推送binary log给slave (即canal )canal 解析binary log对象(原始为byte流)

双写一致性-MySQL（在先更新数据库，再删除缓存的基础上）

Java案例，来源出处

https://github.com/alibaba/canal/wiki/ClientExample

查看MySQL版本

select version(); // 5.7.17
当前的主机二进制日志

show master status;
查看 show variables like 'log_bin';默认未开启，修改为on

开启MySQL的binlog写入功能

修改配置文件，win环境下修改my.ini文件（在mysql安装目录下。记得备份my.ini文件）

Ini

log-bin=mysql-bin
binlog-format=Row
server_id=1

重启MySQL
再次查看 show variables like 'log_bin';

授权canal链接MySQL账号
- MySQL默认的用户在MySQL库的user表里面

默认没有canal账户，此处新建+授权

Mysql

DROP USER IF EXISTS 'canal'@'%' ;
CREATE USER 'canal'@'%' IDENTIFIED BY 'canal' ;
GRANT ALL PRIVILEGES ON *.* TO 'canal'@'%' IDENTIFIED BY 'canal' ;
FLUSH PRIVILEGES;
SELECT * FROM mysql .user;

canal服务端

下载

官网地址：https://github.com/alibaba/canal/releases/tag/canal-1.1.6

解压

在根目录下创建文件mkdir /mycanal

进入该文件夹cd /mycanal

解压 tar -zxvf canal.deployer-1.1.6.tar.gz

解压后整体放入到/mycanal路径下

配置

修改 /mycanal/conf/example路径下instance.properties文件

换成自己的MySQL主机master的IP地址

换成自己的在MySQL新建的canal账户（可以使用默认密码）

启动

必须要有 java 8 的环境

在/mycanal/bin路径下执行 -> ./startup.sh

查看

判断canal是否启动成功

查看server日志

查看样例 example的日志

双写一致性 coding-canal客户端(Java编写业务程序)

Redis用RedisTemplate

SQL脚本

选中一个库，执行下面建表语句

Mysql

CREATE TABLE `t_user`(
`id` bigint(20)NOT NULL AUTO_INCREMENT,
`userName` varchar(100)NOT NULL,
PRIMARY KEY (`id`)
)ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8mb4

建module

canal_demo

改POM

Xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.5.14</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>com.luojia</groupId>
    <artifactId>canaldemo</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>canaldemo</name>
    <description>Demo project for Spring Boot</description>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <junit.version>4.12</junit.version>
        <log4j.version>1.2.17</log4j.version>
        <lombok.version>1.16.18</lombok.version>
        <mysql.version>5.1.47</mysql.version>
        <druid.version>1.1.16</druid.version>
        <mapper.version>4.1.5</mapper.version>
        <mybatis.spring.boot.version>1.3.0</mybatis.spring.boot.version>
    </properties>

    <dependencies>
        <!-- canal -->
        <dependency>
            <groupId>com.alibaba.otter</groupId>
            <artifactId>canal.client</artifactId>
            <version>1.1.0</version>
        </dependency>
        <!--SpringBoot 通用依赖模块-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-pool2</artifactId>
        </dependency>
        <!-- springboot 与 AOP -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-aop</artifactId>
        </dependency>
        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjweaver</artifactId>
        </dependency>
        <!-- Mysql 数据库驱动 -->
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>${mysql.version}</version>
        </dependency>
        <!-- springboot集成druid连接池-->
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>druid-spring-boot-starter</artifactId>
            <version>1.1.10</version>
        </dependency>
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>druid</artifactId>
            <version>${druid.version}</version>
        </dependency>
        <!-- mybatis和SpringBoot整合 -->
        <dependency>
            <groupId>org.mybatis.spring.boot</groupId>
            <artifactId>mybatis-spring-boot-starter</artifactId>
            <version>${mybatis.spring.boot.version}</version>
        </dependency>
        <!-- persistence -->
        <dependency>
            <groupId>javax.persistence</groupId>
            <artifactId>persistence-api</artifactId>
            <version>1.0.2</version>
        </dependency>
        <!-- 通过Mapper -->
        <dependency>
            <groupId>tk.mybatis</groupId>
            <artifactId>mapper</artifactId>
            <version>${mapper.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-autoconfigure</artifactId>
        </dependency>
        <!-- jedis -->
        <dependency>
            <groupId>redis.clients</groupId>
            <artifactId>jedis</artifactId>
            <version>3.8.0</version>
        </dependency>
<!--        &lt;!&ndash; lettuce &ndash;&gt;-->
<!--        <dependency>-->
<!--            <groupId>io.lettuce</groupId>-->
<!--            <artifactId>lettuce-core</artifactId>-->
<!--            <version>6.2.1.RELEASE</version>-->
<!--        </dependency>-->

        <!-- SpringBoot 与Redis整合依赖 -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-pool2</artifactId>
        </dependency>
        <!-- swagger2 -->
        <dependency>
            <groupId>io.springfox</groupId>
            <artifactId>springfox-swagger2</artifactId>
            <version>2.9.2</version>
        </dependency>
        <dependency>
            <groupId>io.springfox</groupId>
            <artifactId>springfox-swagger-ui</artifactId>
            <version>2.9.2</version>
        </dependency>

        <!-- 通用基础配置 -->
        <dependency>
            <groupId>cn.hutool</groupId>
            <artifactId>hutool-all</artifactId>
            <version>5.2.3</version>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>${junit.version}</version>
        </dependency>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>${log4j.version}</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>1.7.26</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>1.7.26</version>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>${lombok.version}</version>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <excludes>
                        <exclude>
                            <groupId>org.projectlombok</groupId>
                            <artifactId>lombok</artifactId>
                        </exclude>
                    </excludes>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

写YML

Yml

server.port=8000

# ====================== alibaba.druid ======================
spring.datasource.type=com.alibaba.druid.pool.DruidDataSource
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/jmall?useUnicode=true&characterEncoding=utf-8&useSSL=true&serverTimezone=UTC
spring.datasource.username=root
spring.datasource.password=root
spring.datasource.druid.test-while-idle=fasle

启动类

这个是一个模板不用启动

Java

package com.xfcy.canal_demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class CanalDemoApplication {

	public static void main(String[] args) {
		//SpringApplication.run(CanalDemoApplication.class, args);
	}

}

业务类

RedisUtils(java连接redis操作，使用的是Jedis)

Java

package com.luojia.canaldemo.utils;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

public class RedisUtils {

    public static final String REDIS_IP_ADDR = "127.0.0.1";

    public static final String REDIS_PWD = "123456";

    public static JedisPool jedisPool;

    static {
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        jedisPoolConfig.setMaxTotal(20);
        jedisPoolConfig.setMaxIdle(10);
        jedisPool = new JedisPool(jedisPoolConfig, REDIS_IP_ADDR, 6379, 10000, REDIS_PWD);
    }

    public static Jedis getJedis() throws Exception {
        if (null != jedisPool) {
            return jedisPool.getResource();
        }
        throw new Exception("Jedispoll is not ok");
    }
}

RedisCanalClientExample（Canal监听code）

Java

package com.luojia.canaldemo.biz;


import com.alibaba.fastjson.JSONObject;
import com.alibaba.otter.canal.client.CanalConnector;
import com.alibaba.otter.canal.client.CanalConnectors;
import com.alibaba.otter.canal.common.utils.AddressUtils;
import com.alibaba.otter.canal.protocol.CanalEntry.*;
import com.alibaba.otter.canal.protocol.Message;
import com.luojia.canaldemo.utils.RedisUtils;
import io.lettuce.core.RedisClient;
import redis.clients.jedis.Jedis;

import java.net.InetSocketAddress;
import java.util.List;
import java.util.UUID;

public class RedisCanalClientExample {

    public static final Integer _60SECONDS = 60;
    //
    public static final String REDIS_IP_ADDR = "127.0.0.1";
	// 插入监听
    public static void redisInsert(List<Column> columns) {

        JSONObject jsonObject = new JSONObject();
        for (Column column : columns) {
            System.out.println(column.getName() + ": " + column.getValue() + " insert = " + column.getUpdated());
            jsonObject.put(column.getName(), column.getValue());
        }
		// 
        if (columns.size() > 0) {
            try (Jedis jedis = RedisUtils.getJedis()) {
                jedis.set(columns.get(0).getValue(), jsonObject.toJSONString());
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
	//删除监听
    public static void redisDelete(List<Column> columns) {
        JSONObject jsonObject = new JSONObject();
        for (Column column : columns) {
            System.out.println(column.getName() + ": " + column.getValue() + " delete = " + column.getUpdated());
            jsonObject.put(column.getName(), column.getValue());
        }

        if (columns.size() > 0) {
            try (Jedis jedis = RedisUtils.getJedis()) {
                jedis.del(columns.get(0).getValue());
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
	// 更新监听
    public static void redisUpdate(List<Column> columns) {

        JSONObject jsonObject = new JSONObject();
        for (Column column : columns) {
            System.out.println(column.getName() + ": " + column.getValue() + " update = " + column.getUpdated());
            jsonObject.put(column.getName(), column.getValue());
        }

        if (columns.size() > 0) {
            try (Jedis jedis = RedisUtils.getJedis()) {
                jedis.set(columns.get(0).getValue(), jsonObject.toJSONString());
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
	// 打印操作
    public static void printEntry(List<Entry> entrys) {
        for (Entry entry : entrys) {
            if (entry.getEntryType() == EntryType.TRANSACTIONBEGIN || entry.getEntryType() == EntryType.TRANSACTIONEND) {
                continue;
            }

            RowChange rowChage = null;
            try {
                rowChage = RowChange.parseFrom(entry.getStoreValue());
            } catch (Exception e) {
                throw new RuntimeException("ERROR ## parser of eromanga-event has an error , data:" + entry.toString(), e);
            } 

            EventType eventType = rowChage.getEventType();
            System.out.println(String.format("================&gt; binlog[%s:%s] , name[%s,%s] , eventType : %s",
                    entry.getHeader().getLogfileName(), entry.getHeader().getLogfileOffset(),
                    entry.getHeader().getSchemaName(), entry.getHeader().getTableName(),
                    eventType));

            for (RowData rowData : rowChage.getRowDatasList()) {
                if (eventType == EventType.DELETE) {
                    redisDelete(rowData.getBeforeColumnsList());
                } else if (eventType == EventType.INSERT) {
                    redisInsert(rowData.getAfterColumnsList());
                } else {
                    System.out.println("-------&gt; before");
                    redisUpdate(rowData.getBeforeColumnsList());
                    System.out.println("-------&gt; after");
                }
            }
        }
    }
	// 启动程序
    public static void main(String[] args) {
        // 创建链接
        CanalConnector connector = CanalConnectors.newSingleConnector(new InetSocketAddress(AddressUtils.getHostIp(),
                11111), "example", "", "");
        int batchSize = 1000;
        int emptyCount = 0;
        try {
            connector.connect();
            // 监听当前库的所有表，这个部分是需要特别关注的。不可能所有表都监听的
            // connector.subscribe(".*\\..*");
            connector.subscribe("jmall.t_user");
            connector.rollback();
            int totalEmptyCount = 10 * _60SECONDS;
            while (emptyCount < totalEmptyCount) {
                System.out.println("我是canal，每秒监听一次：" + UUID.randomUUID().toString());
                Message message = connector.getWithoutAck(batchSize); // 获取指定数量的数据
                long batchId = message.getId();
                int size = message.getEntries().size();
                if (batchId == -1 || size == 0) {
                    // MySQL数据没有变动
                    emptyCount++;
                    System.out.println("empty count : " + emptyCount);
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                    }
                } else {
                    emptyCount = 0;
                    // System.out.printf("message[batchId=%s,size=%s] \n", batchId, size);
                    printEntry(message.getEntries());
                }

                connector.ack(batchId); // 提交确认
                // connector.rollback(batchId); // 处理失败, 回滚数据
            }

            System.out.println("empty too many times, exit");
        } finally {
            connector.disconnect();
        }
    }
}

题外话

java程序下 connector.subscribe配置的过滤正则

关闭资源代码简写

try-with-resource释放资源（语法糖）

在这里插入图片描述

8.bitmap、hyperloglog、GEO实践

面试题：

抖音电商直播，主播介绍的商品有评论，1个商品对应了一系列的评论，排序+展现+取前10条记录
用户在手机APP上的签到打卡信息：1天对应一系列用户的签到记录，新浪微博、钉钉打卡签到，来没来如何统计
应用网站上的网页访问信息：一个网页对应一系列的访问点击，淘宝网首页，每天有多少人浏览首页
公司系统上线后，说一下UV、PV、DAU分别是多少？

记录对集合中的数据进行统计

在移动应用中，需要统计每天的新增用户数和第2天的留存用户数；

在电商网站的商品评论中，需要统计评论列表中的最新评论；

在签到打卡中，需要统计一个月内连续打卡的用户数；

在网页访问记录中，需要统计独立访客（Unique Visitor. uV）量。

痛点：

类似今日头条、抖音、淘宝这样的额用户访问级别都是亿级的，请问如何处理?

需求痛点

亿级数据的收集+清洗+统计+展现

一句话：存的进+去得快+多维度展现

真正有价值的是统计

统计的类型

亿级系统中，常见的四种统计

聚合统计
- 统计多个集合元素的聚合结果，就是前面讲解过的交差并等集合统计
- 复习命令

排序统计

抖音短视频最新评论留言的场景，请你设计一个展现列表。（考察数据结构和设计思路）

设计案例和回答思路：

以抖音vcr最新的留言评价为案例，所有评论需要两个功能，按照时间排序(正序、反序)+分页显示能够排序+分页显示的redis数据结构是什么合适?

zset

在面对需要展示最新列表、排行榜等场景时，如果数据更新频繁或者需要分页显示，建议使用ZSet

二值统计

集合元素的取值就只有0和1两种。在钉钉上签到打卡的场景中，我们只用记录有签到(1)或没有签单(0)

见bitmap

基数统计

指统计一个集合中不重复的元素个数

见HyperLogLog

HyperLogLog

名称解释：

什么是UV

Unique Visitor，独立访客，一般理解为客户端IP

需要去重考虑
什么是PV

Page View，页面浏览量

不用去重
什么是DAU

Daily Active User，日活跃量用户，登录或者使用了某个产品的用户数（去重复登录的用户）

常用于反映网站、互联网应用或者网络游戏的运营情况
什么是MAU

Monthly Active User，月活跃用户量

需求设计

很多计数类场景，比如每日注册 IP 数、每日访问 IP 数、页面实时访问数 PV、访问用户数 UV等。

因为主要的目标高效、巨量地进行计数，所以对存储的数据的内容并不太关心。

也就是说它只能用于统计巨量数量，不太涉及具体的统计对象的内容和精准性。

统计单日一个页面的访问量(PV)，单次访问就算一次。

统计单日一个页面的用户访问量(UV)，即按照用户为维度计算，单个用户一天内多次访问也只算一次。

多个key的合并统计，某个门户网站的所有模块的PV聚合统计就是整个网站的总PV。

hyperloglog复习

基数
- 是一种数据集，去重复后的真实个数
- 在Redis里面，每个HyperLogLog键只需要花费12KB内存，就可以计算接近2的64次方个不同元素的基数

命令：

pdadd key element .... 将所有元素添加到key中

pfcount key 统计key 的估计值（不精确有0.81%的误差）

pgmerge new_key key1 key2 ... 合并key至新key

案例：

在这里插入图片描述

误差怎么来的？

这个误差率如何来的？

http://antirez.com/news/75

Redis之父安特雷兹回答：

统计亿级UV的Redis方案

对比几种去重的方案

去重复统计功能

hashSet
bitmap
- bitmap是通过用位bit数组来表示各元素是否出现，每个元素对应一位，所需的总内存为N个bit。
- 新进入的元素只需要将已经有的bit数组和新加入的元素进行按位或计算就行。这个方式能大大减少内存占用且位操作迅速。
- 如果数据较大，比如一个样本案例就是一亿个基数拉值数据，一个样本就是一亿，如果要统计一亿个数据的基数拉值，大约需要内存 1100000000/8/1024/1024 约等于 12M，内存减少占用的效果显著。这样得到统计一个对象样本的基数值需要12M。
- 如果统计10000个对象样本(1w个亿级),就需要117.1875G将近120G，可见使用bitmaps还是不适用大数据量下(亿级)的基数计数场景，
- 但是bitmap是精确计算的
结论
- 量变会引起质变
办法
- 概率算法
  - 通过牺牲准确率来换取空间，对于不要求绝对准确率的场景下可以使用，因为概率算法不直接存储数据本身，通过牺牲准确率来换取空间，对于不要求绝对准确率的场景下可以使用，因为概率算法不直接存储数据本身
  - HyperLogLog就是一种概率算法的实现。
原理说明
- 只是进行不重复的基数统计，不是集合也不保存数据，只记录数量而不是具体内容
- 缺点是有误差
  - hyperloglog提供不精确的去重技术方案
  - 牺牲准确率来换取空间，误差仅仅只是 0.81% 左右

对比之下选择

用mysql
- mysql扛不住稍微大一点的并发，而且都需要存入mysql中，导致mysql的检索也会变慢
用redis的hash结构存储
- 按照ipv4的结构来说明，一个ip最多15个字节（ip=“192.168.238.1xx”），某一天 1.5亿*15个字节 = 2G，一个月60G，内存直接没了，加内存条都没用
hyperloglog
- 在Redis里面，每个HyperLogLog键只需要花费12KB内存，就可以计算接近2的64次方个不同元素的基数

在这里插入图片描述

编码(yml和pom与上次一致)

HyperLogLogController

Java

import com.xfcy.service.HypeLogLogService;
import io.swagger.annotations.Api;
import io.swagger.annotations.ApiOperation;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

import javax.annotation.Resource;

/**
 * @author 晓风残月Lx
 * @date 2023/3/27 20:17
 */
@Api(tags = "淘宝亿级UV的Redis统计方案")
@Slf4j
@RestController
public class HyperLogLogController {

    @Resource
    private HypeLogLogService hypeLogLogService;


    @ApiOperation("获得IP去重复后的UV统计访问量")
    @RequestMapping(value = "/uv",method = RequestMethod.GET)
    public long uv(){
        return hypeLogLogService.uv();
    }
}

HyperLogLogServiceImpl

Java

import com.xfcy.service.HypeLogLogService;


import lombok.extern.slf4j.Slf4j;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import java.util.Random;
import java.util.concurrent.TimeUnit;

/**
 * @author 晓风残月Lx
 * @date 2023/3/27 20:18
 */
@Slf4j
@Service
public class HypeLogLogServiceImpl implements HypeLogLogService {

    @Resource
    private RedisTemplate redisTemplate;

    /**
     * 模拟后台有用户点击网站首页，每个用户来自不同的IP地址
     *
     * @PostConstruct修饰的方法会在服务器加载Servlet的时候运行，并且只会被服务器执行一次。
     */
    @PostConstruct
    public void initIp() {
        new Thread(() -> {
            String ip = null;
            for (int i = 0; i < 200; i++) {
                Random random = new Random();
                ip = random.nextInt(256) + "." + random.nextInt(256) + "." + random.nextInt(256) + "." + random.nextInt(256);

                Long hll = redisTemplate.opsForHyperLogLog().add("hll", ip);

                log.info("ip = {}, 该IP地址访问首页的次数={}",ip,hll);

                try {
                    // 暂停3秒钟
                    TimeUnit.SECONDS.sleep(3);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
        }, "t1").start();
    }

    public long uv() {
        // PFCOUNT
        return redisTemplate.opsForHyperLogLog().size("hll");
    }
}

HypeLogLogService

Java


public interface HypeLogLogService {

    public long uv();
}xxxxxxxxxx10 1/**2 * @author 晓风残月Lx3 * @date 2023/3/27 20:184 */5public interface HypeLogLogService {67    public long uv();8}910/**

启动项目后测试

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

GEO实践

ps：如果想要获取经纬度的话，可以去百度地图拾取坐标系统 (baidu.com)

附近的人、附近的美食店铺怎么实现的

用mysql
- 查询性能问题，并发高、数据量大这种查询要搞垮mysql数据库
- 一般mysql查询的是一个平面矩形访问，而叫车服务要以我为中心N公里为半径的圆形覆盖
- 精准度的问题，我们知道地球不是平面坐标系，而是一个圆球，这种矩形计算在长距离计算时会有很大误差，mysql不合适
用GEO
- 可以解决上述问题

命令复习：

会出现中文乱码

redis -cli -a 123456 – raw

在登录时需要使用-raw修改为中文编码
GEOADD 添加经纬度坐标

GEOPOS返回经纬度

GEOHASH返回坐标的geohash表示

geohash算法生成的base32编码值，3维变2维变1维

GEODIST两个位置之间的距离

GEORADIUS

以半径为中心，查找附近的XXX

GEORADIUSBYMEMBE

具体实现：

需求分析

推送当前位置，指定范围内的酒店信息

http://www.redis.cn/commands/geoadd.html

编码实现

关键点：GEORADIUS，以给定的经纬度为中心，找出某一半径内的元素

Java

public string geoAdd() {
    Map<String，point> map = new HashMap<>();
    map.put("天安门", new Point( x: 116.403963, y: 39.915119));
    map.put("故宫", new point( x: 116.403414, y: 39.924091));
    map.put("长城", new Point( x: 116.024067, y: 40.362639));
    redisTemplate.opsForGeo().add(CITY,map);
    return map.tostring();
}

public Point position(string member){
    // 获取经纬度坐标,这里的member可以有多个，返回的list也可以有多个
    list<Point> list = redisTemplate.opsForGeo().position(CITY, member);
    return list.get(0);
}

public string hash(string member) {
    //geohash算法生成的base32编码值,这里的member可以有多个，返回的list也可以有多个
    List<string> list = redisTemplate.opsForGeo().hash(CITY,member);
    return list.get(o);
}

public Distance distance( string member1，string member2) {
    //获取两个给定位置之间的距离
    Distance distance = redisTemplate.opsForGeo().distance(CITY,member1,member2,RedisGeoCommands.DistanceUnit.KILOMETERS);
    return distance;
}

public GeoResults radiusByxy() {
    //通过经度，纬度查找附近的，北京王府井位置116.418017, 39.914402
    Circle circle = new Circle(116. 418017, 39 .914402, Metrics . KILOMETERS . getMultiplier());
    //返@50条:
    RedisGeoCommands.GeoRadiusCommandArgs args =
RedisGeoCommands.GeoRadiusCommandArgs.newGeoRadiusArgs().includeDistance().includeCoordinates().sortAscending().limit(50);
    GeoResults<RedisGeoCommands.GeoLocation<String>> geoResults=
this.redisTemplate.opsForGeo().radius(CITY, circle, args);
    return geoResults;
}

public GeoResults radiusByMember() {
    //通过地方查找附近
    String member="天安门";
    //返回50条
    RedisGeoCommands.GeoRadiusCommandArgs args = RedisGeoCommands.GeoRadiusCommandArgs.newGeoRadiusArgs().includeDistance().includeCoordinates( ).sortAscending().limit(5e) ;
    //半径10公里内
    Distance distance=new Distance(10，Metrics.KILOMETERS);
    GeoResults<RedisbeoCommands.GeoLocation<String>> geoResults= this.redisTemplate.opsForbeol().radius(CITY,member,distance,angs);
    return geoResults;
}

bitmap

大厂真实案例

日活统计

连续签到打卡

最近一周的活跃用户

统计指定用户一年之中的登录天数

某用户按照一年365天，哪几天登陆过，哪几天没有登录？

是什么

由0和1状态表现的二进制位的bit数组

能干嘛

用于状态统计，Y、N类似AtomicBoolean

看需求：

用户是否登录过Y、N，比如京东每日签到送京豆
电影、广告是否被点击播放过
钉钉打卡上下班，签到统计

京东签到领取京豆

需求说明

TEXT

签到日历仅展示当月签到数据
签到日历需展示最近连续签到天数
假设当前日期是20210618，且20210616未签到

若20210617已签到且0618未签到，则连续签到天数为1

若20210617已签到且0618已签到，则连续签到天数为2

连续签到天数越多，奖励越大
所有用户均可签到
截至2020年3月31日的12个月，京东年度活跃用户数3.87亿，同比增长24.8%，环比增长超2500万，此外，2020年3月移动端日均活跃用户数同比增长46%假设10%左右的用户参与签到，签到用户也高达3千万。。。

小厂方法，传统MySQL方式
- 建表语句
Mysql
```
CREATE TABLE user_sign
keyid BIGINT NOT NULL PRIMARY KEY AUTO INCREMENT,
user_key VARCHAR(200), #京东用户ID
sign_date DATETIME,#签到日期(20220618)
sign_count INT #连续签到天数

INSERT INTO user_sign(user_key,sign_date,sign_count)
VALUES ('28216618-XXXX-XXXX-XXXX-XXXXXXXXXXXX','2022-06-18 15:11:12',1);
        
SELECT
	sign_count
FROM
	user_sign
WHERE 
	user_key =20216618-XXXX-XXXX-XXXX-XXXXXXXXXXXX 
	AND sign date BETWEEN '2020-06-17 00:00:00' AND '2020-06-18 23:59:59'
ORDER BY
	sign_date DESC
	LIMIT 1;
```
- 困难和解决思路
  
  方法正确但是难以落地实现。 签到用户量较小时这么设计能行，但京东这个体量的用户(估算3000W签到用户，一天一条数据，一个月就是9亿数据)对于京东这样的体量，如果一条签到记录对应着当日签到记录，那会很恐怖......
  
  如何解决这个痛点?
  1. 一条签到记录对应一条记录，会占据越来越大的空间。
  2. 一个月最多31天，刚好我们的int类型是32位，那这样一个int类型就可以搞定一个月，32位大于31天，当天来了就是1没来就是0。
  3. 一条数据直接存储一个月的签到记录，不再是存储一天的签到记录。
大厂方法，基于Redis的Bitmap实现签到日历

建表-按位-redis-bitmap

在签到统计时，每个用户一天的签到用1个bit位就能表示

一个月(假设是31天)的签到情况用31个bit位就可以，一年的签到也只需要用365个bit位，根本不用太复杂的集合类型

命令复习

Bash

SETBIT key offset value    // 将第offset的值设为value  value只能是0或1  offset 从0开始
GETBIT key offset        // 获得第offset位的值
STRLEN key              // 得出占多少字节 超过8位后自己按照8位一组一byte再扩容
BITCOUNT key         // 得出该key里面含有几个1
BITOP and destKey key1 key2 // 对一个或多个 key 求逻辑并，并将结果保存到 destkey 
BITOP or destKey key1 key2 // 对一个或多个 key 求逻辑或，并将结果保存到 destkey 
BITOP XOR destKey key1 key2 // 对一个或多个 key 求逻辑异或，并将结果保存到 destkey 
BITOP NOT destKey key1 key2 // 对一个或多个 key 求逻辑非，并将结果保存到 destkey

9.布隆过滤器

面试总结

现有50亿个电话号码，给你10万个电话号码，如何要快速准确的判断这些电话号码是否已经存在？

判断是否存在，布隆过滤器了解过吗？

安全连接网址，全球数10亿的网址判断

黑名单校验，识别垃圾邮件

白名单校验，识别出合法用户进行后续处理

布隆过滤器基本介绍

是什么

由一个初值都为零的bit数组和多个无偏哈希函数构成，用来快速判断集合中是否存在某个元素

多个无偏hash函数： 无偏hash函数就是能把元素的hash值计算的比较均匀的hash函数，能使得计算后的元素下标比较均匀的映射到位数组中。

如下就是一个简单的布隆过滤器示意图，其中k1、k2代表增加的元素，a、b、c即为无偏hash函数，最下层则为二进制数组。

布隆过滤器.png

空间计算 在布隆过滤器增加元素之前，首先需要初始化布隆过滤器的空间，也就是上面说的二进制数组，除此之外还需要计算无偏hash函数的个数。布隆过滤器提供了两个参数，分别是预计加入元素的大小n，运行的错误率f。布隆过滤器中有算法根据这两个参数会计算出二进制数组的大小l，以及无偏hash函数的个数k。它们之间的关系比较简单：

错误率越低，位数组越长，控件占用较大
错误率越低，无偏hash函数越多，计算耗时较长

增加元素 往布隆过滤器增加元素，添加的key需要根据k个无偏hash函数计算得到多个hash值，然后对数组长度进行取模得到数组下标的位置，然后将对应数组下标的位置的值置为1

通过k个无偏hash函数计算得到k个hash值依次取模数组长度，得到数组索引将计算得到的数组索引下标位置数据修改为1 例如，key = Liziba，无偏hash函数的个数k=3，分别为hash1、hash2、hash3。三个hash函数计算后得到三个数组下标值，并将其值修改为1. 如图所示：

增加元素.png

查询元素 布隆过滤器最大的用处就在于判断某样东西一定不存在或者可能存在，而这个就是查询元素的结果。其查询元素的过程如下：

通过k个无偏hash函数计算得到k个hash值
依次取模数组长度，得到数组索引
判断索引处的值是否全部为1，如果全部为1则存在（这种存在可能是误判），如果存在一个0则必定不存在

**关于误判，**其实非常好理解，hash函数在怎么好，也无法完全避免hash冲突，也就是说可能会存在多个元素计算的hash值是相同的，那么它们取模数组长度后的到的数组索引也是相同的，这就是误判的原因。例如李子捌和李子柒的hash值取模后得到的数组索引都是1，但其实这里只有李子捌，如果此时判断李子柒在不在这里，误判就出现啦！因此布隆过滤器最大的缺点误判只要知道其判断元素是否存在的原理就很容易明白了！

删除元素

布隆过滤器对元素的删除不太支持，目前有一些变形的特定布隆过滤器支持元素的删除！关于为什么对删除不太支持，其实也非常好理解，hash冲突必然存在，删除肯定是很苦难的！

优缺点：

布隆过滤器的优点：

时间复杂度低，增加和查询元素的时间复杂为O(N)，（N为哈希函数的个数，通常情况比较小）
保密性强，布隆过滤器不存储元素本身
存储空间小，如果允许存在一定的误判，布隆过滤器是非常节省空间的（相比其他数据结构如Set集合）

布隆过滤器的缺点：

有点一定的误判率，但是可以通过调整参数来降低
无法获取元素本身
很难删除元素

设计思想 ->

目的：减少内存占用；方式：不保存数据信息，只是在内存中做一个是否存在的标记flag

布隆过滤器的使用

有3种使用方案：

Redis集成布隆过滤器

java本地内存使用谷歌guava包实现

java集成Redis使用布隆过滤器（Jedis）

Redis集成布隆过滤器

Redis版本要求

推荐版本6.x，最低4.x版本，可以通过如下命令查看版本：

redis-server -v

插件名称：rebloom

下载插件压缩包

Bash

wget https://github.com/RedisLabsModules/rebloom/archive/v2.2.6.tar.gz

解压

Bash

tar -zxvf v2.2.6.tar.gz

编译插件

Bash

cd RedisBloom-2.2.6/
make

编译成功后看到redisbloom.so文件即可

使用集成类工具：

Redis配置文件修改

在redis.conf配置文件中加入如RedisBloom的redisbloom.so文件的地址
如果是集群则每个配置文件中都需要加入redisbloom.so文件的地址
添加完成后需要重启redis

Bash

loadmodule /usr/local/soft/RedisBloom-2.2.6/redisbloom.so

redis.conf配置文件中预置了loadmodule的配置项，我们可以直接在这里修改，后续修改会更加

保存退出后一定要记得重启Redis！保存退出后一定要记得重启Redis！保存退出后一定要记得重启Redis！

测试是否成功

Redis集成布隆过滤器的主要指令如下：

bf.add 添加一个元素
bf.exists 判断一个元素是否存在
bf.madd 添加多个元素
bf.mexists 判断多个元素是否存在

连接客户端进行测试，如果指令有效则证明集成成功

如果出现如下情况(error) ERR unknown command ，可以通过如下方法检查：

SHUTDOWN Redis实例，再重启实例，再次测试
检查配置文件是否配置redisbloom.so文件地址正确
检查Redis的版本是否过低

Redis中布隆过滤器指令使用

bf.add

bf.add表示添加单个元素，添加成功返回1

Bash

127.0.0.1:6379> bf.add name liziba
(integer) 1

bf.madd

bf.madd表示添加多个元素

Bash

127.0.0.1:6379> bf.madd name liziqi lizijiu lizishi
1) (integer) 1
2) (integer) 1
3) (integer) 1

bf.exists

bf.exists表示判断元素是否存在，存在则返回1，不存在返回0

Cobol

127.0.0.1:6379> bf.mexists name liziba
1) (integer) 1

bf.mexists

bf.mexists表示判断多个元素是否存在，存在的返回1，不存在的返回0

Cobol

127.0.0.1:6379> bf.mexists name liziqi lizijiu liziliu
1) (integer) 1
2) (integer) 1
3) (integer) 0

Java本地内存使用布隆过滤器

使用布隆过滤器的方式有很多，还有很多大佬自己手写的，我这里使用的是谷歌guava包中实现的布隆过滤器，这种方式的布隆过滤器是在本地内存中实现。

引入pom依赖

Xml

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>29.0-jre</version>
</dependency>

编写测试代码

Java

package com.lizba.bf;
 
import com.google.common.hash.BloomFilter;
import com.google.common.hash.Funnels;
 
/**
 * <p>
 *        布隆过滤器测试代码
 * </p>
 *
 * @Author: Liziba
 * @Date: 2021/8/29 14:51
 */
public class BloomFilterTest {
 
    /** 预计插入的数据 */
    private static Integer expectedInsertions = 10000000;
    /** 误判率 */
    private static Double fpp = 0.01;
    /** 布隆过滤器 */
    private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), expectedInsertions, fpp);
 
    public static void main(String[] args) {
        // 插入 1千万数据
        for (int i = 0; i < expectedInsertions; i++) {
            bloomFilter.put(i);
        }
 
        // 用1千万数据测试误判率
        int count = 0;
        for (int i = expectedInsertions; i < expectedInsertions *2; i++) {
            if (bloomFilter.mightContain(i)) {
                count++;
            }
        }
        System.out.println("一共误判了：" + count);
 
    }
 
}

测试结果

误判了100075次，大概是expectedInsertions（1千万）的0.01，这与我们设置的 fpp = 0.01非常接近。

参数说明

在guava包中的BloomFilter源码中，构造一个BloomFilter对象有四个参数：

Funnel funnel：数据类型，由Funnels类指定即可
long expectedInsertions：预期插入的值的数量
fpp：错误率
BloomFilter.Strategy：hash算法

fpp&expectedInsertions

当expectedInsertions=10000000&&fpp=0.01时，位数组的大小numBits=95850583，hash函数的个数numHashFunctions=7

当expectedInsertions=10000000&&fpp=0.03时，位数组的大小numBits=72984408，hash函数的个数numHashFunctions=5

当expectedInsertions=100000&&fpp=0.03时，位数组的大小numBits=729844，hash函数的个数numHashFunctions=5

综上三次测试可以得出如下结论：

当预计插入的值的数量不变时，偏差值fpp越小，位数组越大，hash函数的个数越多
当偏差值不变时，预计插入的中的数量越大，位数组越大，hash函数并没有变化（注意这个结论只是在guava实现的布隆过滤器中的算法符合，并不是说所有的算法都是这个结论，我做了多次测试，确实numHashFunctions在fpp相同时，是不变的！）

Java集成Redis使用布隆过滤器

Redis经常会被问道缓存击穿问题，比较优秀的解决办法是使用布隆过滤器，也有使用空对象解决的，但是最好的办法肯定是布隆过滤器，我们可以通过布隆过滤器来判断元素是否存在，避免缓存和数据库都不存在的数据进行查询访问！在如下的代码中只要通过bloomFilter.contains(xxx)即可，我这里演示的还是误判率！

引入pom依赖

Cobol

<dependency>
  <groupId>org.redisson</groupId>
  <artifactId>redisson-spring-boot-starter</artifactId>
  <version>3.16.0</version>
</dependency>

编写测试代码

Java

package com.lizba.bf;
 
import org.redisson.Redisson;
import org.redisson.api.RBloomFilter;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
 
/**
 * <p>
 *      Java集成Redis使用布隆过滤器防止缓存穿透方案
 * </p>
 *
 * @Author: Liziba
 * @Date: 2021/8/29 16:13
 */
public class RedisBloomFilterTest {
 
    /** 预计插入的数据 */
    private static Integer expectedInsertions = 10000;
    /** 误判率 */
    private static Double fpp = 0.01;
 
    public static void main(String[] args) {
        // Redis连接配置，无密码
        Config config = new Config();
        config.useSingleServer().setAddress("redis://192.168.211.108:6379");
        // config.useSingleServer().setPassword("123456");
 
        // 初始化布隆过滤器
        RedissonClient client = Redisson.create(config);
        RBloomFilter<Object> bloomFilter = client.getBloomFilter("user");
        bloomFilter.tryInit(expectedInsertions, fpp);
 
        // 布隆过滤器增加元素
        for (Integer i = 0; i < expectedInsertions; i++) {
            bloomFilter.add(i);
        }
 
        // 统计元素
        int count = 0;
        for (int i = expectedInsertions; i < expectedInsertions*2; i++) {
            if (bloomFilter.contains(i)) {
                count++;
            }
        }
        System.out.println("误判次数" + count);
 
    }
 
}

测试结果

其他过滤器

布隆过滤器缺点：比如不支持删除操作、查询效率弱，因为多个随机哈希函数探测的是bit数组中多个不同的点，所以会导致低CPU缓存命中率。

布谷鸟过滤器：

布谷鸟过滤器用更低的空间开销解决了布隆过滤器不能删除元素的问题，做到了更好的效果，具体的为：

支持动态的添加和删除元素

提供了比传统布隆过滤器更高的查找性能，即使在接近满的情况下（比如空间利用率达到 95% 的时候）

比起商过滤器它更容易实现

如果要求误判率低于3%，它比布隆过滤器有更低的空间开销

参考文章：https://www.cnblogs.com/zhaodongge/p/15067657.html

10.缓存预热 + 缓存雪崩 + 缓存击穿 + 缓存穿透

面试总结：

缓存预热、雪崩、穿透、击穿分别是什么？遇到过哪几种情况？
缓存预热是怎么做的？
如何避免或者减少缓存雪崩？
穿透和击穿有什么区别？他俩是一个意思还是截然不同？
穿透和击穿你有什么解决方案？如何避免？
加入出现了缓存不一致，你有哪些修补方案？

参考文章：https://blog.csdn.net/weixin_43290370/article/details/145531885

https://blog.csdn.net/fcvtb/article/details/89478554

缓存预热

是什么

缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

解决方法：

将热点数据提前加载到redis缓存中，可以通过@PostConstruct提前运行某个程序，将其加载到redis中

缓存雪崩

是什么

缓存雪崩就是瞬间过期数据量太大，导致对数据库服务器造成压力

发生

Redis主机挂了，Redis全盘崩溃，偏硬件运维
Redis中有大量key同时过期大面积失效，偏软件开发

预防 + 解决

Redis中key设置为永不过期或者过期时间为指定时间+随机时间，错开同时过期的概率
Redis缓存集群实现高可用

主从+哨兵

Redis Cluster

开启Redis持久化机制AOF/RDB，尽快恢复缓存集群
多缓存结合预防雪崩

ehcache本地缓存 + Redis缓存
服务降级

Hystrix或者阿里sentinel限流&降级
人民币玩家

阿里云-云数据库Redis版：https://www.aliyun.com/product/kvstore?spm=5176.54432.J_3207526240.15.2a3818a5iG191E

缓存穿透

是什么

请求去查询一条记录，先查redis无，后查mysql无，都查询不到该条记录但是请求每次都会打到数据库上面去，导致后台数据库压力暴增，这种现象我们称为缓存穿透，这个redis变成了一个摆设。

简单说就是本来无一物，两库都没有，既不在Redis缓存库，也不在mysql，数据库存在被多次暴击风险

解决

缓存穿透 -> 恶意攻击 -> 可以空对象缓存或者使用布隆过滤器

方案1：空对象缓存或者缺省值

一般情况都是OK的

第一种解决方案，回写增强如果发生了缓存穿透，我们可以针对要查询的数据，在Redis里存一个和业务部门商量后确定的缺省值(比如,零、负数、defaultNull等) 比如，键uid;abcdxxx，值defaultNull作为案例的key和value 先去redis查键uid:abcdxxx没有，再去mysql查没有获得，这就发生了一次穿透现象。 but，可以增强回写机制 mysql也查不到的话也让redis存入刚刚查不到的key并保护mysql。第一次来查询uid:abcdxxx，redis和mysql都没有，返回nul给调用者，但是增强回写后第二次来查uid:abcdxxx，此时redis就有值了。可以直接从Redis中读取default缺省值返回给业务应用程序，避免了把大量请求发送给mysql处理，打爆mysql。

但是，此方法架不住黑客的恶意攻击，有缺陷......，只能解决key相同的情况

Java

    public Customer findCustomerById(Integer customerId) {
        Customer customer = null;
        // 缓存redis的key名称
        String key = CACHE_KEY_CUSTOMER + customerId;
        // 1.去redis上查询
        customer = (Customer) redisTemplate.opsForValue().get(key);

        // 2. 如果redis有，直接返回  如果redis没有，在mysql上查询
        if (customer == null) {
            // 3.对于高QPS的优化，进来就先加锁，保证一个请求操作，让外面的redis等待一下，避免击穿mysql（大公司的操作 ）
            synchronized (CustomerService.class) {
                // 3.1 第二次查询redis，加锁后
                customer = (Customer) redisTemplate.opsForValue().get(key);
                // 4.再去查询我们的mysql
                customer = customerMapper.selectByPrimaryKey(customerId);

                // 5.mysql有，redis无
                if (customer != null) {
                    // 6.把mysql查询到的数据会写到到redis， 保持双写一致性  7天过期
                    redisTemplate.opsForValue().set(key, customer, 7L, TimeUnit.DAYS);
                }else {
                    // defaultNull 规定为redis查询为空、MySQL查询也没有，缓存一个defaultNull标识为空，以防缓存穿透
                    redisTemplate.opsForValue().set(key, "defaultNull", 7L, TimeUnit.DAYS);
                }
            }
        }
        return customer;
    }

但是会有黑客或者恶意攻击

黑客会对你的系统进行攻击，拿一个不存在的id去查询数据，会产生大量的请求到数据库去查询。可能会导致你的数据库由于压力过大而宕掉
key相同打你系统

第一次打到mysql，空对象缓存后第二次就返回defaultNull缺省值，避免mysql被攻击，不用再到数据库中去走一圈了
key不同打你系统

由于存在空对象缓存和缓存回写(看自己业务不限死)，redis中的无关紧要的key也会越写越多(记得设置redis过期时间)

方案2：Google布隆过滤器Guava解决缓存穿透

Guava中布隆过滤器的实现算是比较权威的，所以实际项目中我们可以直接使用Guava布隆过滤器

Guava's BloomFilter 源码出处：https://github.com/google/guava/blob/master/guava/src/com/google/common/hash/BloomFilter.java

案例：白名单过滤器

白名单架构说明

误判问题，但是概率小可以接受，不能从布隆过滤器删除
全部合法的key都需要放入Guava版布隆过滤器+redis里面，不然数据就是返回null

代码编写

建model -> 还是使用redis7-study

改pom

Xml

<!--guava Google 开源的 Guava 中带的布隆过德器-->
<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>23.0</version>
</dependency>

业务类

GUavaBloomFilterController

Java

import com.xfcy.service.GuavaBloomFilterService;
import io.swagger.annotations.Api;
import io.swagger.annotations.ApiOperation;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

import javax.annotation.Resource;

/**
 * @author 晓风残月Lx
 * @date 2023/3/29 19:06
 * guava版的布隆过滤器  谷歌开源
 */
@Api(tags = "gogle工具Guava处理布隆过滤器")
@RestController
@Slf4j
public class GuavaBloomFilterController {

    @Resource
    private GuavaBloomFilterService guavaBloomFilterService;

    @ApiOperation("guava布隆过滤器插入100万样本数据，额外10w（110w）测试是否存在")
    @RequestMapping(value = "/guavafilter", method = RequestMethod.GET)
    public void guavaBloomFilter() {
        guavaBloomFilterService.guavaBloomFilter();
    }
}

GUavaBloomFilterService

Java

import com.google.common.hash.BloomFilter;
import com.google.common.hash.Funnels;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;

import java.util.ArrayList;

/**
 * @author 晓风残月Lx
 * @date 2023/3/29 19:17
 */
@Slf4j
@Service
public class GuavaBloomFilterService {
    // 1.定义一个常量
    public static final int _1W = 10000;
    // 2.定义我们guava布隆过滤器，初始容量
    public static final int SIZE = 100 * _1W;
    // 3.误判率，它越小误判的个数也越少（思考：是否可以无限小？ 没有误判岂不是更好）
    public static double fpp = 0.01;  // 这个数越小所用的hash函数越多，bitmap占用的位越多  默认的就是0.03，5个hash函数   0.01，7个函数
    // 4.创建guava布隆过滤器
    private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), SIZE, fpp);

    public void guavaBloomFilter() {
        // 1.先让bloomFilter加入100w白名单数据
        for (int i = 0; i < SIZE; i++) {
            bloomFilter.put(i);
        }
        // 2.故意取10w个不在合法范围内的数据，来进行误判率的演示
        ArrayList<Integer> list = new ArrayList<>(10 * _1W);

        // 3.验证
        for (int i = SIZE + 1; i < SIZE + (10 * _1W); i++){
            if (bloomFilter.mightContain(i)){
                log.info("被误判了:{}", i);
                list.add(i);
            }
        }
        log.info("误判总数量：{}", list.size());
    }
}

运行结论：

TEXT

现在总共有10万数据是不存在的，误判了3033次，
原始样本:100W
不存在数据:1000001---1100000
3033 / 100000 = 0.03033,和我们的误判率对得上

debug源码看看

布隆过滤器说明

缓存击穿

是什么

大量请求同时查询一个key时，此时这个key正好失效了，就会导致大量的请求都打到数据库，简单点就是热点key突然失效了，暴打MySQL

缓存穿透和缓存击穿是完全不同的东西

危害

会造成某一时刻数据库请求量过大，压力剧增；一般技术部门需要知道热点key是哪些，做到心里有数防止击穿。

解决

缓存击穿 -> 热点key失效-> 今天互斥更新、随机退避、差异失效时间

热点key失效：时间到了自然清除但还是被访问到，delete掉的key，刚好又被访问到

方案一：差异失效时间，对于访问频繁的热点key，干脆就不设置过期时间

方案二：互斥更新，采用双检加锁策略

多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住它。其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。后面的线程进来发现已经有缓存了，就直接走缓存

案例

对于分页显示数据，在高并发下，绝对不能使用mysql，可以用redis的list结构

差异失效时间 用在双缓存架构

模拟高并发的天猫聚划算案例code

分析过程

步骤	说明
1	100%高并发，绝对不可以用MySQL实现
2	先把MySQL里面参加活动的数据抽取进redis，一般采用定时器扫描来决定上线活动还是下线取消。
3	支持分页功能，一页20条数据
	思考：什么样的数据类型支持上述功能？

高并发+定时任务+分页显示

redis数据类型选型

springboot+redis实现高并发的聚划算业务

创建entity对象

Java

package com.luojia.redis7_study.entities;

import io.swagger.annotations.ApiModel;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@AllArgsConstructor
@NoArgsConstructor
@ApiModel(value="聚划算活动Product信息")
public class Product {

    // 产品id
    private Long id;
    // 产品名称
    private String name;
    // 产品价格
    private Integer price;
    // 产品详情
    private String detail;

}

JHSTaskController

Java

package com.luojia.redis7_study.controller;

import com.luojia.redis7_study.entities.Product;
import io.swagger.annotations.Api;
import io.swagger.annotations.ApiOperation;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.util.CollectionUtils;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.List;

@Api(tags = "模拟聚划算商品上下架")
@RestController
@Slf4j
public class JHSTaskController {

    public static final String JHS_KEY = "jhs";
    public static final String JHS_KEY_A = "jhs:a";
    public static final String JHS_KEY_B = "jhs:b";

    @Autowired
    private RedisTemplate redisTemplate;

    @ApiOperation("聚划算案例，每次1页，每页5条数据")
    @GetMapping("/product/find")
    public List<Product> find(int page, int size) {
        long start = (page - 1) * size;
        long end = start + size - 1;
        List list = redisTemplate.opsForList().range(JHS_KEY, start, end);
        if (CollectionUtils.isEmpty(list)) {
            // todo Redis找不到，去数据库中查询
        }
        log.info("参加活动的商家: {}", list);
        return list;
    }
}

JHSTaskService：采用定时器将参与聚划算活动的特价商品新增进入redis中

Java

package com.luojia.redis7_study.service;

import com.luojia.redis7_study.entities.Product;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;

import javax.annotation.PostConstruct;
import java.util.ArrayList;
import java.util.List;
import java.util.Random;

@Service
@Slf4j
public class JHSTaskService {

    public static final String JHS_KEY = "jhs";
    public static final String JHS_KEY_A = "jhs:a";
    public static final String JHS_KEY_B = "jhs:b";

    @Autowired
    private RedisTemplate redisTemplate;

    /**
     * 假设此处是从数据库读取，然后加载到redis
     * @return
     */
    private List<Product> getProductsFromMysql() {
        ArrayList<Product> list = new ArrayList<>();
        for (int i = 0; i < 20; i++) {
            Random random = new Random();
            int id = random.nextInt(10000);
            Product product = new Product((long) id, "product" + i, i, "detail");
            list.add(product);
        }
        return list;
    }

    @PostConstruct
    public void initJHS() {
        log.info("模拟定时任务从数据库中不断获取参加聚划算的商品");
        // 1 用多线程模拟定时任务，将商品从数据库刷新到redis
        new Thread(() -> {
            while(true) {
                // 2 模拟从数据库查询数据
                List<Product> list = this.getProductsFromMysql();
                // 3 删除原来的数据
                redisTemplate.delete(JHS_KEY);
                // 4 加入最新的数据给Redis参加活动
                redisTemplate.opsForList().leftPushAll(JHS_KEY, list);
                // 5 暂停1分钟，模拟聚划算参加商品下架上新等操作
                try {
                    Thread.sleep(60000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }, "t1").start();
    }
}

至此步骤，上述聚划算的功能算是完成，请思考在高并发下有什么经典生产问题?

异常问题：热点缓存Key突然失效导致可怕的缓存击穿

delete命令执行的一瞬间有空隙，其他请求线程继续找redis，但是结果为null，请求直接打到redis，暴击数据库

最终目的：2条命令原子性还是其次，主要是要防止热key突然失效

进一步升级加固案例

互斥锁跟新，采用双检加锁策略
差异失效时间

代码更新:

JHSTaskController

Java

@ApiOperation("聚划算案例，AB双缓存，防止热key突然失效")
@GetMapping("/product/findab")
public List<Product> findAB(int page, int size) {
    List<Product> list = null;
    long start = (page - 1) * size;
    long end = start + size - 1;
    list = redisTemplate.opsForList().range(JHS_KEY_A, start, end);
    if (CollectionUtils.isEmpty(list)) {
        //  Redis找不到，去数据库中查询
        log.info("A缓存已经失效或活动已经结束");
        list = redisTemplate.opsForList().range(JHS_KEY_B, start, end);
        if (CollectionUtils.isEmpty(list)) {
            // todo Redis找不到，去数据库中查询
        }
    }
    log.info("参加活动的商家: {}", list);
    return list;
}

JHSTaskService

Java

// 双缓存
@PostConstruct
public void initJHSAB() {
    log.info("模拟定时任务从数据库中不断获取参加聚划算的商品");
    // 1 用多线程模拟定时任务，将商品从数据库刷新到redis
    new Thread(() -> {
        while(true) {
            // 2 模拟从数据库查询数据
            List<Product> list = this.getProductsFromMysql();
            // 3 先更新B缓存且让B缓存过期时间超过A缓存，如果突然失效还有B兜底，防止击穿
            redisTemplate.delete(JHS_KEY_B);
            redisTemplate.opsForList().leftPushAll(JHS_KEY_B, list);
            // 设置过期时间为1天+10秒
            redisTemplate.expire(JHS_KEY_B, 86410L, TimeUnit.SECONDS);
            // 4 在更新缓存A
            redisTemplate.delete(JHS_KEY_A);
            redisTemplate.opsForList().leftPushAll(JHS_KEY_A, list);
            redisTemplate.expire(JHS_KEY_A, 86400L, TimeUnit.SECONDS);
            // 5 暂停1分钟，模拟聚划算参加商品下架上新等操作
            try {
                Thread.sleep(60000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }, "t1").start();
}

11.基于缓存的Redis分布式锁

参考文章：https://blog.csdn.net/asd051377305/article/details/108384490

Redis除了拿来做缓存，还有基于Redis的其他用法吗

数据共享，分布式Session
分布式锁
全局ID
计算器、点赞
位统计
购物车
轻量级消息队列

list -> stream
抽奖
点赞、签到、打卡
交集差集并集，用户关注，可能认识的人
热点新闻、热搜排行

面试题：

Redis做分布式的时候需要注意什么问题？
你们公司自己实现的分布式锁是否用的setnx命令实现?这个是最合适的吗?你如何考虑分布式锁的可重入问题?
如果Redis是单点部署的，会带来什么问题？准备怎么解决单点问题呢？
Redis集群模式下，比如主从模式下，CAP方面有没有什么问题？
- Redis集群是AP，高可用；Redis单机是C，数据一致性
简单介绍一下RedLock，谈谈Redisson

https://blog.csdn.net/asd051377305/article/details/108384490

Redis分布式锁如何续期，看门狗是什么？

https://blog.csdn.net/weixin_51146329/article/details/129612350

看门狗机制是Redission提供的一种自动延期机制，这个机制使得Redission提供的分布式锁是可以自动续期的。

这里矛盾的点在于，中间件防止锁释放失败，添加了超时时间。然后又为了防止在超时时间后还未释放锁，设计了自动延期机制（看门狗）

锁的种类

单机版同一个虚拟机内**，synchronized或者Lock接口。**

分布式多个不同jvm虚拟机，单机的线程锁机制不再起作用，资源类在不同的服务器之间共享了。

一个靠谱的分布式锁需要具备的条件和刚需

独占性

任何时刻有且只能有一个线程持有
高可用

若为redis集群环境下，不能因为某一个节点挂了而出现获取锁和释放锁失败的情况

高并发请求下，依旧性能OK好使
防死锁

杜绝死锁，必须有超时控制机制或者撤销操作，有个兜底终止跳出方案
不乱抢

防止张冠李戴，不能私底下unlock别人的锁，只能自己加锁自己释放
重入性

同一个节点的同一个线程如果获得锁之后，它也可以再次获取这个锁

分布式锁

setnx key value

基于redis命令：setnx+expire不安全，两条命令为非原子性命令

基于redis Lua脚本能力：set key value[EX seconds] [PX milliseconds] [NX|XX]是一条命令，

重点

JUC中AQS锁的规范落地参考+可重入锁+Lua脚本+Redis命令一步步实现分布式锁

Base案例(boot+redis)

使用场景：多个服务间保证同一时间段内同一用户只能有一个请求（防止关键业务出现并发攻击）

建Module

redis_distributed_lock2

redis_distributed_lock3

写POM

Xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.7.11</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>com.luojia</groupId>
    <artifactId>redis_distributed_lock2</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>redis_distributed_lock2</name>
    <description>Demo project for Spring Boot</description>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <java.version>1.8</java.version>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <lombok.version>1.16.18</lombok.version>
    </properties>

    <dependencies>
        <!--SpringBoot 通用依赖模块-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <!-- SpringBoot 与Redis整合依赖 -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-pool2</artifactId>
        </dependency>
        <!-- swagger2 -->
        <dependency>
            <groupId>io.springfox</groupId>
            <artifactId>springfox-swagger2</artifactId>
            <version>2.9.2</version>
        </dependency>
        <dependency>
            <groupId>io.springfox</groupId>
            <artifactId>springfox-swagger-ui</artifactId>
            <version>2.9.2</version>
        </dependency>

        <dependency>
            <groupId>cn.hutool</groupId>
            <artifactId>hutool-all</artifactId>
            <version>5.2.3</version>
        </dependency>

        <!-- 通用基础配置 -->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>${lombok.version}</version>
            <optional>true</optional>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

改YML

Properties

server.port=7777
spring.application.name=redis_distributed_lock2
# =====================swaqqer2=====================
# http://localhost:7777/swagger-ui.html
swagger2.enabled=true
spring.mvc.pathmatch.matching-strategy=ant_path_matcher
# =====================redis单机=====================
spring.redis.database=0
#修改为自己真实IP
spring.redis.host=127.0.0.1
spring.redis.port=6379
spring.redis.password=123456
spring.redis.lettuce.pool.max-active=8
spring.redis.1ettuce.pool.max-wait=-1ms
spring.redis.1ettuce.pool.max-idle=8
spring.redis.lettuce.pool.min-idle=0

主启动

业务类

InventoryService

Java

package com.luojia.redislock.service;

import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

@Service
@Slf4j
public class InventoryService {
    
    @Autowired
    private StringRedisTemplate stringRedisTemplate;
    @Value("${server.port}")
    private String port;

    private Lock lock = new ReentrantLock();

    public String sale() {
        String resMessgae = "";
        lock.lock();
        try {
            // 1 查询库存信息
            String result = stringRedisTemplate.opsForValue().get("inventory01");
            // 2 判断库存书否足够
            Integer inventoryNum = result == null ? 0 : Integer.parseInt(result);
            // 3 扣减库存，每次减少一个库存
            if (inventoryNum > 0) {
                stringRedisTemplate.opsForValue().set("inventory01", String.valueOf(--inventoryNum));
                resMessgae = "成功卖出一个商品，库存剩余：" + inventoryNum;
                log.info(resMessgae + "\t" + "，服务端口号：" + port);
            } else {
                resMessgae = "商品已售罄。";
                log.info(resMessgae + "\t" + "，服务端口号：" + port);
            }
        } finally {
            lock.unlock();
        }
        return resMessgae;
    }
}

InventoryController

Java

package com.luojia.redislock.controller;

import com.luojia.redislock.service.InventoryService;
import io.swagger.annotations.Api;
import io.swagger.annotations.ApiOperation;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@Api(tags = "redis分布式锁测试")
public class InventoryController {
    @Autowired
    private InventoryService inventoryService;

    @GetMapping("/inventory/sale")
    @ApiOperation("扣减库存，一次卖一个")
    public void sale() {
        inventoryService.sale();
    }
}

手写分布式锁思路分析

上述笔记代码的不足

初始化版本简单添加

业务类，将上面7777的业务逻辑代码原样拷贝到8888，加上synchronized或者Lock
nginx分布式微服务架构
- v2.0版本代码分布式部署后，单机锁还是出现超卖现象，需要分布式锁

Nginx配置负载均衡

命令地址+配置地址

命令地址：/usr/local/nginx/sbin

配置地址：/usr/local/nginx/conf
启动

/usr/local/nginx/sbin 执行./nginx

启动Nginx并测试通过，浏览器看到Nginx欢迎welcome页面
/usr/local/nginx/conf目录下修改配置文件nginx.conf新增反向代理和负载均衡配置

关闭

/usr/local/nginx/sbin 执行./nginx -s stop
指定配置启动

在/usr/local/nginx/sbin 路径下执行命令 ./nginx -c nginx.conf全路径

重启

在/usr/local/nginx/sbin 执行./nginx -s reload
v2.0版本代码修改+启动两个微服务

通过Nginx访问，自己Linux服务器IP地址，反向代理+负载均衡

可以点击查看效果，可以看到一边一个，通过配置的权重来轮询

http://1270.0.1/inventory/sale
上面纯手工点击验证OK，下面高并发模拟
- 使用jmeter进行压测
- 创建线程组Redis

创建一个http请求

jmeter压测

查看报告

执行绿色执行按钮，开始并发请求程序
发现商品出现超卖

- Bug？why？
  
  synchronized和ReentrantLock是单机锁，只能管住当前自己的jvm。
  
  在单机环境下，可以使用synchronized或Lock来实现
  
  但是在分布式系统中，因为竞争的线程可能不在同一个节点上(同一个jvm中)，所以需要一个让所有进程都能访问到的锁来实现(比如redis或者zookeeper来构建)
  
  不同进程ivm层面的锁就不管用了，那么可以利用第三方的一个组件，来获取锁，未获取到锁，则阻塞当前想要运行的线程
- 分布式锁出现
  
  跨进程+跨服务
  
  解决超卖
  
  防止缓存击穿
解决

上Redis分布式锁setnx；Redis具有极高的性能,且其命令对分布式锁支持友好,借助SET 命令即可实现加锁处理。

代码改造为3.1版

Java

public String sale() {
    String resMessgae = "";
    String key = "luojiaRedisLocak";
    String uuidValue = IdUtil.simpleUUID() + ":" + Thread.currentThread().getId();

    Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, uuidValue);
    // 抢不到的线程继续重试
    if (!flag) {
        // 线程休眠20毫秒，进行递归重试
        try {
            TimeUnit.MILLISECONDS.sleep(20);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        sale();
    } else {
        try {
            // 1 抢锁成功，查询库存信息
            String result = stringRedisTemplate.opsForValue().get("inventory01");
            // 2 判断库存书否足够
            Integer inventoryNum = result == null ? 0 : Integer.parseInt(result);
            // 3 扣减库存，每次减少一个库存
            if (inventoryNum > 0) {
                stringRedisTemplate.opsForValue().set("inventory01", String.valueOf(--inventoryNum));
                resMessgae = "成功卖出一个商品，库存剩余：" + inventoryNum + "\t" + "，服务端口号：" + port;
                log.info(resMessgae);
            } else {
                resMessgae = "商品已售罄。" + "\t" + "，服务端口号：" + port;
                log.info(resMessgae);
            }
        } finally {
            stringRedisTemplate.delete(key);
        }
    }
    return resMessgae;
}

通过递归的方式来完成重试，不断获取锁

但是依旧有问题：手工设置5000个线程来抢占锁，压测OK，但是容易导致StackOverflowError，不推荐，需要进一步完善

修改为3.2版

多线程判断想想JUC里面说过的虚假唤醒，用while替代if，用自旋锁代替递归重试

Java

public String sale() {
    String resMessgae = "";
    String key = "luojiaRedisLocak";
    String uuidValue = IdUtil.simpleUUID() + ":" + Thread.currentThread().getId();

    // 不用递归了，高并发容易出错，我们用自旋代替递归方法重试调用；也不用if，用while代替
    while (!stringRedisTemplate.opsForValue().setIfAbsent(key, uuidValue)) {
        // 线程休眠20毫秒，进行递归重试
        try {TimeUnit.MILLISECONDS.sleep(20);} catch (InterruptedException e) {e.printStackTrace();}
    }

    try {
        // 1 抢锁成功，查询库存信息
        String result = stringRedisTemplate.opsForValue().get("inventory01");
        // 2 判断库存书否足够
        Integer inventoryNum = result == null ? 0 : Integer.parseInt(result);
        // 3 扣减库存，每次减少一个库存
        if (inventoryNum > 0) {
            stringRedisTemplate.opsForValue().set("inventory01", String.valueOf(--inventoryNum));
            resMessgae = "成功卖出一个商品，库存剩余：" + inventoryNum + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        } else {
            resMessgae = "商品已售罄。" + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        }
    } finally {
        stringRedisTemplate.delete(key);
    }
    return resMessgae;
}

V3.2代码存在的问题

需要防止服务器突然宕机导致程序死锁

部署了微服务的Java程序机器挂了，代码层面根本没有走到finally这块，没办法保证解锁(无过期时间该key一直存在)，这个key没有被删除，需要加入一个过期时间限定key

解决

修改代码为v4.1版

Java

while (!stringRedisTemplate.opsForValue().setIfAbsent(key, uuidValue)) {
            // 线程休眠20毫秒，进行递归重试
            try {TimeUnit.MILLISECONDS.sleep(20);} catch (InterruptedException e) {e.printStackTrace();}
        }

        // 设置过期时间
        stringRedisTemplate.expire(key, 30L, TimeUnit.SECONDS);

4.1版本结论

不可行，设置的key+过期时间分开了，必须要合并成一行使其具备原子性
修改为4.2版

Java

while (!stringRedisTemplate.opsForValue().setIfAbsent(key, uuidValue, 30L, TimeUnit.SECONDS)) {
            // 线程休眠20毫秒，进行递归重试
            try {TimeUnit.MILLISECONDS.sleep(20);} catch (InterruptedException e) {e.printStackTrace();}
        }

4.2版本结论

加锁和过期时间设置必须同一行，保证原子性

v4.2版本代码问题

实际业务中，如果处理时间超过了设置的key的过期时间，那删除key的时候岂不是张冠李戴，删除了别人的锁

解决

只能自己删除自己的，不允许删除别人的说，修改代码为5.0版本

Java

// v5.0 版本
public String sale() {
    String resMessgae = "";
    String key = "luojiaRedisLocak";
    String uuidValue = IdUtil.simpleUUID() + ":" + Thread.currentThread().getId();

    // 不用递归了，高并发容易出错，我们用自旋代替递归方法重试调用；也不用if，用while代替
    while (!stringRedisTemplate.opsForValue().setIfAbsent(key, uuidValue, 30L, TimeUnit.SECONDS)) {
        // 线程休眠20毫秒，进行递归重试
        try {TimeUnit.MILLISECONDS.sleep(20);} catch (InterruptedException e) {e.printStackTrace();}
    }

    try {
        // 1 抢锁成功，查询库存信息
        String result = stringRedisTemplate.opsForValue().get("inventory01");
        // 2 判断库存书否足够
        Integer inventoryNum = result == null ? 0 : Integer.parseInt(result);
        // 3 扣减库存，每次减少一个库存
        if (inventoryNum > 0) {
            stringRedisTemplate.opsForValue().set("inventory01", String.valueOf(--inventoryNum));
            resMessgae = "成功卖出一个商品，库存剩余：" + inventoryNum + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        } else {
            resMessgae = "商品已售罄。" + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        }
    } finally {
        // v5.0 改进点，判断加锁与解锁是不同客户端，自己只能删除自己的锁，不误删别人的锁
        if (stringRedisTemplate.opsForValue().get(key).equalsIgnoreCase(uuidValue)) {
            stringRedisTemplate.delete(key);
        }
    }
    return resMessgae;
}

v5.0依旧存在问题

finally代码块的判断+del删除不是原子性的

启用Lua脚本编写redis分布式锁判断+删除判断代码

lua脚本

官网解释：https://redis.io/docs/manual/patterns/distributed-locks/

Lua脚本浅谈

Lua脚本初识

Redis调用Lua脚本通过eval命令保证代码执行的原子性，直接用return返回脚本执行后的结果值

Lua脚本进一步

Redis分布式锁Lua脚本官网练习

C

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

条件语法判断

条件判断案例

C

if KEYS[1] > KEYS[2] then return ARGV[1] elseif KEYS[1] < KEYS[2] then return ARGV[2] else return ARGV[3] end

通过Lua脚本解决v5.0版本Bug

Java

public String sale() {
    String resMessgae = "";
    String key = "luojiaRedisLocak";
    String uuidValue = IdUtil.simpleUUID() + ":" + Thread.currentThread().getId();

    // 不用递归了，高并发容易出错，我们用自旋代替递归方法重试调用；也不用if，用while代替
    while (!stringRedisTemplate.opsForValue().setIfAbsent(key, uuidValue, 30L, TimeUnit.SECONDS)) {
        // 线程休眠20毫秒，进行递归重试
        try {TimeUnit.MILLISECONDS.sleep(20);} catch (InterruptedException e) {e.printStackTrace();}
    }

    try {
        // 1 抢锁成功，查询库存信息
        String result = stringRedisTemplate.opsForValue().get("inventory01");
        // 2 判断库存书否足够
        Integer inventoryNum = result == null ? 0 : Integer.parseInt(result);
        // 3 扣减库存，每次减少一个库存
        if (inventoryNum > 0) {
            stringRedisTemplate.opsForValue().set("inventory01", String.valueOf(--inventoryNum));
            resMessgae = "成功卖出一个商品，库存剩余：" + inventoryNum + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        } else {
            resMessgae = "商品已售罄。" + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        }
    } finally {
        // 改进点，修改为Lua脚本的Redis分布式锁调用，必须保证原子性，参考官网脚本案例
        String luaScript =
            "if redis.call('get',KEYS[1]) == ARGV[1] then " +
            "return redis.call('del',KEYS[1]) " +
            "else " +
            "return 0 " +
            "end";
        stringRedisTemplate.execute(new DefaultRedisScript(luaScript, Boolean.class), Arrays.asList(key), uuidValue);

    }
    return resMessgae;
}

可重入锁又名递归锁

说明：

TEXT

可重入锁又名递归锁

是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁(前提，锁对象得是同一个对象)，不会因为之前已经获取过还没释放而阻塞。

如果是1个有synchronized修饰的递归调用方法，程序第2次进入被自己阻塞了岂不是天大的笑话，出现了作茧自缚。
所以Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可以一定程度避免死锁。

可重入锁这四个字分开来解释：

可：可以

重：再次

入：进入

锁：同步锁

进入什么：进入同步域（即同步代码块/方法或显示锁锁定的代码）

一句话：一个线程中的多个流程可以获取同一把锁，持有这把同步锁可以再次进入。自己可以获取自己的内部锁

可重入锁种类

隐式锁(即synchronized关键字使用的锁) 默认是可重入锁

TEXT

指的是可重复可递归调用的锁，在外层使用锁之后。在内层仍然可以使用，并目不发生死锁，这样的锁就叫做可重入锁。简单的来说就是:在一个synchronied修饰的方法或代码块的内部调用本类的其他synchronized修饰的方法或代码块时，是永远可以得到锁的。
与可重入锁相反，不可重入锁不可递归调用，递归调用就发生死锁。

Synchronized的重入的实现机理

TEXT

    每个锁对象拥有一个锁计数器和一个指向持有该锁的线程的指针。

    当执行monitorenter时，如果目标锁对象的计数器为零，那么说明它没有被其他线程所持有，Java虚拟机会将该锁对象的持有线程设置为当前线程，并且将其计数器加1。

    在目标锁对象的计数器不为零的情况下，如果锁对象的持有线程是当前线程，那么 Java 虚拟机可以将其计数器加1，否则需要等待直至持有线程释放该锁。
    当执行monitorexit时，Java虚拟机则需将锁对象的计数器减1。计数器为零代表锁已被释放。

显式锁(即Lock)也有ReentrantLock这样的可重入锁

TEXT

一个Synchronized修饰的方法或代码块的内部调用本类的其他Synchronized修饰的方法或代码块时，是永远可以得到锁

lock/unlock配合可重入锁进行AQS源码分析讲解

切记，一般而言，你Lock了几次就要unlock几次；

可以分析new ReentrantLock();查看

上述可重入锁的计数问题，redis中哪个数据类型可以替代

K K V 数据结构

TEXT

hset luojiaRedisLock 0c90d37cb6ec42268861b3d739f8b3a8:1 11
    
type luojiaRedisLock -> hash

Map<String, Map<Object, Object>>

小总结

setnx只能解决有无的问题，够用但是不完美

hset，不但解决有无，还能解决可重入问题

设计重点（一横一纵）

目前两个分支，目的是保证同一个时候只能有一个线程持有锁进去redis做扣减库存动作

一个分支保证加锁/解锁，lock/unlock;

另一个分支扣减库存，redis命令的原子性‘

加锁Lua脚本lock

先判断redis分布式锁这个key是否存在

EXISTS key：

返回零说明不存在，hset新建当前线程属于自己的锁，field key格式为UUID:ThreadID，value为加锁次数；

返回壹说明已经有锁，需进一步判断是不是当前线程自己的 ->

HEXISTS key uuid:ThreadID：返回0说明不是自己的锁；返回1说明是自己的锁，自增1次表示重入

HINCRBY key UUID:ThreadID 1
上述设计修改为Lua脚本

V1版本

Java

// 加锁的Lua脚本，对标我们的lock方法
if redis.call('exists', 'key') == 0 then
	redis.call('hset', 'key', 'uuid:threadid', 1)
	redis.call('expire', 'key', 50)
	return 1
elseif redis.call('hexists', 'key', 'uuid:threadid') == 1 then
	redis.call('hincrby', 'key', 'uuid:threadid', 1)
	redis.call('expire', 'key', 50)
	return 1
else
	return 0
end

V2版本

当key不存在的时候，hincrby可以自动创建这个key并且自增

Java

// V2 合并相同的代码，用hincrby替代hset，精简代码
if redis.call('exists', 'key') == 0 or redis.call('hexists', 'key', 'uuid:threadid') == 1 then
	redis.call('hincrby', 'key', 'uuid:threadid', 1)
	redis.call('expire', 'key', 50)
	return 1
else
	return 0
end

V3版本

Java

// V3 脚本OK，换上参数来替代写死的key，value
if redis.call('exists', KEYS[1]) == 0 or redis.call('hexists', KEYS[1], ARGV[1]) == 1 then
	redis.call('hincrby', KEYS[1], ARGV[1], 1)
	redis.call('expire', KEYS[1], ARGV[2])
	return 1
else
	return 0
end

测试

Java

-- 已完成验证
if redis.call('exists', KEYS[1]) == 0 or redis.call('hexists', KEYS[1], ARGV[1]) == 1 then redis.call('hincrby', KEYS[1], ARGV[1], 1) redis.call('expire', KEYS[1], ARGV[2]) return 1 else return 0 end

eval "if redis.call('exists', KEYS[1]) == 0 or redis.call('hexists', KEYS[1], ARGV[1]) == 1 then redis.call('hincrby', KEYS[1], ARGV[1], 1) redis.call('expire', KEYS[1], ARGV[2]) return 1 else return 0 end" 1 luojiaRedisLock 001122:1 50

解锁LUA脚本unlock

设计思路：有锁且还是自己的锁 -> HEXISTS key uuid:ThreadID

返回零，说明根本没有锁，程序块返回nil

不是零，说明有锁且是自己的锁，直接调用HINCRBY负一，表示每次减一，解锁一次直到它变成零表示可以删除该锁Key，del锁
上述设计修改为Lua脚本

V1版本

Java

  // 解锁的Lua脚本，对标我们的lock方法
  if redis.call('hexists', 'key', uuid:threadid) == 0 then
  	return nil
  elseif redis.call('hincrby', key, uuid:threadid, -1) == 0 then
      return redis.call('del', key)
  else 
      return 0
  end

V2版本

Java

if redis.call('hexists', KEYS[1], ARGV[1]) == 0 then
	return nil
elseif redis.call('hincrby', KEYS[1], ARGV[1], -1) == 0 then
    return redis.call('del', KEYS[1])
else 
    return 0
end

测试验证

Java

if redis.call('hexists', KEYS[1], ARGV[1]) == 0 then return nil elseif redis.call('hincrby', KEYS[1], ARGV[1], -1) == 0 then return redis.call('del', KEYS[1]) else return 0 end

eval "if redis.call('hexists', KEYS[1], ARGV[1]) == 0 then return nil elseif redis.call('hincrby', KEYS[1], ARGV[1], -1) == 0 then return redis.call('del', KEYS[1]) else return 0 end " 1 luojiaRedisLock 001122:1

LUA脚本整合JAVA程序

步骤一：复原程序为初识无锁版本

Java

public String sale() {
    String resMessgae = "";

    try {
        // 1 抢锁成功，查询库存信息
        String result = stringRedisTemplate.opsForValue().get("inventory01");
        // 2 判断库存书否足够
        Integer inventoryNum = result == null ? 0 : Integer.parseInt(result);
        // 3 扣减库存，每次减少一个库存
        if (inventoryNum > 0) {
            stringRedisTemplate.opsForValue().set("inventory01", String.valueOf(--inventoryNum));
            resMessgae = "成功卖出一个商品，库存剩余：" + inventoryNum + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        } else {
            resMessgae = "商品已售罄。" + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        }
    } finally {

    }
    return resMessgae;
}

步骤二：新建RedisDistributedLock类实现JUC里面的Lock接口

步骤三：满足JUC里面AQS对Lock锁的接口规范定义来进行实现落地代码

步骤四：结合设计模式开发属于自己的Redis分布式锁工具类

lua脚本加锁

Java

if redis.call('exists', KEYS[1]) == 0 or redis.call('hexists', KEYS[1], ARGV[1]) == 1 then
	redis.call('hincrby', KEYS[1], ARGV[1], 1)
	redis.call('expire', KEYS[1], ARGV[2])
	return 1
else
	return 0
end

lua脚本解锁

Java

if redis.call('hexists', KEYS[1], ARGV[1]) == 0 then
	return nil
elseif redis.call('hincrby', KEYS[1], ARGV[1], -1) == 0 then
    return redis.call('del', KEYS[1])
else 
    return 0
end

工厂设计模式引入

通过实现JUC里面的Lock接口，实现Redis分布式锁RedisDistributedLock

Java

package com.luojia.redislock.mylock;

import cn.hutool.core.util.IdUtil;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;

import java.util.Arrays;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;

/**
 * 自研的分布式锁，实现了Lock接口
 */
public class RedisDistributedLock implements Lock {

    private StringRedisTemplate stringRedisTemplate;

    private String lockName; // KEYS[1]
    private String uuidValule; // ARGV[1]
    private long expireTime; // ARGV[2]

    public RedisDistributedLock(StringRedisTemplate stringRedisTemplate, String lockName) {
        this.stringRedisTemplate = stringRedisTemplate;
        this.lockName = lockName;
        this.uuidValule = IdUtil.simpleUUID() + ":" + Thread.currentThread().getId();
        this.expireTime = 50L;
    }

    @Override
    public void lock() {
        tryLock();
    }

    @Override
    public boolean tryLock() {
        try {
            tryLock(-1L, TimeUnit.SECONDS);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return false;
    }

    @Override
    public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
        if (-1 == time) {
            String script =
                    "if redis.call('exists', KEYS[1]) == 0 or redis.call('hexists', KEYS[1], ARGV[1]) == 1 then " +
                        "redis.call('hincrby', KEYS[1], ARGV[1], 1) " +
                        "redis.call('expire', KEYS[1], ARGV[2]) " +
                        "return 1 " +
                    "else " +
                         "return 0 " +
                    "end";
            System.out.println("lockName:" + lockName + "\t" + "uuidValue:" + uuidValule);

            // 加锁失败需要自旋一直获取锁
            while (!stringRedisTemplate.execute(
                    new DefaultRedisScript<>(script, Boolean.class),
                    Arrays.asList(lockName),
                    uuidValule,
                    String.valueOf(expireTime))) {
                // 休眠60毫秒再来重试
                try {TimeUnit.MILLISECONDS.sleep(60);} catch (InterruptedException e) {e.printStackTrace();}
            }
            return true;
        }
        return false;
    }

    @Override
    public void unlock() {
        String script = "" +
                "if redis.call('hexists', KEYS[1], ARGV[1]) == 0 then " +
                "return nil " +
                "elseif redis.call('hincrby', KEYS[1], ARGV[1], -1) == 0 then " +
                "return redis.call('del', KEYS[1]) " +
                "else " +
                "return 0 " +
                "end";
        System.out.println("lockName:" + lockName + "\t" + "uuidValue:" + uuidValule);
        
        // LUA脚本由C语言编写，nil -> false; 0 -> false; 1 -> true;
        // 所以此处DefaultRedisScript构造函数返回值不能是Boolean，Boolean没有nil
        Long flag = stringRedisTemplate.execute(
                new DefaultRedisScript<>(script, Long.class),
                Arrays.asList(lockName),
                uuidValule);
        if (null == flag) {
            throw new RuntimeException("this lock does not exists.");
        }
    }

    // 下面两个暂时用不到，不用重写
    @Override
    public void lockInterruptibly() throws InterruptedException {

    }

    @Override
    public Condition newCondition() {
        return null;
    }
}

Java

// v7.0 使用自研的lock/unlock+LUA脚本自研的Redis分布式锁
Lock redisDistributedLock = new RedisDistributedLock(stringRedisTemplate, "luojiaRedisLock");
public String sale() {
    String resMessgae = "";
    redisDistributedLock.lock();
    try {
        // 1 抢锁成功，查询库存信息
        String result = stringRedisTemplate.opsForValue().get("inventory01");
        // 2 判断库存书否足够
        Integer inventoryNum = result == null ? 0 : Integer.parseInt(result);
        // 3 扣减库存，每次减少一个库存
        if (inventoryNum > 0) {
            stringRedisTemplate.opsForValue().set("inventory01", String.valueOf(--inventoryNum));
            resMessgae = "成功卖出一个商品，库存剩余：" + inventoryNum + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        } else {
            resMessgae = "商品已售罄。" + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        }
    } finally {
        redisDistributedLock.unlock();
    }
    return resMessgae;
}

如果直接使用上面的代码设计，会有什么问题

需要考虑扩展，本次是Redis实现分布式锁，以后zookeeper、MySQL实现呢？
引入工厂模式改造7.1版code

DistributedLockFactory

Java

package com.luojia.redislock.mylock;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Component;

import java.util.concurrent.locks.Lock;

@Component
public class DistributedLockFactory {

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    public Lock getDistributedLock(String lockType, String lockName) {
        if (lockType == null) {
            return null;
        }

        if ("REDIS".equalsIgnoreCase(lockType)) {
            return new RedisDistributedLock(stringRedisTemplate, lockName);
        } else if ("ZOOKEEPER".equalsIgnoreCase(lockType)) {
            // 后面存在就返回对应的分布式锁
        } else if ("MYSQL".equalsIgnoreCase(lockType)) {
            // 后面存在就返回对应的分布式锁
        }

        return null;
    }
}

InventoryService使用工厂模式版本

Java

// v7.0 使用自研的lock/unlock+LUA脚本自研的Redis分布式锁
@Autowired
private DistributedLockFactory distributedLockFactory;
public String sale() {
    String resMessgae = "";
    Lock redisLock = distributedLockFactory.getDistributedLock("REDIS", "luojiaRedisLock");
    redisLock.lock();
    try {
        // 1 抢锁成功，查询库存信息
        String result = stringRedisTemplate.opsForValue().get("inventory01");
        // 2 判断库存书否足够
        Integer inventoryNum = result == null ? 0 : Integer.parseInt(result);
        // 3 扣减库存，每次减少一个库存
        if (inventoryNum > 0) {
            stringRedisTemplate.opsForValue().set("inventory01", String.valueOf(--inventoryNum));
            resMessgae = "成功卖出一个商品，库存剩余：" + inventoryNum + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        } else {
            resMessgae = "商品已售罄。" + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        }
    } finally {
        redisLock.unlock();
    }
    return resMessgae;
}

单机+并发通过测试

可重入测试

InventoryService类新增可重入测试方法

Java

// v7.1 使用工厂类创建锁
@Autowired
private DistributedLockFactory distributedLockFactory;
public String sale() {
    String resMessgae = "";
    Lock redisLock = distributedLockFactory.getDistributedLock("REDIS", "luojiaRedisLock");
    redisLock.lock();
    try {
        // 1 抢锁成功，查询库存信息
        String result = stringRedisTemplate.opsForValue().get("inventory01");
        // 2 判断库存书否足够
        Integer inventoryNum = result == null ? 0 : Integer.parseInt(result);
        // 3 扣减库存，每次减少一个库存
        if (inventoryNum > 0) {
            stringRedisTemplate.opsForValue().set("inventory01", String.valueOf(--inventoryNum));
            resMessgae = "成功卖出一个商品，库存剩余：" + inventoryNum + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
            testReEntry();
        } else {
            resMessgae = "商品已售罄。" + "\t" + "，服务端口号：" + port;
            log.info(resMessgae);
        }
    } finally {
        redisLock.unlock();
    }
    return resMessgae;
}

private void testReEntry() {

    Lock redisLock = distributedLockFactory.getDistributedLock("REDIS", "luojiaRedisLock");
    redisLock.lock();
    try {
        log.info("=================测试可重入锁=================");
    } finally {
        redisLock.unlock();
    }
}

结果：无法重入

testReEntry方法中，会创建一个新的锁Key，因为ThreadID一致了，但是UUID不OK

引入工厂模式改造7.2版本code

DistributedLockFactory -> 新增一个无参构造函数

Java

package com.luojia.redislock.mylock;

import cn.hutool.core.util.IdUtil;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Component;

import java.util.concurrent.locks.Lock;

@Component
public class DistributedLockFactory {

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    private String uuid;

    public DistributedLockFactory() {
        this.uuid = IdUtil.simpleUUID();
    }

    public Lock getDistributedLock(String lockType, String lockName) {
        if (lockType == null) {
            return null;
        }

        if ("REDIS".equalsIgnoreCase(lockType)) {
            return new RedisDistributedLock(stringRedisTemplate, lockName, uuid);
        } else if ("ZOOKEEPER".equalsIgnoreCase(lockType)) {
            // 后面存在就返回对应的分布式锁
        } else if ("MYSQL".equalsIgnoreCase(lockType)) {
            // 后面存在就返回对应的分布式锁
        }
        return null;
    }
}

RedisDistributedLock -> 修改构造方法

Java

// V7.2 
public RedisDistributedLock(StringRedisTemplate stringRedisTemplate, String lockName, String uuid) {
    this.stringRedisTemplate = stringRedisTemplate;
    this.lockName = lockName;
    this.uuidValule = uuid + ":" + Thread.currentThread().getId();
    this.expireTime = 50L;
}

使用@Autowired创建的工厂类是一个单例的，在spring进行注入的时候已经初始化好了，所以所有线程产生的UUID都是一样的

确保RedisLock过期时间大于业务执行时间的问题

时间到了，业务没有执行完需要自动续期

CAP

原文：https://blog.csdn.net/lixinkuan328/article/details/95535691

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值，即写操作之后的读操作，必须返回该值。（分为弱一致性、强一致性和最终一致性）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

取舍策略 CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：

**CA without P：**如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。传统的关系型数据库RDBMS：Oracle、MySQL就是CA。

**CP without A：**如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

**AP wihtout C：**要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

Redis集群是AP

redis异步复制造成的锁丢失，比如：主节点没来的及把刚刚set进来的这条数据给从节点，master就挂了，从机上位但是从机上无数据
Zookeeper集群是CP

故障：

Eureka集群是AP

Nacos集群是AP

自动续期的LUA脚本

TEXT

// 自动续期的LUA脚本
if redis.call('hexists', KEYS[1], ARGV[1]) == 1 then
    return redis.call('expire', KEYS[1], ARGV[2])
else
    return 0
end

测试验证

TEXT


if redis.call('hexists', KEYS[1], ARGV[1]) == 1 then return redis.call('expire', KEYS[1], ARGV[2]) else return 0 end
---
hset luojiaRedisLock test 001
expire luojiaRedisLock 30
eval "if redis.call('hexists', KEYS[1], ARGV[1]) == 1 then return redis.call('expire', KEYS[1], ARGV[2]) else return 0 end" 1 luojiaRedisLock test 1

8.0新增自动续期功能

Java

@Override
public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
    if (-1 == time) {
        String script =
            "if redis.call('exists', KEYS[1]) == 0 or redis.call('hexists', KEYS[1], ARGV[1]) == 1 then " +
            "redis.call('hincrby', KEYS[1], ARGV[1], 1) " +
            "redis.call('expire', KEYS[1], ARGV[2]) " +
            "return 1 " +
            "else " +
            "return 0 " +
            "end";
        System.out.println("lock() lockName:" + lockName + "\t" + "uuidValue:" + uuidValule);

        // 加锁失败需要自旋一直获取锁
        while (!stringRedisTemplate.execute(
            new DefaultRedisScript<>(script, Boolean.class),
            Arrays.asList(lockName),
            uuidValule,
            String.valueOf(expireTime))) {
            // 休眠60毫秒再来重试
            try {TimeUnit.MILLISECONDS.sleep(60);} catch (InterruptedException e) {e.printStackTrace();}
        }
        // 新建一个后台扫描程序，来检查Key目前的ttl，是否到我们规定的剩余时间来实现锁续期
        resetExpire();
        return true;
    }
    return false;
}

// 自动续期
private void resetExpire() {
    String script =
        "if redis.call('hexists', KEYS[1], ARGV[1]) == 1 then " +
        "return redis.call('expire', KEYS[1], ARGV[2]) " +
        "else " +
        "return 0 " +
        "end";
    new Timer().schedule(new TimerTask() {
        @Override
        public void run() {
            if (stringRedisTemplate.execute(
                new DefaultRedisScript<>(script, Boolean.class),
                Arrays.asList(lockName),
                uuidValule,
                String.valueOf(expireTime))) {
                // 续期成功，继续监听
                System.out.println("resetExpire() lockName:" + lockName + "\t" + "uuidValue:" + uuidValule);
                resetExpire();
            }
        }
    }, (this.expireTime * 1000 / 3));
}

总结

synchronized单机版OK； -> v1.0

Nginx分布式微服务，轮询多台服务器，单机锁不行；-> v2.0

取消单机锁，上redis分布式锁setnx，中小企业使用没问题；-> v3.1

只是加锁了，没有释放锁，出异常的话，可能无法释放锁，必须要在代码层面finally释放锁 -> v3.2

如果服务宕机，部署了微服务代码层面根本就没有走到finally这块，没办法保证解锁，这个Key没有被删除，需要对锁设置过期时间 -> v3.2

为redis的分布式锁key增加过期时间，还必须要保证setnx+过期时间在同一行，保证原子性 -> v4.1

程序由于执行超过锁的过期时间，所以在finally中必须规定只能自己删除自己的锁，不能把别人的锁删除了，防止张冠李戴 -> v5.0

将Lock、unlock变成LUA脚本保证原子性； -> v6.0

保证锁的可重入性，hset替代setnx+Lock变成LUA脚本，保障可重入性； -> v7.0

锁的自动续期 -> v8.0

12.RedLock算法

翻译过来就是红锁。

前提：

自研一把分布式锁，面试回答的主要考点

按照JUC里面java.util.concurrent.locks.Lock接口规范编写
lock()加锁关键逻辑
- 加锁：加锁实际上就是在redis中，给key设置一个值，为了避免死锁，并给定一个过期时间
- 可重入：加锁的LUA脚本，通过redis里面的hash数据模型，加锁和可重入性都要保证
- 自旋：加锁不成，需要while进行重试并自旋，AQS
- 续期：在过期时间内，一定时间内业务还未完成，自动给锁续期

3.unlock()解锁关键逻辑

将redis的key删除，但是也不能乱删，不能说客户端1的请求将客户端2的锁给删除掉了，只能自己删自己的锁
考虑可重入性的递减，加锁几次就需要删除几次
最后到零了，直接del删除

上面自研的redis锁对于一般中小公司，不是特别高并发场景足够用了，单机redis小业务也撑得住

Redis分布式锁-Redlock红锁算法 Distributed locks with Redis

官网：https://redis.io/docs/manual/patterns/distributed-locks/

解释:

为什么学习这个？怎么产生的？

之前手写的分布式锁有什么缺点：

翻译：

有时在特殊情况下，例如在故障期间，多个客户端可以同时持有锁是完全没问题的。如果是这种情况，您可以使用基于复制的解决方案。否则，我们建议实施本文档中描述的解决方案。

线程1首先获取锁成功，将键值对写入redis 的 master节点，在 redis将该键值对同步到slave 节点之前，master发生了故障；

redis触发故障转移，其中一个slave升级为新的 master，此时新上位的master并不包含线程1写入的键值对，因此线程⒉尝试获取锁也可以成功拿到锁，此时相当于有两个线程获取到了锁，可能会导致各种预期之外的情况发生，例如最常见的脏数据。

我们加的是排它独占锁，同一时间只能有一个建redis锁成功并持有锁，严禁出现2个以上的请求线程拿到锁。

RedLock算法设计理念

Redis之父提出了RedLock算法解决上面这个一锁被多建的问题

Redis也提供了Redlock算法，用来实现基于多个实例的分布式锁。锁变量由多个实例维护，即使有实例发生了故障，锁变量仍然是存在的，客户端还是可以完成锁操作。Redlock算法是实现高可靠分布式锁的一种有效解决方案，可以在实际开发中使用。

设计理念

该方案也是基于(set加锁、Lua脚本解锁）进行改良的，所以redis之父antirez只描述了差异的地方，大致方案如下：假设我们有N个Redis主节点，例如N= 5这些节点是完全独立的，我们不使用复制或任何其他隐式协调系统，为了取到锁客户端执行以下操作：
1. 获取当前时间，以毫秒为单位;
2. 依次尝试从5个实例，使用相同的 key和随机值（例如 UUID）获取锁。当向Redis 请求获取锁时，客户端应该设置一个超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为10秒，则超时时间应该在5-50毫秒之间。这样可以防止客户端在试图与一个宕机的 Redis 节点对话时长时间处于阻塞状态。如果一个实例不可用，客户端应该尽快尝试去另外一个Redis实例请求获取锁;
3. 客户端通过当前时间减去步骤1记录的时间来计算获取锁使用的时间。当且仅当从大多数(N/2+1，这里是3个节点)的Redis节点都取到锁，并且获取锁使用的时间小于锁失效时间时，锁才算获取成功;
4. 如果取到了锁，其真正有效时间等于初始有效时间减去获取锁所使用的时间（步骤3计算的结果）。
5. 如果由于某些原因未能获得锁（无法在至少N/2＋1个Redis实例获取锁、或获取锁的时间超过了有效时间)，客户端应该在所有的Redis 实例上进行解锁（即便某些Redis实例根本就没有加锁成功，防止某些节点获取到锁但是客户端没有得到响应而导致接下来的一段时间不能被重新获取锁）。
  
  该方案为了解决数据不一致的问题，直接舍弃了异步复制只使用master节点，同时由于舍弃了slave，为了保证可用性，引入了N个节点
  
  客户端只有在满足下面的这两个条件时，才能认为是加锁成功。
  
  条件1:客户端从超过半数（大于等于N/2+1）的Redis实例上成功获取到了锁;
  
  条件2:客户端获取锁的总耗时没有超过锁的有效时间。
解决方案
为什么是奇数：N = 2X + 1 （N是最终部署机器数，X是容错机器数）

Redisson实现

Redisson 就是 Redlock算法的实现

Redisson是Java的Redis客户端之一，提供了一些API方便操作Redis

Redisson之官网：https://redisson.org

Redisson之github：https://github.com/redisson/redisson/wiki

Redisson之解决分布式锁：https://github.com/redisson/redisson/wiki/8.-distributed-locks-and-synchronizers

POM

Xml

<!--redisson-->
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.13.4</version>
</dependency>

RedisConfig

Java

import org.redisson.Redisson;
import org.redisson.config.Config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.StringRedisSerializer;

/**
 * @author 晓风残月Lx
 * @date 2023/4/1 10:31
 */
@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, Object> redisTemplate(LettuceConnectionFactory lettuceConnectionFactory)
    {
        RedisTemplate<String,Object> redisTemplate = new RedisTemplate<>();
        redisTemplate.setConnectionFactory(lettuceConnectionFactory);
        //设置key序列化方式string
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        //设置value的序列化方式json
        redisTemplate.setValueSerializer(new GenericJackson2JsonRedisSerializer());

        redisTemplate.setHashKeySerializer(new StringRedisSerializer());
        redisTemplate.setHashValueSerializer(new GenericJackson2JsonRedisSerializer());

        redisTemplate.afterPropertiesSet();

        return redisTemplate;
    }

//    v 8.0 引入 redisson
    @Bean
    public Redisson redisson() {
        Config config = new Config();
        config.useSingleServer()
                .setAddress("redis://192.168.238.111:6379")
                .setDatabase(0)
                .setPassword("123456");
        return (Redisson) Redisson.create(config);
    }
}

InventoryController

Java

import com.xfcy.service.InventoryService;
import io.swagger.annotations.Api;
import io.swagger.annotations.ApiOperation;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

/**
 * @author 晓风残月Lx
 * @date 2023/4/1 10:32
 */
@RestController
@Api(tags = "redis分布式锁测试")
public class InvetoryController {

    @Autowired
    private InventoryService inventoryService;

    @ApiOperation("扣减库存sale，一次卖一个")
    @GetMapping(value = "/inventory/sale")
    public String sale()
    {
        return inventoryService.sale();
    }


    @ApiOperation("扣减库存saleByRedisson，一次卖一个")
    @GetMapping(value = "/inventory/saleByRedisson")
    public String saleByRedisson()
    {
        return inventoryService.saleByRedisson();
    }
}

InventoryService

Java

    /**
     * v 9.0    引入Redisson对应的官网推荐RedLock算法实现
     *
     * @return
     */
    @Autowired
    private Redisson redisson;

    public String saleByRedisson() {
        String retMessage = "";

        RLock redissonLock = redisson.getLock("xfcyRedisLock");
        redissonLock.lock();
        try {
            //1 查询库存信息
            String result = stringRedisTemplate.opsForValue().get("inventory001");
            //2 判断库存是否足够
            Integer inventoryNumber = result == null ? 0 : Integer.parseInt(result);
            //3 扣减库存
            if (inventoryNumber > 0) {
                stringRedisTemplate.opsForValue().set("inventory001", String.valueOf(--inventoryNumber));
                retMessage = "成功卖出一个商品，库存剩余: " + inventoryNumber;

            } else {
                retMessage = "商品卖完了，o(╥﹏╥)o";
            }
            System.out.println(retMessage);
        } finally {
            // 改进点，只能删除属于自己的 key，不能删除别人的
            if (redissonLock.isLocked() && redissonLock.isHeldByCurrentThread()){
                redissonLock.unlock();
            }
        }
        return retMessage + "\t" + "服务端口号：" + port;
    }

RedLock源码分析

https://github.com/Romantic-Lei/Learning-in-practice/blob/master/Redis/12.Redis高阶篇/9.Redlock算法和底层源码分析/4.Redisson源码解析.md

多机案例

理论参考来源

Redis之父提出了Redlock算法解决这个问题

这个锁的算法实现了多redis实例的情况，相对于单redis节点来说，优点在于防止了单节点故障造成整个服务停止运行的情况且在多节点中锁的设计，及多节点同时崩溃等各种意处情况有自己独特的设计方法。

Redisson 分布式锁支持 MultiLock 机制可以将多个锁合并为一个大锁，对一个大锁进行统一的申请加锁以及释放锁。

最低保证分布式锁的有效性及安全性的要求如下:

1.互斥：任何时刻只能有一个client获取锁

2.释放死锁：即使锁定资源的服务崩溃或者分区，仍然能释放锁

3.容错性：只要多数redis节点(一半以上) 在使用，client就可以获取和释放锁

网上讲的基于故障转移实现的redis主从无法真正实现Redlock：

因为redis在进行主从复制时是异步完成的，比如在clientA获取锁后，主redis复制数据到从redis过程中崩溃了，导致没有复制到从redis中，然后从redis选举出一个升级为主redis，造成新的主redis没有clientA 设置的锁，这时clientB尝试获取锁，并且能够成功获取锁，导致互斥失效；

代码参考来源

https://github.com/redisson/redisson/wiki/8.-distributed-locks-and-synchronizers

最新推荐使用MultiLock多重锁，详见官网案例

使用Redisson分布式锁，需要单独的Redis master多节点，不能是哨兵模式的master或者集群模式的master；

加入现在有三台Redis 服务器，并且是master：

TEXT

RLock lock1 = redisson1.getLock("lock1");
RLock lock2 = redisson2.getLock("lock2");
RLock lock3 = redisson3.getLock("lock3");

RLock multiLock = anyRedisson.getMultiLock(lock1, lock2, lock3);

// traditional lock method
multiLock.lock();

这样三台Redis都会有加锁信息，当其中某一台宕机后，不会影响整个加锁信息，其他客户端过来依旧会拿到锁信息，不能成功获取到锁(可重入锁除外)，次数如果宕机服务器重新上线，它会自动同步其他Redis上的锁信息，并且同步锁过期时间

13.Redis缓存淘汰策略

总结

生产上你们redis内存设置多少

如何配置、修改redis的内存大小

如果内存满了怎么办

redis清理内存的方式？定期删除和惰性删除了解过吗？

redis缓存淘汰策略有哪些？分别是什么？用过那个？

redis的LRU了解过吗？请手写LRU

LRU和LFU算法的区别是什么？

LRU means Least Recently Used 最近最少使用

LFU means Least Frequently Used 最近最不常用

查看redis内存及修改

redis默认内存是多少？在哪查看？如何设置修改？

查看Redis最大占用内存

打开redis配置文件，设置maxmemory参数，maxmemory是bytes字节类型，注意类型转换。

通过命令查看默认的内存大小：config get maxmemory

默认内存大小为0吗？那我们之前的数据是怎么保存进去的？
redis默认内存多少可用？

如果不设置最大内存或者设置最大内存大小为0，在64位操作系统下不限制内存大小，在32位操作系统下最多使用3GB内存

注意：在64bit系统下，maxmemory设置为0表示不限制redis内存使用
一般生产上你如何配置

一般推荐Redis设置内存为最大物理内存的3/4
如何修改redis内存设置

通过修改文件配置

通过命令修改，但是redis重启后会失效

什么命令查看redis内存使用情况

info memory

config get maxmemory

内存打满了，超出了设置的最大值会怎么样？

结论

设置了maxmemory的选项，假如redis内存使用达到了上限，没有加上过期时间就会导致数据写满maxmemory，为了避免类似情况，需要使用内存淘汰策略

redis过期键的删除策略

如果一个键是过期的，那它到了过期时间之后是不是马上就从内存中被删除了呢？

如果不是，那过期后到底什么时候被删除呢？是什么操作？

redis三种删除策略

立即删除

立即删除能保证内存中数据的最大新鲜度，因为它保证过期键值会在过期后马上被删除，其所占用的内存也会随之释放。但是立即删除对cpu是最不友好的。因为删除操作会占用cpu的时间，如果刚好碰上了cpu很忙的时候，比如正在做交集或排序等计算的时候，就会给cpu造成额外的压力，让CPU心累，时时需要删除，忙死。

这会产生大量的性能消耗，同时也会影响数据的读取操作

**总结：**对CPU不友好，用处理器性能换取存储空间（拿时间换空间）
定期删除
- 每隔一段时间执行一次删除过期键操作并通过限制删除操作执行时长和频率来减少删除操作对CPU时间的影响。
- 定期抽样key，判断是否过期
- 容易出现漏网之鱼
定期删除策略的难点是确定删除操作执行的时长和频率：如果删除操作执行得太频繁或者执行的时间太长，定期删除策略就会退化成立即删除策略，以至于将CPU时间过多地消耗在删除过期键上面。如果删除操作执行得太少，或者执行的时间太短，定期删除策略又会和惰性删除束略一样，出现浪费内存的情况。因此，如果采用定期删除策略的话，服务器必须根据情况，合理地设置删除操作的执行时长和执行频率。
惰性删除

数据到达过期时间，不做处理。等下次访问该数据时，如果未过期，返回数据 ;发现已过期，删除，返回不存在。

惰性删除策略的缺点是，它对内存是最不友好的。

如果一个键已经过期，而这个键又仍然保留在redis中，那么只要这个过期键不被访问，它所占用的内存就不会释放。在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些过期键又恰好没有被访问到的话，那么它们也许永远也不会被删除(除非用户手动执行FLUSHDB)，我们甚至可以将这种情况看作是一种内存泄漏 - 无用的垃圾数据占用了大量的内存。而服务器却不会自己去释放它们，这对于运行状态非常依赖于内存的Redis服务器来说,肯定不是一个好消息

**总结：**对内存不友好，用存储空间换取处理器性能（拿空间换时间），开启惰性删除淘汰，lazyfree-lazy-eviction=yes

缓存淘汰策略

redis配置文件

在MEMORY MANAGEMENT中

LRU：最近最少使用页面置换算法，淘汰最长时间未被使用的页面，看页面最后一次被使用到发生调度的时间长短，首先淘汰最长时间未被使用的页面。（是在一段时间内的未使用页面，重点在时间段上）

LFU：最近最不常用页面置换算法，淘汰一定时期内被访问次数最少的页面，看一定时间段内页面被使用的频率，淘汰一定时期内被访问次数最少的页（是在一段时间内的未使用页面，重点在使用上）

淘汰策略有哪些(Redis7版本)

noeviction：不会驱逐任何key，表示即使内存达到上限也不进行置换，所有能引起内存增加的命令都会返回error
allkeys-lru：对所有key使用LRU算法进行删除，优先删除掉最近最不经常使用的key，用以保存新数据
volatile-lru：对所有设置了过期时间的key使用LRU算法进行删除
allkeys-random：对所有key随机删除
volatile-random：对所有设置了过期时间的key随机删除
volatile-ttl：删除马上要过期的key
allkeys-lfu：对所有key使用LFU算法进行删除
volatile-lfu：对所有设置了过期时间的key使用LFU算法进行删除

对上面淘汰策略的总结

2个维度：过期键中筛选；所有键中筛选

4个方面：LRU LFU random ttl

8个选项

性能配置建议

避免存储 bigkey
开启惰性淘汰 lazyfree-lazy-eviction=yes

14.经典的5大数据类型源码

暂时不学

https://github.com/Romantic-Lei/Learning-in-practice/blob/master/Redis/12.Redis高阶篇/11.Redis经典五大类型源码及底层实现/images/49.zset(redis6)1.png

15.epoll和IO多路复原

基本概念：

**BIO （Blocking I/O）：同步阻塞 I/O 模式。**来一个进一个，占用式。

**NIO （New I/O）：同步非阻塞模式。**来一个进一个，非占用式，轮询式。

**AIO （Asynchronous I/O）：异步非阻塞 I/O 模型。**来多个进多个，谁好了就叫我

什么是IO多路复原呢？

I/O

网络 I/O

多路

多个客户端连接（连接就是套接字描述符，即socket 或者 channel），指的是多条 TCP 连接

复用

用一个进程来处理多条的连接，使用单进程就能实现同时处理多个客户端的连接

总结

实现了用一个进程来处理大量的用户连接 IO多路复用类似一个规范和接口，落地实现是由 linux系统的 select -> poll -> epoll

在上面的4.多线程和单线程已经提及过了

Redis如何处理多并发客户端连接，为什么单线程，为什么快

Redis 利用 epoll来实现 IO多路复用，将连接信息和事件都放到队列中，一次放到文件事件分派器，事件分派器将事件分发给事件处理器

redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以I/O操作在一股情况下往往不能直接返回，这会导致某一文件的I/O阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现

所谓 I/O 多路复用机制，就是说通过一种机制，可以监视多个描述符，一旦某个描述符就绪(一般是读就绪或写就绪)，能够通知程序进行相应的读写操作。这种机制的使用需要 select、poll 、epoll 来配合。多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。

Redis 服务采用 Reactor 的方式来实现文件事件处理器(每一个网络连接其实都对应一个文件描述符)

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为**文件事件处理器。**它的组成结构为4部分:

多个套接字、
IO多路复用程序.
文件事件分派器、
事件处理器。

因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型

Reactor 模式要求 主线程（I/O 处理单元）只负责监听文件描述符上是否有事件发生，有的话就立即将该事件通知工作线程（逻辑单

元）。除此之外，主线程不做任何其他实质性的工作。 读写数据，接受新的连接，以及处理客户请求均在工作线程中完成。

从Redis6开始，将网络数据读写、请求协议解析通过多个IO线程的来处理，对于真正的命令执行来说，仍然使用单线程操作

Unix网络编程中的五种IO模型

Blocking IO 阻塞IO（BIO）
NoneBlocking IO 非阻塞IO（NIO）
IO multiplexing IO多路复用
signal driven IO 信号驱动IO
asynchronous IO 异步IO（AIO）

异步、同步、阻塞、非阻塞

同步
- 调用者要一直等待调用结果的通知后才能进行后续的执行
异步
- 指被调用方先返回应答让调用者先回去，然后再计算调用结果，计算完最终结果后再通知并返回给调用方
- 异步调用要想获得结果一般通过回调
同步与异步的理解
- 同步、异步的讨论对象是被调用者（服务提供者），重点在于获得调用结果的消息通知方式上
阻塞
- 调用方一直在等待而且别的事情什么都不做，当前线/进程都会被挂起，啥也不干
非阻塞
- 调用在发出去后，调用方先去忙别的事情，不会阻塞当前进/线程，而会立即返回
阻塞与非阻塞的理解
- 阻塞、非阻塞的讨论对象是**调用者（服务请求者），重点在于等消息时候的行为，**调用者是否能干其他事
总结
- 同步阻塞
  - 调用发出后，调用者一直等待调用结果的通知，什么也不干
- 同步非阻塞
  - 调用发出后，会立马收到答复，如果得到的不是完整的资源，调用者会周期循环轮询发送IO请求，直到真正获得调用结果的通知，在此期间调用者可以去做别的
- 异步阻塞
  - 调用不会马上发出，安排一个时间再发起请求，什么也不干，等待调用结果的通知
- 异步非阻塞
  - 调用不会马上发出，安排一个时间再发起请求，当发出请求，可以马上得到答复，如果得到的不是完整的资源，调用者调用者会周期循环轮询发送IO请求，直到真正获得调用结果的通知，在此期间调用者可以去做别的

BIO

BIO单线程

客户端与服务端建立了连接，如果这个连接的客户端迟迟不乏数据，数据就会一直堵塞再 read() 方法上，这样其他客户端也不能进行连接，也就是一次只能处理一个客户端，对客户很不友好

BIO多线程

存在的问题 每来一个客户端，就要开辟一个线程，如果来1万个客户端，那就要开辟1万个线程。在操作系统中用户态不能直接开辟线程，需要调用内核来创建的一个线程，这其中还涉及到用户状态的切换（上下文的切换），十分耗资源。 解决方法 **线程池，**在客户端连接少的情况下可以使用，但是用户量大的清况下，你不知道线程池要设置多大，内存可能不够 NIO（非阻塞式IO）

NIO

在NIO模式中，一切都是非阻塞的：

accept()方法是非阻塞的，如果没有客户端连接，就返回无连接标识

read()方法是非阻塞的，如果read()方法读取不到数据就返回空闲中标识，如果读取到数据时只阻塞read()方法读数据的时间

在NIO模式中，只有一个线程：

当一个客户端与服务端进行连接，这个socket就会加入到一个数组中，隔一段时间遍历一次，看这个socket的read()方法能否读到数据，这样一个线程就能处理多个客户端的连接和读取了

存在的问题

如何用单线程处理大量的链接

非阻塞IO就是请求发出，如果资源没有完成，不断轮询该请求

Redis IO多路复用详解

Redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到事件分派器，事件分派器将事件分发给事件处理器。

在这里插入图片描述

Redis 服务采用 Reactor 的方式来实现文件事件处理器（每一个网络连接其实都对应一个文件描述符）

Reator设计模式

基于 I/O 复用模型：多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。

Reactor 模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor 模式也叫 Dispatcher 模式。即 I/O 多了复用统一监听事件，收到事件后分发(Dispatch 给某进程)，是编写高性能网络服务器的必备技术！

Reactor 模式中有 2 个关键组成：

1）Reactor：Reactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对 IO 事件做出反应。它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人；

2）Handlers：处理程序执行 I/O 事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际办理人。Reactor 通过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操作。

select、poll、epoll 都是 I/O 多路复用的具体的实现

I/O 多路复用的具体的实现select、poll、epoll

select方法

select函数监视的文件描述符分3类，分别是readfds、writefds和exceptfds，将用户传入的数组拷贝到内核空间，调用后select函数会阻塞，直到有描述符就绪（有数据可读、可写、或者有except)或超时(timeout指定等待时间，如果立即返回设为null即可)，函数返回。

当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。

优点

select其实就是把NIO中用户态要遍历的fd数组(我们的每一个socket链接，安装进ArrayList里面的那个)拷贝到了内核态，让内核态来遍历，因为用户态判断socket是否有数据还是要调用内核态的，所有拷贝到内核态后，这样遍历判断的时候就不用一直用户态和内核态频繁切换了。

从代码中可以看出，select系统调用后，返回了一个置位后的&rset，这样用户态只需进行很简单的二进制比较，就能很快知道哪些socket需要read数据，有效提高了效率

缺点

bitmap默认大小为1024，虽然可以调整但还是有限度的
rset每次循环都必须重新置位为0，不可重复使用
尽管将rset从用户态拷贝到内核态由内核态判断是否有数据，但是还是有拷贝的开销
当有数据时select就会返回，但是select函数并不知道哪个文件描述符有数据了，后面还需要再次对文件描述符数组进行遍历。效率比较低

缺点详细解释：

1、bitmap最大1024位，一个进程最多只能处理1024个客户端

2、&rset不可重用，每次socket有数据就相应的位会被置位

3、文件描述符数组拷贝到了内核态(只不过无系统调用切换上下文的开销。(内核层可优化为异步事件通知))，仍然有开销。select调用需要传入fd数组，需要拷贝一份到内核，高并发场景下这样的拷贝消耗的资源是惊人的。(可优化为不复制)

4、select并没有通知用户态哪一个socket有数据，仍然需要O(n)的遍历。select仅仅返回可读文件描述符的个数，具体哪个可读还是要用户自己遍历。(可优化为只返回给用户就绪的文件描述符，无需用户做无效的遍历)

select小总结

select方式，既做到了一个线程处理多个客户端连接(文件描述符），又减少了系统调用的开销(多个文件描述符只有一次select的系统调用＋N次就绪状态的文件描述符的read系统调用

poll方法

优点

1、poll使用pollfd数组来代替select中的bitmap，数组没有1024的限制，可以一次管理更多的client。它和 select的主要区别就是，去掉了select只能监听1024个文件描述符的限制。

2、当pollfds数组中有事件发生，相应的revents置位为1，遍历的时候又置位回零，实现了pollfd数组的重用

问题

poll解决了select缺点中的前两条，其本质原理还是select的方法，还存在select中原来的问题

1、pollfds数组拷贝到了内核态，仍然有开销

2、poll并没有通知用户态哪一个socket有数据，仍然需要O(n)的遍历

epoll方法

执行流程（epoll非阻塞的）

当有数据的时候，会把相应的文件描述符 “置位”，但是epool没有revent标志为，所以并不是真正的置位。这时候会把有数据的文件描述符放到队首。
epoll会返回有数据的文件描述符的个数
根据返回的个数，读取前N个文件描述符即可
读取、处理

结论

多路复用快的原因在于，操作系统提供了这样的系统调用，使得原来的while循环里多次系统调用，变成了一次系统调用＋内核层遍历这些文件描述符。

epoll是现在最先进的IO多路复用器，Redis、Nginx，linux中的Java NIO都使用的是epoll。

这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。

1、一个socket的生命周期中只有一次从用户态拷贝到内核态的过程，开销小

2、使用event事件通知机制，每次socket中有数据会主动通知内核，并加入到就绪链表中，不需要遍历所有的socket

在多路复用IO模型中，会有一个内核线程不断地去轮询多个socket的状态，只有当真正读写事件发送时，才真正调用实际的IO读写操作。因为在多路复用IO模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有真正有读写事件进行时，才会使用IO资源，所以它大大减少了资源占用。多路I/O复用模型是利用select、poll、epoll可以同时监察多个流的I/0事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有I/O事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。采用多路I/О复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗)，且Redis在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈

三个方法对比

PS：尽量不要用 windows 的redis，只能调用select()方法，时间复杂度是O(n), Linux是用epoll()，时间复杂度O(1)，所以 Linux 的 redis 会比 windows 的快！！

I/O模型总结

在这里插入图片描述

迷你版微信抢红包案例

需求分析

各种节假日，发红包+抢红包，不说了，100%高并发业务要求，不能用mysql来做
一个总的大红包，会有可能拆分成多个小红包，总金额 = 分金额1+分金额2+分金额3......分金额N
每个人只能抢一次，你需要有记录，比如100块钱，被拆分成10个红包发出去，总计有10个红包，抢一个少一个，总数显示(10/6)直到完，需要记录哪些人抢到了红包，重复抢作弊不可以。
有可能还需要你计时，完整抢完，从发出到全部over，耗时多少?
红包过期，或者群主人品差，没人抢红包，原封不动退回。
红包过期，剩余金额可能需要回退到发红包主账户下。

由于是高并发不能用mysql来做，只能用redis，那需要要redis的什么数据类型?

架构设计

难点：

1 拆分算法如何红包其实就是金额，拆分算法如何 ?给你100块，分成10个小红包(金额有可能小概率相同，有2个红包都是2.58)如何拆分随机金额设定每个红包里面安装多少钱?

2 次数限制每个人只能抢一次，次数限制

3 原子性3 每抢走一个红包就减少一个(类似减库存)，那这个就需要保证库存的-----------------------原子性，但是还需要不加锁实现，因为大量并发上来后，全部都卡死的话，用户使用效果不佳，并且容易导致服务器被压垮

你认为存在redis什么数据类型里面? set ? hash? list?

关键点

发红包

抢红包

抢，不加锁且原子性，还能支持高并发

没人一次且有抢红包记录

记红包

记录每个人抢了多少

拆红包

拆红包算法：

所有人抢到金额之和等于红包金额，不能超过，也不能少于。
每个人至少抢到一分钱
要保证所有人抢到金额的几率相等

结论：

抢红包业务通用算法：二倍均值法

剩余红包金额为M，剩余人数为N，那么有如下公式:

每次抢到的金额 = 随机区间 (0，(剩余红包金额M ÷ 剩余人数N )X 2)

这个公式，保证了每次随机金额的平均值是相等的，不会因为抢红包的先后顺序而造成不公平。举个栗子: 假设有10个人，红包总额100元。第1次: 100 ÷ 10 X 2 = 20,所以第一个人的随机范围是 (0，20 )，平均可以抢到10元。假设第一个人随机到10元，那么剩余金额是100-10 = 90

第2次: 909 X2 = 20,所以第二个人的随机范围同样是 (0，20 )，平均可以抢到10元。假设第二个人随机到10元，那么剩余金额是90-10 = 80 元。

第3次: 80-8 X2 = 20,所以第三个人的随机范围同样是 (0，20 )，平均可以抢到10元。以此类推，每一次随机范围的均值是相等的。

编码实现

RedPackageController

Java

import com.xfcy.service.RedPackageService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

/**
 *  模拟抢红包，模拟整数的
 * @author 晓风残月Lx
 * @date 2023/4/5 15:53
 */
@RestController
public class RedPackageController {

    public static final String RED_PACKAGE_KEY = "redpackage:";
    public static final String RED_PACKAGE_CONSUME_KEY = "redpackage:consume";

    @Autowired
    private RedPackageService redPackageService;

    @RequestMapping("/send")
    public String sendRedPackage(int totalMoney, int redPackageNumber) {
        String str = redPackageService.sendRedPackage(totalMoney, redPackageNumber);
        return str;
    }

    @RequestMapping("/rob")
    public String robRedPackage(String redPackageKey, String userId) {
        String str = redPackageService.robRedPackage(redPackageKey, userId);
        return str;
    }
}

RedPackageService

Java

import cn.hutool.core.util.IdUtil;
import com.google.common.primitives.Ints;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;

import java.util.Arrays;
import java.util.Random;
import java.util.concurrent.TimeUnit;

/**
 * 模拟抢红包
 *
 * @author 晓风残月Lx
 * @date 2023/4/5 16:00
 */
@Service
public class RedPackageService {

    @Autowired
    private RedisTemplate redisTemplate;

    public static final String RED_PACKAGE_KEY = "redpackage:";
    public static final String RED_PACKAGE_CONSUME_KEY = "redpackage:consume";

    /**
     * 拆红包的算法 --->  二倍均值算法
     *
     * @param totalMoney
     * @param redpackageNumber
     * @return
     */
    public Integer[] splitRedPackageAlgorithm(int totalMoney, int redpackageNumber) {
        Integer[] redPackageNums = new Integer[redpackageNumber];
        // 已经被抢夺的红包金额
        int useMoney = 0;

        for (int i = 0; i < redpackageNumber; i++) {
            if (i == redpackageNumber - 1) {
                redPackageNums[i] = totalMoney - useMoney;
            } else {
                // 二倍均值算法，每次拆分后塞进子红包的金额
                // 金额 = 随机取件（0，（剩余红包金额 / 未被抢的剩余红包数 N ）* 2 ）
                int avgMoney = ((totalMoney - useMoney) / (redpackageNumber - i)) * 2;
                redPackageNums[i] = 1 + new Random().nextInt(avgMoney - 1);
            }
            useMoney = useMoney + redPackageNums[i];
        }
        return redPackageNums;
    }

    /**
     * 发红包
     *
     * @param totalMoney
     * @param redPackageNumber
     */
    public String sendRedPackage(int totalMoney, int redPackageNumber) {
        // 1. 拆红包，将总金额totalMoney拆分成 redpackageNumber 个子红包
        Integer[] splitRedPackages = splitRedPackageAlgorithm(totalMoney, redPackageNumber);     // 拆分红包算法（二倍均值算法）通过后获得的多个子红包数组

        // 2. 发红包并保存进 list 结构 并且设置过期时间
        String key = RED_PACKAGE_KEY + IdUtil.simpleUUID();
        redisTemplate.opsForList().leftPushAll(key, splitRedPackages);
        redisTemplate.expire(key, 1, TimeUnit.DAYS);

        // 3.发红包ok，返回前台显示
        return key + "\t" + Ints.asList(Arrays.stream(splitRedPackages).mapToInt(Integer::valueOf).toArray());
    }

    public String robRedPackage(String redPackageKey, String userId) {
        // 1.验证某个用户是否抢过红包，不可以多抢
        Object redPackage = redisTemplate.opsForHash().get(RED_PACKAGE_CONSUME_KEY + redPackageKey, userId);
        // 2.没有抢过红包可以抢，如果抢过返回 -2 表示抢过
        if (null == redPackage) {
            // 2.1 从 list 结构中出队一个作为抢的红包
            Object partRedPackage = redisTemplate.opsForList().leftPop(RED_PACKAGE_KEY + redPackageKey);
            if (partRedPackage != null) {
                // 2.2 抢到红包后 需要记录到hash结构中 记录每人抢到的红包
                redisTemplate.opsForHash().put(RED_PACKAGE_CONSUME_KEY + redPackageKey, userId, partRedPackage);
                System.out.println("用户" + userId + "\t 抢到了多少钱的红包：" + partRedPackage);
                // TODO  后续异步进mysql或者MQ进一步做统计处理，每一年你发出多少红包，抢到了多少红包
                return String.valueOf(partRedPackage);
            }
            // 2. 抢完了
            return "errorCode: -1, 红包抢完了";
        } else {
            // 3. 抢过了红包
            int myRedPackage = (int) redisTemplate.opsForHash().get(RED_PACKAGE_CONSUME_KEY + redPackageKey, userId);
            return "errorCode: -2,  message:" + userId + "\t  你已经抢过了红包，不能在抢了,你抢的金额是" + myRedPackage;
        }

    }
}

批量删除（扩展）

“***” 代表 key前缀

Bash

redis-cli keys "***" | xargs redis-cli del

12.基于Redis的互联网API幂等设计在互联网API接口中，由于网络超时、手动刷新等经常导致客户端重复提交数据到服务端，这就要求在设计API接口时做好幂等控制。尤其是在面向微服务架构的系统中，系统间的调用非常频繁，如果不做好幂等性（一致性）设置，轻则会导致脏数据入库，重则导致资损。本例基于Redis实现一个幂等控制框架。

详见这篇博文《基于redis的API接口幂等设计》

13.基于redis的分布式锁详见这篇博文:https://blog.csdn.net/hellozpc/article/details/82953590

redis集群增减机器的一致性hash算法 https://www.cnblogs.com/myseries/p/10956835.html

redis集群架构 https://www.zhihu.com/question/293357668

TEXT

                        版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

原文链接：https://blog.csdn.net/hellozpc/article/details/81267030

JavaSE 系列笔记