3.1 持久化
Redis 提供了多种不同级别的持久化方式：
- RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
- AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
- Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
3.1.1RDB(Redis DataBase)
Rdb:在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的 snapshot 快照，它恢复时就是将快照文件直接读到内存里。
Redis 会单独的创建(fork) 一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了，再用这个临时文件替换上次持久化还的文件。整个过程总，主进程是不进行任何 IO 操作，这就确保了极高的性能，如果需要进行大规模的数据恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方法要比 AOF 方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失。
Rdb 保存的是 dump.rdb 文件
在测试：执行 flushAll 命令, 使用 shutDown 直接关闭进程时，第二次打开时 redis 会自动读取 dump.rdb 文件，但是恢复时，全为空。(此时的原因：在关闭时刻，redis 系统会保存空的 dump.rdb 替换原来的缓存文件。所以第二次打开的 redis系统时候，自动读取的是空值文件)
RDB save 操作
Rdb 是整个内存的压缩的 snapshot，RDB 的数据结构，可以配置符合快照触发条件，默认的是 1 分钟内改动 1 万次，或者 5 分钟改动 10 次，或者是 15 分钟改动一次；
如何触发 RDB 快照
Save：save 时只管保存，其他不管，全部阻塞。
Bgsave：redis 会在后台进行快照操作，快照操作的同时还可以响应客户端的请求，可以通过 lastsave 命令获取最后一次成功执行快照的时间。
执行 flushall 命令，也会产生 dump.rdb 文件，但里面是空的。
如何恢复:
将备份文件(dump.rdb)移动到 redis 安装目录并启动服务即可
Config get dir 命令可获取目录
如何停止
动态停止 RDB 保存规则的方法：redis -cli config set save “”
3.1.2AOF(Append Only File)
以日志的形式俩记录每个写操作，将 redis 执行过的所有写指令记录下来(读操作不记录)。只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次一完成数据恢复工作。
开启aof:appendonly yes
aof文件损坏：(网络传输或者其他问题导致 aof 文件破坏)服务器启动报错(但是 dump.rdb 文件是完整的) 说明启动先加载 aof 文件
解决方案：执行命令 redis-check-aof --fix aof 文件 [自动检查删除不和 aof 语法的字段]
aof策略：Appendfsync 参数：
Always 同步持久化 每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性较好。
Everysec： 出厂默认推荐，异步操作，每秒记录，日过一秒宕机，有数据丢失
Rewrite
概念：AOF 采用文件追加方式，文件会越来越来大为避免出现此种情况，新增了重写机制，aof 文件的大小超过所设定的阈值时，redis 就会自动 aof 文件的内容压缩，值保留可以恢复数据的最小指令集，可以使用命令 bgrewirteaof。
重写原理：aof 文件持续增长而大时，会 fork 出一条新进程来将文件重写(也就是先写临时文件最后再 rename)，遍历新进程的内存中的数据，每条记录有一条 set 语句，重写 aof 文件的操作，并没有读取旧的的 aof 文件，而是将整个内存的数据库内容用命令的方式重写了一个新的 aof 文件，这点和快照有点类似。
触发机制：redis 会记录上次重写的 aof 的大小，默认的配置当 aof 文件大小上次 rewrite 后大小的一倍且文件大于 64M 触发(3G)
no-appendfsync-on-rewrite no : 重写时是否可以运用 Appendfsync 用默认 no 即可，保证数据安全
auto-aof-rewrite-percentage 倍数 设置基准值
auto-aof-rewrite-min-size 设置基准值大小
AOF优点：
1、数据防丢失（）
2、数据可恢复（AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存，举例：
对于误操作flashall可以， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 flashall命令。）
3、文件重写（因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作）4、写入不需要进行 seek（AOF 文件是一个只进行追加操作的日志文件（append only log），即使偶发的网路异常，也可使用redis-check-aof 工具修复）
AOF缺点：数据文件大，恢复数据慢。
3.2 主从复制
Redis 支持简单且易用的主从复制（master-slave replication）功能， 该功能可以让从服务器(slave server)成为主服务器(master server)的精确复制品。
以下是关于 Redis 复制功能的几个重要方面：
- Redis 使用异步复制。 从 Redis 2.8 开始， 从服务器会以每秒一次的频率向主服务器报告复制流（replication stream）的处理进度。
- 一个主服务器可以有多个从服务器。
- 不仅主服务器可以有从服务器， 从服务器也可以有自己的从服务器， 多个从服务器之间可以构成一个图状结构。
- 复制功能不会阻塞主服务器： 即使有一个或多个从服务器正在进行初次同步， 主服务器也可以继续处理命令请求。
- 复制功能也不会阻塞从服务器： 只要在 redis.conf 文件中进行了相应的设置， 即使从服务器正在进行初次同步， 服务器也可以使用旧版本的数据集来处理命令查询。（ 在从服务器删除旧版本数据集并载入新版本数据集的那段时间内， 连接请求会被阻塞。）
- 复制功能可以单纯地用于数据冗余（data redundancy）， 也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）： 比如说， 繁重的 SORT 命令可以交给附属节点去运行。
- 可以通过复制功能来让主服务器免于执行持久化操作： 只要关闭主服务器的持久化功能， 然后由从服务器去执行持久化操作即可。
关于数据安全：所以应该禁止主服务器关闭持久化的同时自动拉起。
从服务器配置：
配置一个从服务器非常简单， 只要在配置文件中增加以下的这一行就可以了：
slaveof 192.168.1.1 6379
从 Redis 2.6 开始， 从服务器支持只读模式， 并且该模式为从服务器的默认模式。参数：redis.conf 文件中的 slave-read-only
Redis主从复制可以根据是否是全量分为全量同步和增量同步。
3.2.1 全量同步
完成上面几个步骤后就完成了从服务器数据初始化的所有操作，从服务器此时可以接收来自用户的读请求。
值得注意的是，当多个Slave尝试连接同一个Master进行全量同步的时候，Redis为尽可能地减少复制所需的工作，设定了两种处理情形：
| 当有新的Slave连接Master时 | Master的处理策略 |
|---|---|
| 步骤3尚未执行 | 所有Slave都会接收到相同的快照文件 |
| 步骤3正在执行或已执行 | 待当前的同步流程执行完毕后，对新的Slave重新执行一遍同步流程。 |
由于Redis在复制进行期间，还会尽可能地处理接收的命令请求。为保障Master有足够的内存来创建子进程和创建用于存储写操作命令的缓冲区等操作，同时又不影响Redis处理命令请求的效率，在实际的操作过程中，最好使得主服务器预留30%~45%的内存用于执行上述操作。
3.2.2 增量同步
3.2.3 Redis主从同步策略
参考：
https://redis.io/topics/replication
https://www.cnblogs.com/shsxt/p/7911591.html
https://www.cnblogs.com/hepingqingfeng/p/7263782.html
扫一扫
416
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
