redis 非线性数据库 （二）

一、redis中发布与订阅

1 什么是发布与订阅

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

Redis 客户端可以订阅任意数量的频道。

2 发布与订阅的命令

订阅：subscribe channel                   订阅频道channel。
发布：publish channel                    msg向频道channel 发送一条msg消息。

注意：只有订阅的客户端才能收到 发布的消息

二、Redis持久化

于 Redis 的数据都存放在内存中，如果没有配置持久化， Redis 重启后数据就全丢失了，于是需要开启

Redis 的持久化功能，将数据保存到磁盘上，当 Redis 重启后，可以从磁盘中恢复数据。

Redis提供了两个不同形式的持久化方式：

RDB(Redis DataBase)

AOF(Append Only File)

1、 持久化操作-RDB

1.1 RDB是什么？

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

1.2 备份过程

Redis 会单独创建（ fork ）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程 都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能，如果需要进行大规模数据的恢 复，且对于数据恢复的完整性不是非常敏感，那RDB 方式要比 AOF 方式更加的高效。 RDB 的缺点是最后 一次持久化后的数据可能丢失。

 1.3 dump.rdb文件

1. RDB 保存的文件，在 redis.conf 中配置文件名称，默认为 dump.rdb 。

 

2. rdb文件的保存位置，也可以修改。默认在Redis启动时命令行所在的目录下。  

 redis.conf中配置文件路径

 1.4 如何触发快照？

1.4.1 配置文件中默认的快照配置

 1. 快照默认配置

    
save 3600 1：表示3600秒内（一小时）如果至少有1个key的值变化，则保存 
save 300 100：表示300秒内（五分钟）如果至少有100个 key 的值变化，则保存 
save 60 10000：表示60秒内如果至少有 10000个key的值变化，则保存

注意：可以自己配置新的保存规则。配置修改后，需 要重启Redis服务。

redis-cli shutdown

redis-server    # 开启服务

redis-cli   启动客户端

1.4.2 flushall

执行 flushall 命令，也会触发 rdb 规则。

1.4.3 save与bgsave

 

1.4.4 stop-writes-on-bgsave-error 

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

1.4.5 rdbcompression 

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

 1.4.6 rdbchecksum

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

1.5 恢复数据  

只需要将 rdb 文件放在 Redis 的启动目录， Redis 启动时会自动加载 dump.rdb 并恢复数据

2 持久化操作-AOF

2.1 AOF是什么？

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

2.2 AOF持久化流程

1. 客户端的请求写命令会被 append 追加到 AOF 缓冲区内。

2. AOF 缓冲区根据 AOF 持久化策略 [always,everysec,no] 将操作同步到磁盘的 AOF 文件中。

3. AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 rewrite 重写，压缩 AOF 文件容量。

4. Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的。

2.3 AOF默认不开启  

可以在 redis.conf 中配置文件名称，默认为 appendonly.aof 。

AOF 文件的保存路径，同 RDB 的路径一致

注意：如果AOF和RDB同时启动，Redis默认读取AOF的数据。

2.4 AOF启动/修复/恢复  

正常恢复

1. 启动：设置Yes：修改默认的appendonly no，改为yes。

2. 恢复：重启Redis然后重新加载。

例：设置 appendonly 为 yes ，配置修改后，需要重启 Redis 服务。

重启服务  服务器启动后，生成appendonly.aof文件，且大小为0。

redis-cli shutdown

redis-server    # 开启服务

redis-cli   启动客户端

异常恢复

1. 启动：设置Yes：修改默认的appendonly no，改为yes。

2. 修复：如遇到AOF文件损坏，通过/user/local/bin/redis-check-aof --fix appendonly.aof进行

恢复。

3. 恢复：重启Redis然后重新加载。

2.5 AOF同步频率设置

1. appendfsync always

始终同步，每次Redis的写入都会立刻记入日志，性能较差但数据完整性比较好。

2. appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

3. appendfsync no

redis不主动进行同步，把同步时机交给操作系统。

2.6 Rewrite

1. AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大

小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令

集。

例：设置k1为0，然后incr 进行了4次，k1对应的值会是4，其实就相当于set k1 4

2. 重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定

Redis要满足一定条件才会进行重写。

redis.conf 默认配置

auto-aof-rewrite-min-size ：表示重写时，文件大小必须必这个值要大。

auto-aof-rewrite-percentage ：表示目前文件大小比上次重写后的文件大小大这么多才行。

二、Redis 事务

2.1 redis事务简介

1.Redis 事务是一组命令的集合，一个事务中的所有命令都将被序列化，按照一次性、顺序性、排他

性的执行队列系列的命令。

2. Redis 单条命令保证原子性，但是事务不保证原子性，且没有回滚。事务中任意命令执行失败，其

余的命令仍会被执行。

3. Redis 事务没有隔离级别的概念。批量操作在执行前被放入缓存队列，并不会被实际执行，也就不

存在事务内的查询要看到事务里的更新，事务外查询不能看到。

4. Redis 事务的三个阶段：

开始事务

命令入队

执行事务

2.2 Redis事务基本操作

Multi  开始事务 ，输入命令都会依次缓存在队列中，但不会执行

Exec  输入exec 后，redis会将之前的缓存在队列中的命令依次执行

discard  该命令  使multi开始事务后放弃组队

案例

multi 开始事务 
set k1 v1 进行组队，并不执行 
set k2 v2 进行组队，并不执行 
exec 执行队列命令，依次设置k1 k2

multi 开始事务 
set k3 v3 进行组队，并不执行 
set k4 v4 进行组队，并不执行 
discard 取消组队，都不执行

2.3 Redis中的乐观锁

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

watch key  # 用乐观锁监听这个key   注意：要在开启事务之前使用
multi      # 开启事务，把命令加载缓存队列中，但不会执行
exec       # 开始执行队列缓存中的命令

unwatch   #  取消watch 对所有key的监听

# 如果在执行watch命令之后，exec命令或discard命令先执行的话，那么就不需要再执行unwatch。

三、Redis主从复制

1、简介

主从复制，是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称为主节点 (Master) ，后

者称为从节点 (Slave) ；数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台 Redis 服务器都是主节点；且一个主节点可以有多个从节点 ( 或没有从节点 ) ，但一个从

节点只能有一个主节点。

Master 以写为主， Slave 以读为主。

2、主从复制的作用

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服

务的冗余。

3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务

（即写 Redis 数据时应用连接主节点，读 Redis 数据时应用连接从节点），分担服务器负载；尤其是

在写少读多的场景下，通过多个从节点分担读负载，可以大大提高 Redis 服务器的并发量。

4. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是

Redis 高可用的基础。

一般来说，要将 Redis 运用于工程项目中，不会只有一台 Redis ，原因如下：

1. 从结构上，单个 redis 服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较

大；

2. 从容量上，单个 redis 服务器内存容量有限，就算一台 Redis 服务器内存容量为 256G ，也不能将所有

内存用做 Redis 存储内存，一般来说， 单台 Redis 最大使用内存不应该超过 20G 。

 3、Redis主从复制-一主多从环境搭建

3.1  在reids配置文件的文件夹下 创建新建三个配置文件，分别为redis6379.conf、 redis6380.conf、redis6381.conf，由文件名可知，redis的端口号分别为6379、6380、6381。

touch reids6379.conf
touch redis6380.conf
touch redis6381.conf

创建出3个空文件，redis.conf是原有的配置文件。

3.2 在三个配置文件写入内容

可以通过include /usr/local/bin/myredis/redis.conf将公共基础配置直接引入文件。

将 include /usr/local/bin/myredis/redis.conf 统一添加到这三个文件中

在各个文件中，添加对应的 pidfile 、 port 、 dbfilename

 例如 ：

redis6379.conf 文件配置

include /usr/local/bin/myredis/redis.conf   # 导入公共配置基础文件
pidfile /var/run/redis_6379.pid             # 进程的具体文件
port 6379                                   # 端口号
dbfilename dump6379.rdb                     # 恢复文件名

redis6380.conf 文件配置

include /usr/local/bin/myredis/redis.conf  
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb

redis6381.conf 文件配置

include /usr/local/bin/myredis/redis.conf  
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb

3.3 通过不同的redis6379.conf 、redis6380.conf、redis6381.conf ，分别启动3个redis服务

redis-server ./myredis/redis6379.conf
redis-server ./myredis/redis6380.conf
redis-server ./myredis/redis6381.conf

3.4 查看redis三个服务开启的情况

netstat -ltnp

3.5 在redis客户端中，通过info replication命令可以查看Redis服务器当前状态 可以给redis-cli命令添加-p参数，来指定链接哪个服务器

redis-cli -p 6379 
redis-cli -p 6380 
redis-cli -p 6381

info replication

 3.6 把端口6380、6381追加到master的端口6379上

slaveof host port   # 链接主节点

slaveof no one      # 将slave变成master

注意：

在从库中进行写操作，会报错。

由于该主从复制在同一台虚拟机上搭建，所以需要修改端口号，如果在多台服务器上搭建主从复

制，则需要修改相对应的ip。

如果在多台服务器上搭建主从复制，一定要开放远程链接。

3.7 redis主从复制遇到的问题

1. 如果Master断开（宕机），Slave依然连接着Master，可以正常使用读操作，但是没有写操作。如
果Master恢复正常，Slave依旧可以直接获取Master写的信息。
2. 如果Slave断开（宕机），当该Slave重启成功，则会变为Master，需要通过slaveof 恢复成Slave，
只要变为Slave，立刻可以从Master同步所有数据

3.8 reids 主从复制原理

Slave启动成功连接到Master后会主动发送一个同步（sync）命令。
Master接到Slave的命令，把Master数据进行持久化，把rdb文件发送给Slave，Slave拿到rdb进行
读取。
每次Master进行写操作之后，会和Slave进行数据同步。

4、Redis主从复制之哨兵模式（Sentinel）

反客为主的自动版，能够后台监控Master是否故障，如果故障了，根据投票数自动将Slave转换为
Master。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独
立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

 

4.1 哨兵模式的使用 

1、redis服务器弄成一主多从        

2、在redis配置文件夹下创建建sentinel.conf文件（名字一定不能错）。

3、配置哨兵， sentinel.conf添加内容

# sentinel monitor <master-name> <ip> <port> <count>w 
sentinel monitor myredis 127.0.0.1 6379 1

其中： myredis 为监控对象起的服务器名称（随意）， 1 代表至少有 1 个哨兵投票同意迁移

如果Master存在密码，需要配置sentinel auth-pass 服务器名 密码

sentinel auth-pass myredis 123456 
daemonize yes

4、启动哨兵，在/usr/local/bin/文件夹下执行./redis-sentinel /usr/local/myredis/sentinel.conf命 令

四、Redis集群

1、redis集群简介

1.1 Redis集群（RedisCluster）
RedisCluster实现了对Redis的水平扩容，即启动N个Redis节点，将整个数据库分布存储在这N个节点当中，每个节点存储总数据的1/N。
RedisCluster通过分区（partition）来提供一定程度的可用性（availability）：即集群有一部分节点失效或者无法进行通讯，集群也可以继续处理命令。（当主节点挂掉的时候，开启redis哨兵模式，把子节点升为主节点，那ip就改变了，redis集群中当一部分节点挂掉，可以使用其他节点来处理命令）
Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接，用来交换彼此的信息。

为了使得集群在一部分节点宕机或者无法与集群的大多数节点进行通讯的情况下， 仍然可以正常运作，
Redis 集群对节点使用了主从复制功能。 

2、redis集群环境的搭建

1. 删除持久化数据，aof、rdb  

2. 创建6个实例，即在/usr/local/bin/myredis文件夹下分别创建6379、6380、6381、6389、6390、6391的conf。

3. 在redis.conf中关闭appendonly

4. 在不同的conf文件中，配置对应的内容可以通过include /usr/local/myredis/redis.conf将公共基础配置直接引入文件。将include /usr/local/myredis/redis.conf统一添加到这三个文件中
在各个文件中，添加对应的pidfile、port、dbfilename、cluster-enabled（是否打开集群）、cluster-config-file（设定节点配置文件名）、cluster-node-timeout （设置节点失联时间，超过该时间（毫秒），集群自动进行主从切换）

例如：

        redis6379.conf中添加

# 引入公共配置文件
include /usr/local/myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
# 是否打开集群
cluster-enabled yes
# 设定节点配置文件名
cluster-config-file nodes-6379.conf
# 设置节点失联时间，超过该时间（毫秒），集群自动进行主从切换
cluster-node-timeout 15000

5. 启动该6个redis，并确保是否全部生成nodes-xxxx.conf文件。（启动之前务必保证redis服务支持远程连接，redis.conf中 bind 0.0.0.0）

6. 进入redis安装目录下的src文件夹 

7. 在/opt/redis-6.2.6/src文件夹下执行命令

redis-cli --cluster create --cluster-replicas 1 ip:6379
ip:6380 ip:6381 ip:6389 ip:6390 ip:6391

 此处使用真实ip地址，-replicas 1代表采用最简单的方式配置集群，一台主机，一台从机。
replicas表示每个master需要有几个slave。

执行命令后，redis提供推荐的主从配置建议，执行同意。 

集群创建成功。

8. 通过./redis-cli -c -p 6379可连接至集群（由于所有节点相通，任意端口号均可）
在redis客户端中执行cluster nodes查看节点状态。

3、每个节点存储的数据 

一个 Redis 集群包含 16384 个哈希槽（hash slot），每个键都属于这 16384 个哈希槽的其中一个。
集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key
的 CRC16 校验和 。
集群中的每个节点负责处理一部分哈希槽。 举个例子， 一个集群可以有三个节点， 其中：
        1. 节点 1 负责处理 0 号至 5500 号哈希槽。
        2. 节点 2 负责处理 5501 号至 11000 号哈希槽。
        3. 节点 3 负责处理 11001 号至 16384 号哈希槽。

 

3.1 命令执行 

set k1 v1

根据k1计算出的槽值进行切换节点，并存入数据。 

不在一个槽(slot)下的键值，是不能使用mget、mset等多建操作。

mset k1 v1 k2 v2 k3 v3   # 这样使用会报错

解决方法：

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

mset k1{test} v1 k2{test} v2 k3{test} v3

 3.2 故障修复

1. 关闭6379服务器，进入redis-cli执行cluster nodes

6379服务器fail，6390成为了新的master
2. 重新启动6379服务器，再次查看，6379成为了Slave 

五、redis分布式

Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系Redis中可以使用SETNX命令实现分布式锁。
将 key 的值设为 value ，当且仅当 key 不存在。 若给定的 key 已经存在，则 SETNX 不做任何动作

解锁：使用 del key 命令就能释放锁

解决死锁：
1）通过Redis中expire()给锁设定最大持有时间，如果超过，则Redis来帮我们释放锁。
2） 使用 setnx key “当前系统时间+锁持有的时间”和getset key “当前系统时间+锁持有的时间”组合的命令就可以实现。