《Redis入门指南》最后三章简介

最新推荐文章于 2024-07-17 17:18:59 发布

trouble-i-am-in

最新推荐文章于 2024-07-17 17:18:59 发布

阅读量726

点赞数

分类专栏： redis 文章标签： redis

redis 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

原来太看得起自己写了一篇详细篇，后来发现我只是把书上的话重新抄了一遍，结果写到后面自己都云里雾里了，所以我把那篇删掉重写。

这篇文章的重点是简单介绍 Redis 的这些特性，但是不涉及具体的操作，那不是我的能力之内的，我也没自信讲清楚，适合第一次接触 Redis，想先了解一个大概的人。

第七章--持久化

我们知道 Redis 是缓存在内存中的，数据库关闭或者服务器关闭都会导致数据的丢失，所以 Redis 为了保存数据，就会把一些信息存储到硬盘中，缓存消失后可以凭借这些信息来恢复数据，这些信息包括现有的存储在内存中的数据，用户输入的指令，这两种数据分别靠不同的方式保存在硬盘中，RDB方式与AOF方式。

RDB方式

RDB方式主要是通过快照的形式来存储用户的数据的，快照的具体实现还是很容易理解的，下面具体讲。快照分为人为手工执行与自动执行。人为手工执行可以使用 SAVE 和 BGSAVE，两者的区别是，输入 SAVE 命令后，客户端进入拒绝服务状态，直接使用快照方式将数据写入硬盘，直到写入完成才允许用户接着输入命令，BGSAVE 则会在后台执行将数据存入硬盘中，期间用户还是正常执行命令的。但是这样不是存在矛盾吗？万一用户修改的一个数据恰巧正被用户输入的指令修改呢？其实是不会存在问题的，看了接下来讲解的快照原理就理解了。讲了手动开始存储，接下来讲解自动执行快照的配置。看 Redis 的配置文件，其中有这么三行，我是 windows 下安装 Redis。

这三行的格式是 save m n，m 代表时间间隔，单位是秒，n 代表键的数量，key 的数量，这里的三行代表的条件满足的话，会自动触发快照来存储数据。

save 900 1

拿这个来举例子，这个配置代表在900秒内有1个键被访问的话，注意这里的访问的含义，包括修改、删除、读取等操作都包括在访问的意义内，特别是 flushall 这种一次性操作多个键的命令，都会触发这个条件，执行快照保存数据。这些设置一般是根据个人需求来设置的，而且数量也不定。

快照原理

当我们使用客户端操作 Redis 数据库时，一旦开始执行快照，系统会自动复制一份当前进程(客户端执行的程序)的副本，即子进程，原进程叫父进程，父进程继续接收用户输入的命令并执行，子进程负责将数据存储成 RDB 文件(这时没有直接写入内存)，但是注意一点，系统没有把原始数据全部复制一份给子进程，而是让子进程和父进程共享一个内存，只是将当前子进程需要的数据复制一份给子进程，这样即使子进程正在存储的数据正被用户修改着，也只是让子进程存储的是修改前的数据，却不会造成混乱。当子进程完成数据的存储时，就把子进程生成的 RDB 文件替换硬盘中的旧的 RDB 文件，到此为止，一次快照完成。

AOF 方式

前面存储的是数据，AOF 方式则是存储用户输入的命令，生成的文件是 AOF 文件，与 RDB 文件存储在同一路径下，开启 AOF 后，用户每个输入的命令都会被存储。可以单独开启 AOF 方式或者 RDB 方式，但是一般情况下是将两者都开启的。AOF 也有一些配置参数，这里不详细讲了。

第八章--集群

前面我们讲了配置 Redis 的持久性，但是假设一个情况，当部署 Redis 的服务器崩溃了，这时即使数据库数据都保存在硬盘中没有损失，但是也没有办法使用了，所以对于一些比较大型的应用都会配置主从数据的，主数据库执行大部分操作，而且会将数据同步到从数据中，从数据充当一个备胎的角色，当主数据崩溃后，从数据就升级成主数据库来继续工作，这一章的内容就是关于主从数据库的。一个主数据库可能不止配置一个从数据库，而且从数据库也可以发展自己的从数据库，简而言之，对于从数据库来说，主数据库只有一个，但是对于主数据库从数据库可以有很多个。

主从数据库数据同步原理

前面讲过主从数据库的数据是同步的，那么是怎么实现的，首先主数据库使用第七章讲解的快照生成 RDB 文件，并在生成 RDB 文件的期间缓存用户的输入命令，之后把生成的 RDB 文件和缓存的命令发送给从数据库，从数据库就靠这些信息自动生成数据，这一过程称为--复制的初始化阶段，完成这一阶段之后主数据库会把之后用户输入的命令异步的发送给从数据库，注意这里是异步的发送之后接收的命令，也就是主从数据库的数据不是实时相同的，是存在一定时差的。

这时假设一种情况，在完成复制初始化阶段之后，主数据库还没来得及把最新的命令发送给从数据库，从数据库就断开了连接，这时主数据库怎么办呢？

这时主数据库会根据两个配置参数决定接下来的行动：

min-slaves-to write x

min-slaves-max-lag y

第一个参数表示当前连接的从数据库数量只有大于或等于 x，主数据库才允许用户修改，如果小于 x，则拒绝服务。

第二个参数表示允许从数据库断线重连的最大时间，如果从数据库在该时间内重新连接上主数据库，主数据库则采用--增量复制来修复从数据库的数据，这个下面会讲。但是一旦超过这个时间，则需要再次执行一次前面讲过的主从数据库同步过程。

增量复制

我们看主从数据库的同步原理发现，如果每次从数据库断线重连都要重复一遍这样的过程，无疑是麻烦的，特别是从数据库只是缺失了一些命令的情况下，所以 Redis 主数据库会缓存用户的命令，并且为每个命令设置一个偏移量，凭借这个偏移量就可以使从数据库根据自己的命令的偏移量来查询自己还需要的命令，之后主数据库就把从数据库缺失的命令发给他，而不需要再执行一遍主从数据同步。

哨兵

所谓哨兵就是随着 Redis 配置而开启的一个进程，因为职责跟哨兵很像，所以取名叫哨兵。还记得我们提出主从数据库时说的从数据库转主数据库，主数据库转从数据库吗？如果我们手工去执行的话，那么就需要人为的发现问题再去解决，可是可以配置哨兵来监控这一行为，并在主数据库崩溃后自动将从数据库升级成主数据库，主数据库自动降级成从数据库，这一切只需要设置好哨兵的配置，在问题出现时，哨兵会自动解决。

为了实现上述的要求与哨兵自己内部的通信，哨兵需要监控他负责的主数据库与从数据库，而且是多个哨兵监控同一主从数据库才行，具体原因看了下面的哨兵的工作原理就知道了。

哨兵工作流程及其解释

1 每10秒哨兵会向主数据库发送 info 命令

2 每2秒哨兵会向主数据库和从数据库的 __sentinel__:hello 频道发送自己的信息

3 每1秒哨兵会向主数据库、从数据库和其他哨兵发送 ping 命令

一个一个来解释

1 不用管 info 命令到底是什么，只需要知道他的具体作用是什么就行了，这条命令会要求主数据库将他的从数据库信息全部发送给哨兵，哨兵则根据这些信息去连接从数据库，同样向他们发送 info 命令，请求他们的从数据库，这样哨兵就可以监控该主数据库下所有的从数据库了，哨兵也是靠这样的做法发现新加入的数据库的。

2 这个频道( channel )是默认开启的，监控该数据库的哨兵都会自动订阅该频道，可以这么理解，这就是为哨兵开启的一条他们互相发送消息的通道，哨兵间就靠这个互相确认对方身份以及确认对方是否是新加入的哨兵。

3 ping 命令就是向指定地址发送一些无意义的数据包，根据网络协议判断对方是否接收，哨兵凭借这一命令来判断该数据库是否连接正常。

接下来讲当出现 3 中的主数据库连接失败的解决方案。

首先该哨兵对该数据库的判断是“主观下线”，所以他会向别的同样监控该数据库的哨兵发送确认消息，询问他们是否认为该数据库“主观下线”，当达到配置参数指定的数量的哨兵确定“主观下线”后，该哨兵就该数据库判定“客观下线”，之后就在几个哨兵之间采用 Raft 算法竞选出一个哨兵首领，由该哨兵首领单独对主从数据库进行更换，保证同时只有一个进程对数据库做出修改。

哨兵的部署我也不会，所以想深究的加油！