redis：持久化和主从复制

Redis持久化

Redis 提供了2个不同形式的持久化方式。

• RDB（ Redis DataBase）

• AOF（Append Of File）

---

RDB

RDB是什么

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

• RDB是如何执行的

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

• Fork

  • Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

  • 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”

  • 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

---

RDB的优势

• 适合大规模的数据恢复

• 对数据完整性和一致性要求不高更适合使用

• 节省磁盘空间

• 恢复速度快

---

RDB的劣势

• Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

• 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

• 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

---

redis备份

先通过config get dir 查询rdb文件的目录

将*.rdb的文件拷贝到别的地方

rdb的恢复

• 关闭Redis

• 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb

• 启动Redis, 备份数据会直接加载

---

AOF(Append Of File)

• AOF是什么

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

• AOF默认不开启

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

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

• AOF和RDB同时开启，redis听谁的？

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

• AOF文件的修复

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

cd usr/local/bin/redis/
redis-check-aof --fix appendonly.aof

---

AOF持久化流程

• 客户端的请求写命令会被append追加到AOF缓冲区内；
• AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
  • always：始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
  • everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
  • no：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
• AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
  • rewrite重写的条件：初始基准值为64MB，达到基准值的100%进行重写，将命令进行整合。

例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,

如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

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

---

优势：

• 备份机制更稳健，丢失数据概率更低。

• 可读的日志文本，通过操作AOF稳健，可以处理误操作。

---

劣势：

• 比起RDB占用更多的磁盘空间。

• 恢复备份速度要慢。

• 每次读写都同步的话，有一定的性能压力。

• 存在个别Bug，造成恢复不能。

---

用哪个好

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

---

主从复制

• 主从复制是什么

主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

• 主从复制能干嘛
  • 读写分离，性能扩展
  • 容灾快速恢复（当一台服务器坏掉了，可以快速切换到其其他服务器。主从复制是一主多从。）

---

操作

• 创建多个配置文件进行一些修改

• 启动三个redis服务

进入redis可以使用命令查看当前主机状态

info replication

在从机上使用命令

slaveof

slaveof 127.0.0.1 6379
info replication

将6380和6381变为从机。此时的主机状态：

主机写，从机读。不能使用从机进行写的操作！

(error) READONLY You can't write against a read only replica.

---

shutdowd问题

• 主服务器挂掉

从服务器仍然是从服务器，并且知道主服务挂掉。当主服务器重新连接，主服务器仍然可以查看到两个从服务器

• 从服务器挂掉

从服务器重新连接后变为主服务器，当从服务器重新变为主服务器期间，如果主服务器想数据库从存值，从服务器也能获取。

原理：

• Slave启动成功连接到master后会发送一个sync命令

• Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步

• 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

• 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步

• 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

---

薪火相传模式

使用一种链的结构：主——从——从。

缺点：中间的从机挂掉，就可能会直接瘫痪。

---

反客为主模式

当主机挂掉，选择其中的一个从机成为主机。

使用命令

slaveof no one

缺点：仍然需要手动的进行操作。

---

哨兵模式

哨兵模式是反客为主模式的增强版。当主机挂掉后，哨兵会监测到，然后哨兵就行选举，选举一个从机成为新的主机。老的主机重新连接后，会变为新主机的从机。

• 配置哨兵，创建sentinel.conf

cd /myredis/
vi sentinel.conf

• 填写内容

sentinel monitor mymaster 127.0.0.1 6379 1
# 其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。 

• 启动哨兵

redis-sentinel  /myredis/sentinel.conf 

---

选举的规则、

1. 选择优先级靠前的从机

在redis.conf中有一个叫做replica-priority的字段控制着优先级，数字越小，优先级越高

2. 选择偏移量最大的从机

哪一个从机和主机的数据最接近，就选择谁

3. 选择runid最小的从机

每个redis实例启动后都会随机生成一个40位的runid