Redis高级
目录
把原来的redis.conf配置分件分贝复制一件到这三个目录中
现在这三个实例并没有主从关系，所以我们需要通过slaveof命令设置主从关系
Redis事务
redis的事务是弱事务
redis事务是先把所有的操作加入一个队列中，然后依次执行队列中的操作
开启事务：
multi各种操作..
执行事务
exec
不执行事务
discard
示例
127.0.0.1:6379> multi #开启事务
OK
127.0.0.1:6379> set name hhh
QUEUED #显示加入操作队列
127.0.0.1:6379> set age 18
QUEUED
127.0.0.1:6379> exec #执行事务
1) OK
2) OK
语法错误
只要事务中的一个队列中某一个操作语法错误，整个事务队列中的操作都不会运行
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name hhh
QUEUED
127.0.0.1:6379> set age #语法错误
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> set addr sh
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors. #整个事务都不会操作
执行错误
事务中的队列某一个操作语法正确，但是执行错误，会继续执行队列中的操作，所以redis的事务是不会回滚的
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name hhh
QUEUED
127.0.0.1:6379> lpush name a b c #语法正确，但是执行错误，因为name已经是string,但是这是list类型的操作
QUEUED
127.0.0.1:6379> set name abc #会继续执行后面的操作
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK
127.0.0.1:6379> get name
"abc"
Redis持久化
RDB持久化
RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。
- 执行save命令
- 执行bgsave命令
- Redis停机时
- 触发RDB条件时
1）save命令
执行save命令时，直接触发RDB快照保存
save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞，直到RDB快照文件全部保存成功。只有在数据迁移时可能用到。
2）bgsave命令
下面的命令可以异步执行RDB：
这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。
3）停机时
Redis停机时会执行一次save命令，实现RDB持久化。
注意：意外宕机不会执行save命令
4）conf文件触发RDB条件
Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：
# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1 900秒执行一次快照
save 300 10
save 60 10000 RDB的其它配置也可以在redis.conf文件中设置：
# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes
# RDB文件名称
dbfilename dump.rdb
# 文件保存的路径目录
dir ./ RDB原理
bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。
fork采用的是copy-on-write技术：
- 当主进程执行读操作时，访问共享内存；
- 当主进程执行写操作时，则会拷贝一份数据，执行写操作。
小结
RDB方式bgsave的基本流程？
- fork主进程得到一个子进程，共享内存空间
- 子进程读取内存数据并写入新的RDB文件
- 用新RDB文件替换旧的RDB文件
RDB会在什么时候执行？save 60 1000代表什么含义？
- 默认是服务停止时
- 代表60秒内至少执行1000次修改则触发RDB
RDB的缺点？
- RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险，就是redis意外宕机后，不会执行RDB操作，会丢失最后一次快照后所有修改的数据
- fork子进程、压缩、写出RDB文件都比较耗时
- bgsave执行每次执行都会阻塞redis服务进行创建子线程，频繁执行会影响系统吞吐量
AOF持久化
AOF原理
AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。
AOF配置
AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"AOF的命令记录的频率也可以通过redis.conf文件来配：
# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no三种策略对比：
AOF文件重写
因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。
如图，AOF原本有三个命令，但是set num 123 和 set num 666都是对num的操作，第二次会覆盖第一次的值，因此第一个命令记录下来没有意义。
所以重写命令后，AOF文件内容就是：mset name jack num 666
Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：
# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb RDB与AOF对比
1.RDB默认开启，AOF需要手动开启
2.RDB的性能优于AOF
3.AOF的安全性高于RDB
4.AOF优先级高于RDB
5.RDB存储某个时刻的数据快照，AOF存储写命令
6.RDB在配置触发状态会丢失最后一次快照以后更改的所有数据，AOF默认使用everysec,每一秒保存一次，最多丢失两秒内的数据
1.如果只追求高性能，不关注数据安全性，则可以关闭RDB和AOF,如redis宕机重启，直接从数据源恢复数据
2.如需较高性能且关注数据安全性，则开启RDB,并自定义触发快照规则
3.如更关注数据的安全性，就开启AOF
4.可以同时开启AOF,RDB，RDB用于数据的迁移
Redis主从复制架构
单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。
我们可以使用主从复制架构，创建一个master主节点，负责写数据到从节点，创建多个slave从节点，负责读取数据返回。
搭建主从复制架构
这里我们会在同一台虚拟机中开启3个redis实例，模拟主从集群，信息如下：
| IP | PORT | 角色 |
|---|---|---|
| 192.168.150.101 | 7001 | master |
| 192.168.150.101 | 7002 | slave |
| 192.168.150.101 | 7003 | slave |
在redis目录创建三个目录
把原来的redis.conf配置分件分贝复制一件到这三个目录中
cp bin/redis.conf 7001
cp bin/redis.conf 7002
cp bin/redis.conf 7003修改配置文件
第一处：端口
第二处：文件输出位置
启动三个redis实例
./bin/redis-server 7001/redis.conf
./bin/redis-server 7002/redis.conf
./bin/redis-server 7003/redis.conf现在这三个实例并没有主从关系，所以我们需要通过slaveof命令设置主从关系
有临时和永久两种模式：
-
修改配置文件（永久生效）
- 在redis.conf中添加一行配置：
slaveof <masterip> <masterport>
- 在redis.conf中添加一行配置：
-
使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：
slaveof <masterip> <masterport>
slaveof 192.168.230.130 7001如何查看主从关系，随便连接一个服务端
./bin/redis-cli -p 7001使用
info replication
可以看到7001端口的redis为主节点，有两个从节点，分别是7002，7003
升级为主节点：
slaveof no one
测试
执行下列操作以测试：
-
利用redis-cli连接7001，执行
set num 123 -
利用redis-cli连接7002，执行
get num，再执行set num 666 -
利用redis-cli连接7003，执行
get num，再执行set num 888
可以发现，只有在7001这个master节点上可以执行写操作，7002和7003这两个slave节点只能执行读操作。
主从数据同步原理
全量同步
主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点，流程：
这里有一个问题，master如何得知salve是第一次来连接呢？？
有几个概念，可以作为判断依据：
- Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
- offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。
因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据。
因为slave原本也是一个master，有自己的replid和offset，当第一次变成slave，与master建立连接时，发送的replid和offset是自己的replid和offset。
master判断发现slave发送来的replid与自己的不一致，说明这是一个全新的slave，就知道要做全量同步了。
master会将自己的replid和offset都发送给这个slave，slave保存这些信息。以后slave的replid就与master一致了。
因此，master判断一个节点是否是第一次同步的依据，就是看replid是否一致。
完整流程描述：
- slave节点请求增量同步
- master节点判断replid，发现不一致，这是一个刚连接的从节点,拒绝增量同步，需要全量同步
- master将完整内存数据生成RDB，发送RDB到slave
- slave清空本地数据，加载master的RDB
- master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
- slave执行接收到的命令，保持与master之间的同步
增量同步
全量同步需要先做RDB，然后将RDB文件通过网络传输个slave，成本太高了。因此除了第一次做全量同步，其它大多数时候slave与master都是做增量同步。
什么是增量同步？就是只更新slave与master存在差异的部分数据。如图：
那么master怎么知道slave与自己的数据差异在哪里呢?
repl_backlog原理
master怎么知道slave与自己的数据差异在哪里呢?
这就要说到全量同步时的repl_baklog文件了。
这个文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。
repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset：
slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。
随着不断有数据写入，master的offset逐渐变大，slave也不断的拷贝，追赶master的offset：
但是，如果slave出现网络阻塞，导致master的offset远远超过了slave的offset，并且完全覆盖了slaveof的offset
棕色框中的红色部分，就是尚未同步，但是却已经被覆盖的数据。此时如果slave恢复，需要同步，却发现自己的offset都没有了，无法完成增量同步了。只能做全量同步。
主从同步优化
主从同步可以保证主从数据的一致性，非常重要。
可以从以下几个方面来优化Redis主从就集群：
- 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
- Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
- 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
- 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力
小结
简述全量同步和增量同步区别？
- 全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
- 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave
什么时候执行全量同步？
- slave节点第一次连接master节点时
- slave节点断开时间太久，repl_baklog中的offset已经被覆盖时
什么时候执行增量同步？
- slave节点断开又恢复，并且在repl_baklog中能找到offset时
缺点：
如果主节点宕机，我们需要手动选择一个从节点作为主节点
比如7001宕机，我们需要连接7002客户端，执行
slaveof no one
并连接7003客户端,把7002作为主节点
slaveof 192.168.230.100 7002
如果此时7001恢复，也要把7001作为7002的从节点
Redis哨兵
Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。
搭建三个哨兵节点
哨兵节点也是redis，只不过不存取数据，发挥监控作用
在redis目录下创建三个目录
创建sentinel.conf配置文件
port 27001
bind 0.0.0.0 #不限制ip
daemonize yes #后台启动
sentinel announce-ip 192.168.230.100
sentinel monitor mymaster 192.168.230.100 7001 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
dir "/usr/local/soft/redis/s1"
解读：
port 27001：是当前sentinel实例的端口sentinel monitor mymaster 192.168.150.101 7001 2：指定主节点信息mymaster：主节点名称，自定义，任意写192.168.150.101 7001：主节点的ip和端口2：选举master时的quorum值，要等于这个值才可以成为新的主节点
-
sentinel down-after-milliseconds mymaster 5000这条指令设置了Redis Sentinel认为主节点mymaster不可用的超时时间。down-after-milliseconds参数后面跟的是主节点的名称（在这个例子中是mymaster）和超时时间（以毫秒为单位）。在这里，如果Sentinel在5000毫秒（即5秒）内没有从mymaster接收到有效的响应，它就会认为这个主节点已经宕机。 -
sentinel failover-timeout mymaster 60000这条指令设置了Redis Sentinel执行故障转移操作的超时时间。failover-timeout参数后面跟的是主节点的名称和超时时间（以毫秒为单位）。在这里，Sentinel在尝试进行故障转移时，如果在60000毫秒（即60秒）内没有完成故障转移，就会认为故障转移操作超时。就会重新进行故障转移，直到成功
然后将s1/sentinel.conf文件拷贝到s2、s3两个目录中
cp s1/sentinel.conf s2
cp s1/sentinel.conf s3然后分别修改端口号为27002，27003
启动三个哨兵节点
--sentinel代表这是一个sentinel节点
bin/redis-server s1/sentinel.conf --sentinel
bin/redis-server s2/sentinel.conf --sentinel
bin/redis-server s3/sentinel.conf --sentinel整个哨兵节点已经在监控一主两从节点，mymaster代表主节点
测试：关闭7001redis主节点
7002自动成为主节点，7003也成为7002的从节点
重启7001,自动成为7002的从节点
哨兵原理
哨兵的作用如下：
- 监控：Sentinel 会不断检查您的master和slave是否按预期工作
- 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
- 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端
集群监控原理
Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：
•主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
•客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半+1。
所以哨兵节点数量最好为单数
集群故障恢复原理
一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：
- 首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
- 然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
- 如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
- 最后是判断slave节点的运行id大小，越小优先级越高。
当选出一个新的master后，该如何实现切换呢？
流程如下：
- sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master
- sentinel给所有其它slave发送slaveof 192.168.150.101 7002 命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
- 最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点
小结
Sentinel的三个作用是什么？
- 监控
- 故障转移
- 通知
Sentinel如何判断一个redis实例是否健康？
- 每隔1秒发送一次ping命令，如果超过一定时间没有相向则认为是主观下线
- 如果大多数sentinel都认为实例主观下线，则判定服务下线
故障转移步骤有哪些？
- 首先选定一个slave作为新的master，执行slaveof no one
- 然后让所有节点都执行slaveof 新master
- 修改故障节点配置，添加slaveof 新master
Redis分片集群
搭建分片集群
主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：
-
海量数据存储问题（从节点太少）
-
高并发写的问题（只有一个主节点执行写操作）
使用分片集群可以解决上述问题，如图:
分片集群特征：
-
集群中有多个master，每个master保存不同数据
-
每个master都可以有多个slave节点
-
master之间通过ping监测彼此健康状态
-
客户端请求可以访问集群任意节点，最终都会被转发到正确节点
这里我们会在同一台虚拟机中开启6个redis实例，模拟分片集群，信息如下：
| IP | PORT | 角色 |
|---|---|---|
| 192.168.150.101 | 7001 | master |
| 192.168.150.101 | 7002 | master |
| 192.168.150.101 | 7003 | master |
| 192.168.150.101 | 8001 | slave |
| 192.168.150.101 | 8002 | slave |
| 192.168.150.101 | 8003 | slave |
准备实例和配置
删除之前的7001、7002、7003这几个目录，重新创建出7001、7002、7003、8001、8002、8003目录：
在每一个目录创建一个redis.conf配置文件
port 7001
# 开启集群功能
cluster-enabled yes
# 集群的配置文件名称，不需要我们创建，由redis自己维护
cluster-config-file /tmp/6379/nodes-7001.conf
# 节点心跳失败的超时时间
cluster-node-timeout 5000
# 持久化文件存放目录
dir /tmp/6379
# 绑定地址
bind 0.0.0.0
# 让redis后台运行
daemonize yes
# 注册的实例ip
#replica-announce-ip 192.168.230.100
# 保护模式
protected-mode no
# 数据库数量
databases 1
# 日志
logfile /tmp/6379/run.log
依次启动
创建集群
虽然服务启动了，但是目前每个服务之间都是独立的，没有任何关联。
我们需要执行命令来创建集群，在Redis5.0之前创建集群比较麻烦，5.0之后集群管理命令都集成到了redis-cli中。
redis-cli --cluster create --cluster-replicas 1 192.168.150.101:7001 192.168.150.101:7002 192.168.150.101:7003 192.168.150.101:8001 192.168.150.101:8002 192.168.150.101:8003命令说明：
redis-cli --cluster或者./redis-trib.rb：代表集群操作命令create：代表是创建集群--replicas 1或者--cluster-replicas 1：指定集群中每个master的副本个数为1，此时节点总数 ÷ (replicas + 1)得到的就是master的数量。因此节点列表中的前n个就是master，其它节点都是slave节点，随机分配到不同master
查看集群信息
redis-cli -p 7001 cluster nodes测试
# 连接
redis-cli -p 7001
# 存储数据
set num 123
# 读取数据
get num
# 再次存储
set a 1结果悲剧了：
集群操作时，需要给redis-cli加上-c参数才可以：
redis-cli -c -p 7001 
散列插槽
插槽原理
Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上，查看集群信息时就能看到：
数据key不是与节点绑定，而是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况：
- key中包含"{}"，且“{}”中至少包含1个字符，“{}”中的部分是有效部分
- key中不包含“{}”，整个key都是有效部分
例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。
如图，在7001这个节点执行set a 1时，对a做hash运算，对16384取余，得到的结果是15495，因此要存储到103节点。
到了7003后，执行get num时，对num做hash运算，对16384取余，得到的结果是2765，因此需要切换到7001节点
小结
Redis如何判断某个key应该在哪个实例？
- 将16384个插槽分配到不同的实例
- 根据key的有效部分计算哈希值，对16384取余
- 余数作为插槽，寻找插槽所在实例即可
如何将同一类数据固定的保存在同一个Redis实例？
- 这一类数据使用相同的有效部分，例如key都以{typeId}为前缀
总结
redis集群中的三个节点中的主节点互相监控，实时检查主节点是否宕机
三个主节点会平均分到相同数量的slot，可以任意连接一个redis服务端，写数据时，会根据key计算出一个slot值，如果这个slot值处于当前主节点的slot范围,会写入内容，并同步内容到对于从节点，反之就会把这个消息转发到包含这个slot值的主节点中，让那个主节点执行命令。
异常关闭主节点，对应的从节点就会成为主节点
恢复主节点，会成为新的主节点的从节点
异常关闭从节点，不影响集群使用，但是可能会出现单点故障问题
同时关闭一个节点的主和从，会导致整个集群不可用，因为有一部分slot值缺失
key过期删除策略
到了过期时间，有三种删除策略
定时删除
惰性删除
定期删除
一.定时删除
它会在设置键的过期时间的同时，创建一个定时器，当键到了过期时间，定时器就会立即对整个键进行删除，快速释放内存空间
但是缺点就是有大量的定时器运行，对cpu十分不友好，拉低系统的性能
二.惰性删除
这个策略不会持续的去关注key的过期时间，而是在获取key的时候，再去判断这个key是否过期，如果过期则删除这个key,并返回空
问题：对cpu十分友好，但是对内存十分不友好
三.定期删除
这个策略默认会（一秒执行10次）随机获取20个key，然后判断者20个可以是否过期，如果过期就删除，然后删除的个数超过1/4的概率(过期key多)，就会再触发依次继续随机获取然后删除过期的key，如果没有超过1/4就结束本次操作
如何自定义配置：
在redis.conf配置文件的hz参数即可
内存淘汰策略
如果当前redis允许使用的内存已经满了，继续向里面存入数据时，会发生什么
我们可以提高redis允许使用的最大内存
redis.conf的maxmemory参数
有八种内存淘汰策略
默认是不淘汰，当内存空间不足时，就抛出异常
对设置了过期时间的数据淘汰：
- 删除设置过期时间，且最近最久未被使用的key
- 删除设置过期时间，且最近最少未被使用的key
- 删除设置过期时间，且即将过期的key
- 从设置了删除过期时间的key中随机删除一个
对所有数据淘汰：
- 从所有数据中，删除最近最久未被使用的key
- 从所有数据中，删除最近最少未被使用的key
- 从所有数据中，随机删除一个key
原文地址：https://blog.csdn.net/luosuss/article/details/143894713
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！