Redis 6 新手入门基础篇

Redis 6 新手入门基础篇

前言

今天来讲讲redis以下知识点，如有不当请多指教！

• Redis持久化
• 主从复制
• Sentinel机制
• Redis Cluster

Redis持久化

redis是基于内存的，如果不想办法将数据保存在硬盘上，一旦redis重启(退出/故障)，内存的数据将会全部丢失。

Redis提供了两种持久化方法：

RDB(基于快照)，将某一时刻的所有数据保存到一个RDB文件中。 AOF(append-only-file)，当Redis服务器执行写命令的时候，将执行的写命令保存到AOF文件中。

RDB

保存某个时间点的全量数据快照

• 手动触发 SAVE：阻塞Redis的服务器进程，知道RDB文件被创建完毕 BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程，使用lastsave指令可以查看最近的备份时间
• 自动触发 根据redis.conf配置里的save m n定时触发（用的是BGSAVE） 主从复制时，主节点自动触发 执行Debug Relaod 执行Shutdown且没有开启AOF持久化

注意：Redis服务器在启动的时候，如果发现有RDB文件，就会自动载入RDB文件(不需要人工干预)

RDB的优缺点

优点： RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照，适合备份，全量复制等场景。 且加载RDB恢复数据远远快于AOF的方式。

缺点： 没办法做到实时持久化/秒级持久化，因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

RDB的相关配置

//在n秒内修改m条数据时创建RDB文件
save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error yes  //bgsave出错时停止写入
rdbcompression yes  //压缩RDB文件
rdbchecksum yes   //校验文件是否损坏

AOF

与RDB不一样的是，AOF记录的是命令，而不是数据。

如何开启AOF? 只需在配置文件中将appendonly设置为yes即可。

AOF的工作流程：

1、所有的写入命令追加到aof_buf缓冲区中。 2、AOF会根据对应的策略向磁盘做同步操作。刷盘策略由appendfsync参数决定。 3、定期对AOF文件进行重写。重写策略由auto-aof-rewrite-percentage，auto-aof-rewrite-min-size两个参数决定。

appendfsync参数有如下取值：

appendfsync always     # 每次有数据修改发生时都会写入AOF文件。
appendfsync everysec   # 每秒钟同步一次，该策略为AOF的默认策略。
appendfsync no         # 从不同步。高效但是数据不会被持久化。

AOF重写

为什么要重写？ 重写后可以加快节点启动时的加载时间

重写后的文件为什么可以变小？ 进程内超时的数据不用再写入到AOF文件中 多条写命令可以合并为一个

重写条件

1、手动触发 直接调用bgrewriteaof命令

2、自动触发

先来看看有关参数： auto-aof-rewrite-min-size：执行AOF重写时，文件的最小体积，默认值为64MB。 auto-aof-rewrite-percentage：执行AOF重写时，当前AOF大小(即aof_current_size)和上一次重写时AOF大小(aof_base_size)的比值。

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时满足时，才会自动触发AOF重写。

后台重写

Redis将AOF重写程序放到子进程里执行(BGREWRITEAOF命令)，像BGSAVE命令一样fork出一个子进程来完成重写AOF的操作，从而不会影响到主进程。

AOF后台重写是不会阻塞主进程接收请求的，新的写命令请求可能会导致当前数据库和重写后的AOF文件的数据不一致！ 为了解决数据不一致的问题，Redis服务器设置了一个AOF重写缓冲区，当子进程完成重写后会发送信号让父进程将AOF重写缓冲区的数据写到新的AOF文件。

RDB和AOF比较

RDB和AOF并不互斥，它俩可以同时使用。

RDB的优点：载入时恢复数据快、文件体积小。 RDB的缺点：会一定程度上丢失数据(因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。)

AOF的优点：丢失数据少(默认配置只丢失1秒的数据)。 AOF的缺点：恢复数据相对较慢，文件体积大

如果Redis服务器同时开启了RDB和AOF持久化，服务器会优先使用AOF文件来还原数据(因为AOF更新频率比RDB更新频率要高，还原的数据更完善)

主从复制

单机有什么问题？

单机即在一台机器上部署一个redis节点，主要会存在以下问题： 1、如果发生机器故障，例如磁盘损坏，主板损坏等，未能在短时间内修复好，客户端将无法连接redis 2、Redis的内存是有限的，可能放不下那么多的数据 3、单台Redis支持的并发量也是有限的

如图上面是master节点，下面是slave节点，即主节点和从节点。从节点也是可以对外提供服务的，主节点是有数据的，从节点可以通过复制操作将主节点的数据同步过来，并且随着主节点数据不断写入，从节点数据也会做同步的更新。 整体起到的就是数据备份的效果

除了一主一从模型之外，redis还提供了一主多从的模型，也就是一个master可以有多个slave，也就相当于有了多份的数据副本。

读写分离

除了作为数据备份，主从模型还能做另外一个功能，就是读写分离。 让master节点负责提供写服务，slave节点提供读服务，而将数据读取的压力进行分流和负载，分摊给所 有的从节点。

主从复制的配置

1. slaveof命令

slaveof 198.162.88.66 6379

执行该命令使当前redis节点成为指定redis节点的从节点，此复制命令是异步进行的，redis会自动进行后续数据复制的操作

如果想取消从节点可以执行 slave of on one 命令

2、修改配置

# 配置主节点的IP和端口号
slaveof ip port
# 从节点只做读的操作，保证主从数据的一致性
slave-read-only yes

runid和复制偏移量

redis每次启动的时候都会有一个随机的ID，作为一个标识，这个ID就是runid，当然重启之后值就改变了。 假如端口为6380的redis去复制6379，知道runid后，在6380上做一个标识，如果runid改变了，说明主可能重启了或者发生了其它变化，这时候就可以做一个全量复制把数据同步过来。或者第一次启动时根本不知道6379的runid，也会进行全量复制

偏移量：数据写入量的字节 比如主执行set hello world，就会有一个偏移量，然后从同步数据，也会记录一个偏移量 当两个偏移量达到一致时候，实际上数据就是完全同步的状态。

全量复制

全量复制主节点会将RDB文件也就是当前状态去同步给slave，在此期间主节点新写入的命令会单独记录起来，然后当RDB文件加载完毕之后，会通过偏移量对比将这个期间产生的写入值同步给slave，这样就能达到数据完全同步的效果

全量复制过程

1. 在其内部有一条命令psync，是做同步的命令，它可以完成全量复制和部分复制的功能，当启动slave节点时，它会发送psync命令给主节点，需要传递两个参数，runid和offset(偏移量)，也就是从节点向主节点传递主节点的runid以及自己的偏移量，对于第一次复制而言，就直接传递？和 -1，当然这个参数是由slave内部传的。
2. master接收到命令后知道从希望做全量复制，主就会将自己的runid和offset传递给从节点
3. slave节点保存master的基本信息
4. master执行bgsave生成RDB文件，并且在此期间新产生的写入命令会被记录到repl_back_buffer(复制缓冲区)
5. 主节点向从节点传输RDB文件
6. 主节点向从节点发送复制缓冲区内容
7. 清空从节点旧的数据
8. 从节点加载RDB文件到内存中，同时加载缓冲区数据

执行全量复制除了开销大之外，还会有个问题： 假如master和slave网络发生了抖动，那一段时间内这些数据就会丢失，对于slave来说这段时间master更新的数据是不知道的。最简单的方式就是再做一次全量复制，从而获取到最新的数据，在redis2.8之前是这么做的。

部分复制

redis2.8之后提供部分复制，如果发生类似网络抖动，可以有这样一种机制将这种损失降低到最低，如何实现的？

部分复制过程

1. 如果发生了抖动，相当于连接断开了
2. 主节点会将写命令记录到缓冲区(repl_back_buffer)
3. 当slave再次去连接master时候，就是说网络抖动结束之后，会触发部分复制
4. 从节点会执行pysnc命令，将当前自己的offset和主的runid传递给master
5. 如果发现传输的offset偏移量是在buffer内的，如果不在内就说明你已经错过了很多数据，buffer也是有限的，默认是1M(建议调为10M)，会将offset开始到队列结束的数据同步给从节点。这样master和slave就达到了一致。

通过部分复制有效的降低了全量复制的开销。

Redis Sentinel

简介

Sentinel(哨兵)是用于监控redis集群中master状态的工具，是Redis 的高可用性解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。 Sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为新的master服务，替代已下线的master服务继续处理请求，等挂掉的主服务器重连上来，会将它变成从服务器。

三个定时任务

Sentinel在内部有3个定时任务 1）每隔10秒——每个sentinel会对master和slave执行info命令，这个任务主要用来发现slave节点和确认主从关系。 2）每隔2秒——每个sentinel通过master节点的channel交换信息（pub/sub）。master节点上有一个名为__sentinel__:hello的发布订阅的频道。sentinel节点通过__sentinel__:hello频道进行信息交换(对节点的"看法"和自身的信息)，达成共识。 3）每隔1秒——每个sentinel对其他sentinel和redis节点执行ping操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。

主观/客观下线

判断主服务器是否下线有两种情况：

主观下线

Sentinel会以每秒一次的频率向与它创建命令连接的实例(包括主从服务器和其他的Sentinel)发送PING命令，通过PING命令返回的信息判断实例是否在线 如果一个主服务器在down-after-milliseconds毫秒内连续向Sentinel发送无效回复，那么当前Sentinel就会主观认为该主服务器已经下线了。

客观下线

当Sentinel将一个主服务器判断为主观下线以后，为了确认该主服务器是否真的下线，它会向同样监视该主服务器的Sentinel询问，看它们是否也认为该主服务器是否下线。 如果足够多的Sentinel认为该主服务器是下线的，那么就判定该主服务为客观下线，并对主服务器执行故障转移操作。

conf文件配置

在redis-sentinel的conf文件里有这么两个配置：

1）sentinel monitor

四个参数含义： masterName这个是对某个master+slave组合的一个区分标识。 ip 和 port 就是master节点的 ip 和 端口号。 quorum这个参数是进行客观下线的一个依据，意思是**至少有 quorum 个sentinel主观的认为这个master有故障，才会对这个master进行下线以及故障转移。**因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

2）sentinel down-after-milliseconds

这个配置其实就是进行主观下线的一个依据，表示：如果这台sentinel超过timeout这个时间都无法连通master包括slave的话，就会主观认为该master已经下线。

领导者选举

当一个主服务器被认为客观下线以后，此时需要一个Sentinel服务器对该服务器进行处理，因此监视这个下线的主服务器的各个Sentinel会进行协商，选举出一个领头的Sentinel，领头的Sentinel会对下线的主服务器执行故障转移操作。

选举领头Sentinel的规则也比较多，总的来说就是先到先得(哪个快，就选哪个)

故障转移处理

1. 多个sentinel发现并确认master有问题
2. 选举出一个sentinel作为领导
3. 选出一个slave作为master
4. 通知其余slave成为新的master的slave
5. 通知客户端主从变化
6. 等待老的master复活成为新master的slave

注意：挑选某一个从服务器作为主服务器也是有策略的，大概如下：

（1）跟master断开连接的时长 （2）slave优先级 （3）复制offset大小 （4）run id

Redis Cluster

Redis3.0版本之前，可以通过Redis Sentinel（哨兵）来实现高可用，从3.0版本之后，官方推出了Redis Cluster，它的主要用途是实现数据分片，并且实现高可用。

在Redis Sentinel模式中，每个节点需要保存全量数据，冗余比较多，而在Redis Cluster模式中，每个分片只需要保存一部分的数据，

Redis Cluster每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。

Redis Cluster的具体实现细节是采用了Hash槽的概念，集群会预先分配16384个槽，并将这些槽分配给具体的服务节点，通过对Key进行CRC16(key)%16384运算得到对应的槽是哪一个，从而将读写操作转发到该槽所对应的服务节点。当有新的节点加入或者移除的时候，再来迁移这些槽以及其对应的数据。在这种设计之下，我们就可以很方便的进行动态扩容或缩容。

Redis Cluster为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。

有关redis集群的安装配置在这里就不多说了，在这里对先对redis cluster有个了解，日后再来补充。

总结

如果这篇文章对您有所帮助，或者有所启发的话，求一键三连：点赞、转发、收藏，您的支持是我坚持写作最大的动力。