一、事务机制

Redis是支持事务的，Redis事务是基于队列实现的，创建一个事务队列，然后将事务操作都放入队列中，最后依次执行。 :::info

开启事务
multi
#添加命令
sadd key1:value1:key2:value2
sadd key2:value2:key1:value1
.
.
.
#执行事务
exec
# 取消事务
discard

:::

1.1.事务处理机制

语法错误（编译）
当编译时出现语法错误，执行exec时，会直接返回错误，正确的命令也不会执行
执行错误（运行）
命令在运行时出现错误，只有错误的命令不执行

1.2.SpringBoot实现事务操作

1）修改RedisConfig配置类，开启事务控制 :::info //开启redis事务控制
redisTemplate.setEnableTransactionSupport(true); :::

二、 持久化机制

Redis将数据保存在内存中。一旦服务器宕机重启，内存中的数据就会丢失。为了能够让Redis进行数据恢复，因此Redis提供了持久化机制，将内存中的数据保存到磁盘中，避免数据意外丢失。
Redis提供了两种持久化机制：RDB、AOF。 两者可以单独使用，也可以一起使用，一起时，AOF等级比RDB高。

2.1RDB

RDB（Redis DataBase）是Redis默认存储方式。基于快照思想，把这一刻数据保存在磁盘上，产生一个经过压缩的二进制文件，后缀名.rdb。
如果服务器宕机，只要磁盘文件存在就可以还原Redis数据。

2.1.1RDB触发条件

在redis.conf配置中有默认触发机制 :::info save “” # 不使用RDB存储 不能主从
# 记忆
save 3600 1 #表示1小时内至少1个键被更改则进行快照。
save 300 100 #表示5分钟（300秒）内至少100个键被更改则进行快照。
save 60 10000 #表示1分钟内至少10000个键被更改则进行快照。 ::: 也可以手动触发 :::info

进入客户端
bin/redis-cli
#执行save命令(同步执行)
save
#执行bgsave命令(异步子线程执行)
bgsave

::: save 与bgsave区别：
save：同步处理，阻塞Redis服务进程，服务器不会处理任何命令，直到RDB文件保存完毕。
bgsave：会fork一个和主线程一致的子线程负责操作RDB文件，不会阻塞Redis服务进程，操作RDB文件的同时仍然可以处理命令。
redis默认使用bgsave

2.1.2优缺点

优点：

• 基于二进制文件完成数据备份，占用空间少，便于文件传输。
• 能够自定义规则，根据Redis繁忙状态进行数据备份。

缺点：

• 无法保证数据完整性，会丢失最后一次快照后的所有数据。
• bgsave执行每次执行都会阻塞Redis服务进程创建子线程，频繁执行影响系统吞吐率。

  2.2AOF

  当开启AOF持久化后，Redis会将客户端发送的所有更改数据的命令，记录到磁盘中的AOF文件。当Redis重启后，通过读取AOF文件，按顺序获取到记录的数据修改命令，即可完成数据恢复。
  

  2.2.1AOF触发条件

  AOF方式需要手动开启，修改redis.conf :::info

  是否开启AOF，默认为no
  appendonly yes

设置AOF文件名称
appendfilename appendonly.aof

::: AOF的触发方式有三种：always、everysec、no。 默认使用everysec。可以通过redis.conf中appendfsync属性进行配置。

2.2.2执行原理

AOF功能实现的整个执行过程可以分为三个部分：命令追加、文件写入、文件同步。
向磁盘同步根据策略就是redis.conf文件中appendfsync属性值：always、everysec、no
always：每执行一条命令，就执行一次流程
everysec：先把命令从缓存区写入AOF文件中，每隔一秒就会由子线程同步到磁盘
no：把命命从缓冲区全部写入AOF文件中，但是不同步到磁盘。同步交给操作系统完成。间隔30秒
区别：
AOF_BUF写入到AOF AOF文件写入磁盘 宕机重启时 效 安
是否阻塞 是否阻塞 丢失的数据量 率 全
always 阻塞 阻塞 最多只丢失一个命令的数据 低 高
everysec 阻塞 不阻塞 不超过两秒的数据 中 中
no 阻塞 阻塞 操作系统最后一次 高 低
对AOF写入磁盘的数据

2.2.3AOF重写优化

AOF会将对Redis操作的所有写命令都记录下来，随着运行时间，数据会也来越大，占用存储空间也来也大，导致数据还原花费时间也越来也多。
AOF文件重写：当AOF文件体积超过阈值时，Redis会开启子线程创建一个新的AOF文件替代现有AOF文件
1）通过修改redis.conf进行配置 :::info

当前aof文件大小超过上一次aof文件大小的百分之多少时进行重写。如果之前没有重写过，以
启动时aof文件大小为准
auto-aof-rewrite-percentage 100

限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化
auto-aof-rewrite-min-size 64mb

:::

2.3RDB与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. 也可以选择都开启

   三、 高可用-主从复制

   不管是RDB还是AOF，都并不能百分百的避免数据丢失。为了防止数据丢失，可以将数据保存在不同的服务器上。

主服务器和从服务器；也可以防止请求量过大导致排队的问题
主服务器（Master）：负责写数据
从服务器（Slave）：负责读数据
此时，如果从服务器宕机重启，数据不会丢失，主服务器可以将数据同步到从服务器；
主服务器宕机，可以把从服务器设置成主服务器，再讲其他从服务器连接新的主服务器，重启后，改为从服务器；

3.1主从复制的作用

• 读写分离：主写从读，提高服务器的读写负载能力
• 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
• 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
• 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式

• 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

  3.2哨兵模式

  主从复制，虽然解决了数据丢失，和读写分离，但是操作太过繁琐，还要每时每刻盯着，所以就有了哨兵模式。
  哨兵模式是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制新的master并将所有slave连接到新的master。
  
  哨兵也是一台redis服务器，只是不提供数据服务；
  哨兵集群通常为单数；

  3.2.1哨兵集群

  

• Redis提供了哨兵的命令，是一个独立的进程

• 原理 哨兵通过发送命令给多个节点，等待Redis服务器响应，从而监控运行的多个Redis实例的运行情况
• 当哨兵监测到master宕机，会自动将slave切换成master，通过通知其他的从服务器，修改配置文件切换主机

Sentinel三大工作任务：监控、提醒、自动故障迁移

3.2.2客观下线和主观下线

主观下线：当哨兵检测到主库和从库未响应超时，就会标记为主观下线；
注意：如果主库未响应，会发生主从切换；但是出现误判其实主库并没有故障，会出现额外的计算和通信开销。
客观下线：客观下线条件只适用于主服务器

仲裁 qurum：当主管下线达到足够数量，主库会变成客观下线，足够数量的值一般是Sentinel个数的一 半加1；
down-after-milliseconds 是一个哨兵在超过规定时间依旧没有得到响应后，会自己认为主 机不可用；
达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover

3.2.3 集群节点哨兵模式工作原理

哨兵集群中的多个实例共同判断，可以降低对主库下线的误判率
哨兵集群组成: 基于 pub/sub 机制
基于 pub/sub 机制的客户端事件通知

四、 高可扩-Redis Cluster分片集群

4.1分片集群原理

采用哈希槽（Hash Slot）来处理数据和实例之间的映射关系，一个切片集群共有 16384 个哈希槽。
需要把 16384 个槽都分配完，否则 Redis 集群无法正常工作
重定向机制：

• 如果实例上没有该键值对映射的哈希槽，就会返回 MOVED 命令
  • 客户端会更新本地缓存

• 在迁移部分完成情况下，返回ASK

  • 表明 Slot 数据还在迁移中
  • ASK 命令把客户端所请求数据的最新实例地址返回给客户端
  • 并不会更新客户端缓存的哈希槽分配信息

    4.2集群常用命令

    :::info CLUSTER INFO // 打印集群的信息
    CLUSTER NODES // 列出集群当前已知的所有节点（node），以及这些节点的相关信息。
    
    //节点
    CLUSTER MEET // 将 ip 和 port 所指定的节点添加到集群当中，让它成为集群的一份子。
    CLUSTER FORGET // 从集群中移除 node_id 指定的节点。
    CLUSTER REPLICATE // 将当前节点设置为 node_id 指定的节点的从节点。
    CLUSTER SAVECONFIG // 将节点的配置文件保存到硬盘里面。
    CLUSTER ADDSLOTS [slot …] // 将一个或多个槽（slot）指派（assign）给当前节点。
    CLUSTER DELSLOTS [slot …] // 移除一个或多个槽对当前节点的指派。
    CLUSTER FLUSHSLOTS // 移除指派给当前节点的所有槽，让当前节点变成一个没有指派任何槽的节点。
    CLUSTER SETSLOT NODE // 将槽 slot 指派给 node_id 指定的节点。
    CLUSTER SETSLOT MIGRATING // 将本节点的槽 slot 迁移到 node_id 指定的节点中。
    CLUSTER SETSLOT IMPORTING // 从 node_id 指定的节点中导入槽 slot 到本节点。
    CLUSTER SETSLOT STABLE // 取消对槽 slot 的导入（import）或者迁移（migrate）。
    //键
    CLUSTER KEYSLOT // 计算键 key 应该被放置在哪个槽上。
    CLUSTER COUNTKEYSINSLOT // 返回槽 slot 目前包含的键值对数量。
    CLUSTER GETKEYSINSLOT // 返回 count 个 slot 槽中的键。
    //新增
    CLUSTER SLAVES node-id // 返回一个master节点的slaves 列表 :::

    五、 key过期删除策略

    Redis中对于过期键的过期删除策略：

• 定时删除

  • 该策略对内存空间足够友好， 但对CPU非常不友好，会拉低系统性能，因此不建议使用。
• 惰性删除
  • 惰性删除对CPU足够友好，但是对内存空间非常不友好，会造成大量内存空间的浪费。
• 定期删除
  • 默认每秒运行10次会对具有过期时间的key进行一次扫描，但是并不会扫描全部的key，因为这样会大大延长扫描时间。
  • 每次默认只会随机扫描20个key，同时删除这20个key中已经过期的key。
  • 如果这20个key中过期key的比例达超过25%，则继续扫描。

默认每秒扫描10次，想要修改只需修改redis.conf中的hz参数即可

六、内存淘汰策略

在64位操作系统中，如果未设置或设置0，代表无限制。而在32位系统中，默认内存大小为3GB。但是实际生产环境下，一般会设置物理内存的四分之三左右。修改redis.conf中的maxmemory 来设置最大内存。
当客户端执行命令，添加数据时，Redis会检查内存空间大小，如超过最大内存，则触发内存淘汰策略。

6.1淘汰策略

redis默认使用noeviction，我们可以通过修改redis.conf中maxmemory-policy属性值设置不同的内存淘汰策略。

6.2不同策略的使用场景

Redis只做缓存，不做DB持久化，使用allkeys。如状态性信息，经常被访问，但数据库不会修改。
2、同时用于缓存和DB持久化，使用volatile。如商品详情页。
3、存在冷热数据区分，则选择LRU或LFU。如热点新闻，热搜话题等。
4、每个key被访问概率基本相同，选择使用random。如企业内部系统，访问量不大，删除谁对数据库也造成太大压力。
5、根据超时时间长久淘汰数据，选择选用ttl。如微信过期好友请求。