Redis配置详解

我们说 Redis 相对于 Memcache 等其他的缓存产品，有一个比较明显的优势就是 Redis 不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。本篇博客我们就将介绍这些数据类型的详细使用以及顺带介绍Redis系统的相关命令用法。

　　注意：Redis的命令不区分大小写，但是key 严格区分大小写！！！

0、写在前面

　　下面介绍的Redis命令有很多，如果你想通过死记硬背来记住这些命令几乎不可能，但是如果理解了Redis的一些机制，这些命令其实是由很强的通用性的，通过理解来记忆是最好的。另外，每种数据类型都有其适合的使用场景，我也会在文中给与说明，如果滥用，反而会适得其反。

1、string 数据类型

　　string 是Redis的最基本的数据类型，可以理解为与 Memcached 一模一样的类型，一个key 对应一个 value。string 类型是二进制安全的，意思是 Redis 的 string 可以包含任何数据，比如图片或者序列化的对象，一个 redis 中字符串 value 最多可以是 512M。

①、相关命令介绍

　　string 数据类型在 Redis 中的相关命令：

　　表格图片引用：http://www.cnblogs.com/xrq730/p/8944539.html（下同）

　　

　　

　　PS：

　　①、上面的 ttl 命令是返回 key 的剩余过期时间，单位为秒。

　　②、mset和mget这种批量处理命令，能够极大的提高操作效率。因为一次命令执行所需要的时间=1次网络传输时间+1次命令执行时间，n个命令耗时=n次网络传输时间+n次命令执行时间，而批量处理命令会将n次网络时间缩减为1次网络时间，也就是1次网络传输时间+n次命令处理时间。

　　但是需要注意的是，Redis是单线程的，如果一次批量处理命令过多，会造成Redis阻塞或网络拥塞（传输数据量大）。

　　③、setnx可以用于实现分布式锁，具体实现方式后面会介绍。

　　上面是 string 类型的基本命令，下面介绍几个自增自减操作，这在实际工作中还是特别有用的（分布式环境中统计系统的在线人数，利用Redis的高性能读写，在Redis中完成秒杀，而不是直接操作数据库。）。

　　

　　

②、典型使用场景

　　一、计数

　　由于Redis单线程的特点，我们不用考虑并发造成计数不准的问题，通过 incrby 命令，我们可以正确的得到我们想要的结果。

　　二、限制次数

　　比如登录次数校验，错误超过三次5分钟内就不让登录了，每次登录设置key自增一次，并设置该key的过期时间为5分钟后，每次登录检查一下该key的值来进行限制登录。

2、hash 数据类型

　　hash 是一个键值对集合，是一个 string 类型的 key和 value 的映射表，key 还是key，但是value是一个键值对（key-value）。类比于 Java里面的 Map<String,Map<String,Object>> 集合。

①、相关命令介绍

　　

　　演示如下：

　　

②、典型使用场景

　　查询的时间复杂度是O(1)，用于缓存一些信息。

3、list 数据类型

　　list 列表，它是简单的字符串列表，按照插入顺序排序，你可以添加一个元素到列表的头部（左边）或者尾部（右边），它的底层实际上是个链表。

　　列表有两个特点：

　　一、有序

　　二、可以重复

　　这两个特点要注意和后面介绍的集合和有序集合相对比。

①、相关命令介绍

　　

　　

　　

②、典型使用场景

　　一、栈

　　通过命令 lpush+lpop

　　二、队列

　　命令 lpush+rpop

　　三、有限集合

　　命令 lpush+ltrim

　　四、消息队列

　　命令 lpush+brpop

4、set 数据类型

　　Redis 的 set 是 string 类型的无序集合。

　　相对于列表，集合也有两个特点：

　　一、无序

　　二、不可重复

①、相关命令介绍

　　

　　

　　

②、典型使用场景

　　利用集合的交并集特性，比如在社交领域，我们可以很方便的求出多个用户的共同好友，共同感兴趣的领域等。

5、zset 数据类型

　　zset（sorted set 有序集合），和上面的set 数据类型一样，也是 string 类型元素的集合，但是它是有序的。

①、相关命令介绍

　　

　　

②、典型使用场景

　　和set数据结构一样，zset也可以用于社交领域的相关业务，并且还可以利用zset 的有序特性，还可以做类似排行榜的业务。

6、Redis5.0新数据结构-stream

　　Redis的作者在Redis5.0中，放出一个新的数据结构，Stream。Redis Stream 的内部，其实也是一个队列，每一个不同的key，对应的是不同的队列，每个队列的元素，也就是消息，都有一个msgid，并且需要保证msgid是严格递增的。在Stream当中，消息是默认持久化的，即便是Redis重启，也能够读取到消息。那么，stream是如何做到多播的呢？其实非常的简单，与其他队列系统相似，Redis对不同的消费者，也有消费者Group这样的概念，不同的消费组，可以消费同一个消息，对于不同的消费组，都维护一个Idx下标，表示这一个消费群组消费到了哪里，每次进行消费，都会更新一下这个下标，往后面一位进行偏移。

7、系统相关命令

　　

8、key 相关命令

　　关于 key 的命令应该说是最常用的，需要大家记住。

　　

　　

　　

　　这里在介绍一个命令：

OBJECT ENCODING    key

　　这是用来显示这五种数据类型的底层数据结构，下一篇博客我们会详细介绍。

　　

　　上面的命令我们给string 数据类型 k1 赋值 str，给 k2 赋值 123，通过 OBJECT ENCODING 显示底层实现的数据类型分别是 embstr 和 int。这到底是什么呢？下篇博客我们会详细介绍的。

前面我们说过，Redis 相对于 Memcache 等其他的缓存产品，有一个比较明显的优势就是 Redis 不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。这几种丰富的数据类型我们花了两篇文章进行了详细的介绍，接下来我们要介绍 Redis 的另外一大优势——持久化。

　　由于 Redis 是一个内存数据库，所谓内存数据库，就是将数据库中的内容保存在内存中，这与传统的MySQL，Oracle等关系型数据库直接将内容保存到硬盘中相比，内存数据库的读写效率比传统数据库要快的多（内存的读写效率远远大于硬盘的读写效率）。但是保存在内存中也随之带来了一个缺点，一旦断电或者宕机，那么内存数据库中的数据将会全部丢失。

　　为了解决这个缺点，Redis提供了将内存数据持久化到硬盘，以及用持久化文件来恢复数据库数据的功能。Redis 支持两种形式的持久化，一种是RDB快照（snapshotting），另外一种是AOF（append-only-file）。本篇博客先对 RDB 快照进行介绍。

1、RDB 简介

　　RDB是Redis用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。

2、触发方式

　　RDB 有两种触发方式，分别是自动触发和手动触发。

①、自动触发

　　在 redis.conf 配置文件中的 SNAPSHOTTING 下，在这篇文章中我们介绍过。

　　

　　①、save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave（这个命令下面会介绍，手动触发RDB持久化的命令）

　　默认如下配置：

save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存

　　　　当然如果你只是用Redis的缓存功能，不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。可以直接一个空字符串来实现停用：save ""

　　②、stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了

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

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

　　⑤、dbfilename ：设置快照的文件名，默认是 dump.rdb

　　⑥、dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录。

　　也就是说通过在配置文件中配置的 save 方式，当实际操作满足该配置形式时就会进行 RDB 持久化，将当前的内存快照保存在 dir 配置的目录中，文件名由配置的 dbfilename 决定。

②、手动触发

　　手动触发Redis进行RDB持久化的命令有两种：

　　1、save

　　该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。

　　显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，Redis提供了第二种方式。

　　2、bgsave

　　执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

　　基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

　　ps:执行执行 flushall 命令，也会产生dump.rdb文件，但里面是空的.

3、恢复数据

　　将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

　　获取 redis 的安装目录可以使用 config get dir 命令

　　

　　载入的标识是如下命令：

　　

4、停止 RDB 持久化

　　有些情况下，我们只想利用Redis的缓存功能，并不像使用 Redis 的持久化功能，那么这时候我们最好停掉 RDB 持久化。可以通过上面讲的在配置文件 redis.conf 中，可以注释掉所有的 save 行来停用保存功能或者直接一个空字符串来实现停用：save ""

　　也可以通过命令：

redis-cli config set save " "

5、RDB 的优势和劣势

　　①、优势

　　1.RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。

　　2.生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

　　3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

　　②、劣势

　　1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，如果不采用压缩算法(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)

　　2、RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)

　　3、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)

6、RDB 自动保存的原理

　　Redis有个服务器状态结构：

struct redisService{
     //1、记录保存save条件的数组
     struct saveparam *saveparams;
     //2、修改计数器
     long long dirty;
     //3、上一次执行保存的时间
     time_t lastsave;
 
}

　　①、首先看记录保存save条件的数组 saveparam，里面每个元素都是一个 saveparams 结构：

struct saveparam{
     //秒数
     time_t seconds;
     //修改数
     int changes;
};

　　前面我们在 redis.conf 配置文件中进行了关于save 的配置：

save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存

　　那么服务器状态中的saveparam 数组将会是如下的样子：

　　

　　②、dirty 计数器和lastsave 属性

　　dirty 计数器记录距离上一次成功执行 save 命令或者 bgsave 命令之后，Redis服务器进行了多少次修改（包括写入、删除、更新等操作）。

　　lastsave 属性是一个时间戳，记录上一次成功执行 save 命令或者 bgsave 命令的时间。

　　通过这两个命令，当服务器成功执行一次修改操作，那么dirty 计数器就会加 1，而lastsave 属性记录上一次执行save或bgsave的时间，Redis 服务器还有一个周期性操作函数 severCron ,默认每隔 100 毫秒就会执行一次，该函数会遍历并检查 saveparams 数组中的所有保存条件，只要有一个条件被满足，那么就会执行 bgsave 命令。

　　执行完成之后，dirty 计数器更新为 0 ，lastsave 也更新为执行命令的完成时间。

上一篇文章我们介绍了Redis的RDB持久化，RDB 持久化存在一个缺点是一定时间内做一次备份，如果redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)。对于数据完整性要求很严格的需求，怎么解决呢？

　　本篇博客接着来介绍Redis的另一种持久化方式——AOF。

1、AOF简介

　　Redis的持久化方式之一RDB是通过保存数据库中的键值对来记录数据库的状态。而另一种持久化方式 AOF 则是通过保存Redis服务器所执行的写命令来记录数据库状态。

　　比如对于如下命令：

　　

　　RDB 持久化方式就是将 str1,str2,str3 这三个键值对保存到 RDB文件中，而 AOF 持久化则是将执行的 set,sadd,lpush 三个命令保存到 AOF 文件中。

2、AOF 配置

　　在 redis.conf 配置文件的 APPEND ONLY MODE 下：

　　

　　①、appendonly：默认值为no，也就是说redis 默认使用的是rdb方式持久化，如果想要开启 AOF 持久化方式，需要将 appendonly 修改为 yes。

　　②、appendfilename ：aof文件名，默认是"appendonly.aof"

　　③、appendfsync：aof持久化策略的配置；

　　　　　　no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；

　　　　　　always表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低；

　　　　　　everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。

　　④、no-appendfsync-on-rewrite：在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。默认值为no。

　　⑤、auto-aof-rewrite-percentage：默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。

　　⑥、auto-aof-rewrite-min-size：64mb。设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。

　　⑦、aof-load-truncated：aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项，出现这种现象 redis宕机或者异常终止不会造成尾部不完整现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。默认值为 yes。

3、开启 AOF

　　将 redis.conf 的 appendonly 配置改为 yes 即可。

　　AOF 保存文件的位置和 RDB 保存文件的位置一样，都是通过 redis.conf 配置文件的 dir 配置：

　　

　　可以通过 config get dir 命令获取保存的路径。

4、AOF 文件恢复

　　重启 Redis 之后就会进行 AOF 文件的载入。

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

5、 AOF 重写

　　由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令 bgrewriteaof 来重新。

　　比如对于如下命令：

　　

　　如果不进行 AOF 文件重写，那么 AOF 文件将保存四条 SADD 命令，如果使用AOF 重写，那么AOF 文件中将只会保留下面一条命令：

sadd animals "dog" "tiger" "panda" "lion" "cat"

　　也就是说 AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。

　　AOF 文件重写触发机制：通过 redis.conf 配置文件中的 auto-aof-rewrite-percentage：默认值为100，以及auto-aof-rewrite-min-size：64mb 配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

　　这里再提一下，我们知道 Redis 是单线程工作，如果重写 AOF 需要比较长的时间，那么在重写 AOF 期间，Redis将长时间无法处理其他的命令，这显然是不能忍受的。Redis为了克服这个问题，解决办法是将 AOF 重写程序放到子程序中进行，这样有两个好处：

　　①、子进程进行 AOF 重写期间，服务器进程（父进程）可以继续处理其他命令。

　　②、子进程带有父进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

　　使用子进程解决了上面的问题，但是新问题也产生了：因为子进程在进行 AOF 重写期间，服务器进程依然在处理其它命令，这新的命令有可能也对数据库进行了修改操作，使得当前数据库状态和重写后的 AOF 文件状态不一致。

　　为了解决这个数据状态不一致的问题，Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区是在创建子进程后开始使用，当Redis服务器执行一个写命令之后，就会将这个写命令也发送到 AOF 重写缓冲区。当子进程完成 AOF 重写之后，就会给父进程发送一个信号，父进程接收此信号后，就会调用函数将 AOF 重写缓冲区的内容都写到新的 AOF 文件中。

　　这样将 AOF 重写对服务器造成的影响降到了最低。

6、AOF的优缺点

　　优点：

　　①、AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。

　　②、AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。

　　③、AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

　　缺点：

　　①、对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。

　　②、虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。

　　③、RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。

　　那么对于 AOF 和 RDB 两种持久化方式，我们应该如何选择呢？

　　如果可以忍受一小段时间内数据的丢失，毫无疑问使用 RDB 是最好的，定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，而且使用 RDB 还可以避免 AOF 一些隐藏的 bug；否则就使用 AOF 重写。但是一般情况下建议不要单独使用某一种持久化机制，而是应该两种一起用，在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。Redis后期官方可能都有将两种持久化方式整合为一种持久化模型。

7、RDB-AOF混合持久化

　　这里补充一个知识点，在Redis4.0之后，既上一篇文章介绍的RDB和这篇文章介绍的AOF两种持久化方式，又新增了RDB-AOF混合持久化方式。

　　这种方式结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。

　　具体配置为：

aof-use-rdb-preamble

　　设置为yes表示开启，设置为no表示禁用。

　　当开启混合持久化时，主进程先fork出子进程将现有内存副本全量以RDB方式写入aof文件中，然后将缓冲区中的增量命令以AOF方式写入aof文件中，写入完成后通知主进程更新相关信息，并将新的含有 RDB和AOF两种格式的aof文件替换旧的aof文件。

　　简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。

　　这种方式优点我们很好理解，缺点就是不能兼容Redis4.0之前版本的备份文件了。

前面介绍Redis，我们都在一台服务器上进行操作的，也就是说读和写以及备份操作都是在一台Redis服务器上进行的，那么随着项目访问量的增加，对Redis服务器的操作也越加频繁，虽然Redis读写速度都很快，但是一定程度上也会造成一定的延时，那么为了解决访问量大的问题，通常会采取的一种方式是主从架构Master/Slave，Master 以写为主，Slave 以读为主，Master 主节点更新后根据配置，自动同步到从机Slave 节点。

　　接下来我们就来介绍如何进行主从架构的搭建。

　　ps:这里我是在一台机器上模拟多个Redis服务器，与实际生产环境中相比，基本配置都是一样，仅仅是IP地址和端口号变化。

　　

1、修改配置文件

　　首先将redis.conf 配置文件复制三份，通过修改端口分别模拟三台Redis服务器。

　　

　　然后我们分别对这三个redis.conf 文件进行修改。

　　①、修改 daemonize yes

　　

　　表示指定Redis以守护进程的方式启动（后台启动）

　　②、配置PID文件路径 pidfile

　　

　　表示当redis作为守护进程运行的时候，它会把 pid 默认写到 /var/redis/run/redis_6379.pid 文件里面

　　③、配置端口 port

　　

　　④、配置log 文件名字

　　

　　⑤、配置rdb文件名

　　

　　依次将 6380redis.conf 、6381redis.conf 配置一次，则配置完毕。

　　接下来我们分别启动这三个服务。

　　

　　通过命令查看Redis是否启动：

　　

　　接下来通过如下命令分别进入到这三个Redis客户端：

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

　　注意:如果修改端口了,启动redis-cli 命令,比如加上 -p 端口,否则连接不上.如果密码也修改了,则还得添加密码 -a 密码指令来连接.

2、设置主从关系

　　①、通过 info replication 命令查看节点角色

　　

　　

　　我们发现这三个节点都是扮演的 Master 角色。那么如何将 6380 和 6381 节点变为 Slave 角色呢？

　　②、选择6380端口和6381端口，执行命令：SLAVEOF 127.0.0.1 6379

　　

　　我们再看 6379 节点信息：

　　

　　这里通过命令来设置主从关系，一旦服务重启，那么角色关系将不复存在。想要永久的保存这种关系，可以通过配置redis.conf 文件来配置。

slaveof 127.0.0.1 6379

3、测试主从关系

　　①、增量复制

　　主节点执行 set k1 v1 命令，从节点 get k1 能获取吗？

　　

　　

　　

　　由上图可知是可以获取的。

　　②、全量复制

　　通过执行 SLAVEOF 127.0.0.1 6379，如果主节点 6379 以前还存在一些 key，那么执行命令之后，从节点会将以前的信息也都复制过来吗？

　　答案也是肯定的，这里我就不贴测试结果了。

　　③、主从读写分离

　　主节点能够执行写命令，从节点能够执行写命令吗？

　　

　　这里的原因是在配置文件 6381redis.conf 中对于 slave-read-only 的配置

　　

　　如果我们将其修改为 no 之后，执行写命令是可以的。

　　

　　但是从节点写命令的数据从节点或者主节点都不能获取的。

　　④、主节点宕机

　　主节点 Maste 挂掉，两个从节点角色会发生变化吗？

　　

　　

　　上图可知主节点 Master 挂掉之后，从节点角色还是不会改变的。

　　⑤、主节点宕机后恢复

　　主节点Master挂掉之后，马上启动主机Maste，主节点扮演的角色还是 Master 吗？

　　

　　也就是说主节点挂掉之后重启，又恢复了主节点的角色。

4、哨兵模式

　　通过前面的配置，主节点Master 只有一个，一旦主节点挂掉之后，从节点没法担起主节点的任务，那么整个系统也无法运行。如果主节点挂掉之后，从节点能够自动变成主节点，那么问题就解决了，于是哨兵模式诞生了。

　　哨兵模式就是不时地监控redis是否按照预期良好地运行（至少是保证主节点是存在的），若一台主机出现问题时，哨兵会自动将该主机下的某一个从机设置为新的主机，并让其他从机和新主机建立主从关系。

　　

　　哨兵模式搭建步骤：

　　①、在配置文件目录下新建 sentinel.conf 文件，名字绝不能错，然后配置相应内容

　　　

sentinel monitor 被监控机器的名字(自己起名字) ip地址 端口号 得票数

　　

　　分别配置被监控的名字，ip地址，端口号，以及得票数。上面的得票数为1表示表示主机挂掉后salve投票看让谁接替成为主机，得票数大于1便成为主机

　　②、启动哨兵

redis-sentinel /etc/redis/sentinel.conf

　　启动界面：

　　

　　接下来，我们干掉主机 6379，然后看从节点有啥变化。

　　

　　干掉主节点之后，我们查看后台打印日志，发现 6381投票变为主节点了。

　　

　　这时候我们查看从节点 6381的节点信息：

　　

　　6381 节点自动变为主节点了。

　　PS：哨兵模式也存在单点故障问题，如果哨兵机器挂了，那么就无法进行监控了，解决办法是哨兵也建立集群，Redis哨兵模式是支持集群的。

5、主从复制原理

　　Redis的复制功能分为同步（sync）和命令传播（command propagate）两个操作。

　　①、旧版同步

　　当从节点发出 SLAVEOF 命令，要求从服务器复制主服务器时，从服务器通过向主服务器发送 SYNC 命令来完成。该命令执行步骤：

　　1、从服务器向主服务器发送 SYNC 命令

　　2、收到 SYNC 命令的主服务器执行 BGSAVE 命令，在后台生成一个 RDB 文件，并使用一个缓冲区记录从开始执行的所有写命令

　　3、当主服务器的 BGSAVE 命令执行完毕时，主服务器会将 BGSAVE 命令生成的 RDB 文件发送给从服务器，从服务器接收此 RDB 文件，并将服务器状态更新为RDB文件记录的状态。

　　4、主服务器将缓冲区的所有写命令也发送给从服务器，从服务器执行相应命令。

　　②、命令传播

　　当同步操作完成之后，主服务器会进行相应的修改命令，这时候从服务器和主服务器状态就会不一致。

　　为了让主服务器和从服务器保持状态一致，主服务器需要对从服务器执行命令传播操作，主服务器会将自己的写命令发送给从服务器执行。从服务器执行相应的命令之后，主从服务器状态继续保持一致。

　　总结：通过同步操作以及命令传播功能，能够很好的保证了主从一致的特性。

　　但是我们考虑一个问题，如果从服务器在同步主服务器期间，突然断开了连接，而这时候主服务器进行了一些写操作，这时候从服务器恢复连接，如果我们在进行同步，那么就必须将主服务器从新生成一个RDB文件，然后给从服务器加载，这样虽然能够保证一致性，但是其实断开连接之前主从服务器状态是保持一致的，不一致的是从服务器断开连接，而主服务器执行了一些写命令，那么从服务器恢复连接后能不能只要断开连接的哪些写命令，而不是整个RDB快照呢？

　　同步操作其实是一个非常耗时的操作，主服务器需要先通过 BGSAVE 命令来生成一个 RDB 文件，然后需要将该文件发送给从服务器，从服务器接收该文件之后，接着加载该文件，并且加载期间，从服务器是无法处理其他命令的。

　　为了解决这个问题，Redis从2.8版本之后，使用了新的同步命令 PSYNC 来代替 SYNC 命令。该命令的部分重同步功能用于处理断线后重复制的效率问题。也就是说当从服务器在断线后重新连接主服务器时，主服务器只将断开连接后执行的写命令发送给从服务器，从服务器只需要接收并执行这些写命令即可保持主从一致。

6、主从复制的缺点

　　主从复制虽然解决了主节点的单点故障问题，但是由于所有的写操作都是在 Master 节点上操作，然后同步到 Slave 节点，那么同步就会有一定的延时，当系统很繁忙的时候，延时问题就会更加严重，而且会随着从节点slave的增多而愈加严重。

posted @ 2022-02-15 20:00 hanease 阅读(2419) 评论(0) 编辑收藏举报

刷新页面返回顶部