redis持久化机制以及集群操作
时间:2019-05-21 13:43 来源:linux.it.net.cn 作者:IT
redis提供了两种持久化策略
RDB
rdb的持久化策略：按照规则，定时将内存中的数据同步到磁盘当中
snapshot
redis在指定的情况下会触发快照
1.自己配置的快照规则
2.手动执行 save或者 bgsave方法
save 执行内存的数据同步到磁盘上的操作，这个操作会阻塞客户端的请求
bgsave 在后台异步执行快照操作，这个操作不会阻塞客户端的请求
3.执行flushall的时候
清除内存中的数据，只要快照规则不为空，也就是第一个规则存在，那么redis会执行快照
4.执行复制的时候
执行复制的时候
快照文件的存在位置在 redis的bin目录下，里面有一个 dump.rdb文件
快照的实现原理：redis会使用fork函数复制一份当前进程的副本（子进程），fork进程负责把内存的数据同步到磁盘的临时文件，父进程继续处理客户端请求
redis的优缺点：
1.redis会出现数据丢失的情况，执行快照到下一次快照的过程中可能丢失数据
2.可以最大化redis的性能。
AOF
AOF策略，每次执行命令后，把命令本身记录下来
aof会把redis执行的每一条命令追加到磁盘当中。
两种持久化策略可以同时使用，也可以只使用其中的一种，如果同时使用的话，那么redis重启时，会优先使用AOF文件来还原数据。
默认在redis当中aof是没有开启的，我们可以在 redis.conf 文件中开启aof持久化策略，找到 appendonly yes 这样就开启了持久化策略
在redis中执行set命令之后可以看到在redis的bin目录下生成了一个appendonly.aof文件，这个文件中记录了 aof持久化的数据
修改redis.conf中的 appendonly yes，重启后执行对数据的变更命令，会在bin目录下生成对应的aof文件，aof文件中会记录所有的操作命令，如下两个参数可以去对aof文件做优化。
在redis.conf文件中还有这样两个属性
auto-aof-rewrite-percentage 100 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写，如果之前没有重写过，以启动时aof文件大小为准
auto-aof-rewrite-min-size 64mb 限制允许重写最小aof文件大小，也就是文件大小小于64m的时候不需要进行优化。
aof重写的原理
aof重写的整个过程是安全的，
同步磁盘数据，redis每次更改数据的时候，aof机制都会将命令记录到aof文件，但是实际上由于操作系统的缓存机制，数据并没有实时的写入到硬盘，而是进入到硬盘的缓存，再通过硬盘缓存机制刷新保存到文件。
appendfsync always 每次执行写入都会进行同步，这个是最安全但是效率比较低的方式
appendfsync everysec 每一秒执行一次
appendfsync no 不主动进行同步操作，由操作系统去执行，这个是最快但是最不安全的方式
aof文件损坏之后如何修复
通过 redis-check-aof-fix 命令对原来的文件进行修复
redis的集群
复制 （master、slave）
哨兵机制
集群
安装redis，然后make，make install PREFIX=/usr/local/redis 然后把安装目录下的 redis.conf 文件拷贝到 启动目录下
redis集群操作，首先先找到 redis.conf目录下的
bind 127.0.0.1 注释掉
daemonize属性设置成 yes
protected-mode no
把改好的redis复制多份到其他的机器上
然后选择一台机器作为主master的redis节点，其他的作为 slave的节点，在slave的节点的 redis.conf中配置下面的信息。
找到 slaveof ip port 给这个属性配置上相应的 master节点的 ip和port（默认6379)
然后把三台服务器都重新启动
使用 redis-cli 命令进入到redis的控制台执行 info replication命令可以看到下面的信息：
代表这台机器是redis中的master机器
在master中set一条值 set aaa xxx
然后可以在slave这个节点中获取到 aaa的实际值 get aaa
但是如果在从服务器上set值的话会报错
实现原理
slave第一次或者重连接到master上以后，会向master发送一个 SYNC的命令
master收到 SYNC的时候会做两件事情，
a)执行 bgsave (rdb快照文件)
b)master会把新收到的数据修改命令存入到缓冲区，
可以通过 replconf listening-port 6379 这个命令来检测 master上发出的指令
为了不使slave读取的时候出现脏数据
需要在 slave那端的 redis.conf文件中更改上面的配置
slave-server-stale-data yes 这个配置的含义是必须要完成一个master的同步之后才能去做接下来的操作，否则，读取都会报错。
slave中无法对数据进行写的操作，没有办法对master进行动态选举
复制的方式
1.基于rdb文件的复制
2.无硬盘复制
3.增量复制
redis中的哨兵机制
通过哨兵机制去监控服务器master的状态。
使用redis当中的哨兵机制
首先把 redis安装包下的seentinel.conf 文件拷贝到运行目录下的 sentinel.conf下。
该文件中的port 参数表示的是哨兵监控的端口号，
有一个这样的配置 sentinel monitor mymaster 127.0.0.1 6379 2 ，后面的三个参数表示的意思是监控的主机、监控的端口号、控制有多少投票数（如果三个哨兵集群的话最少两个哨兵投票同意才生效）
sentinel down-after-milliseconds mymaster 30000，这个配置表示的意思是 30秒内如果没有连上则表示已经宕机
redis的哨兵启动
./redis-sentinel ../sentinel.conf
启动之后也同样出现了启动redis的界面
然后这里做一个 让主机 ./redis-cli shutdown 这样的操作，可以看到哨兵的控制台会进行 master的重新选举操作。
重新投票选举出来新的 master机器，
redis中的集群原理
slot槽的概念，在redis当中一共有 16384个槽
根据 key的 CRC16算法，得到的结果再对 16384进行取模，假如有三个节点 16384/3 = 5000多个槽
node1 0 5460
node2 5461 10922
node3 10923 16383
当出现第四个节点的时候，就会出现节点数据的重新分配，涉及到数据的迁移，会从每个节点拿个数据到node4节点
(责任编辑：IT)
redis提供了两种持久化策略
RDB
rdb的持久化策略：按照规则，定时将内存中的数据同步到磁盘当中
snapshot
redis在指定的情况下会触发快照
1.自己配置的快照规则
2.手动执行 save或者 bgsave方法
save 执行内存的数据同步到磁盘上的操作，这个操作会阻塞客户端的请求
bgsave 在后台异步执行快照操作，这个操作不会阻塞客户端的请求
3.执行flushall的时候
清除内存中的数据，只要快照规则不为空，也就是第一个规则存在，那么redis会执行快照
4.执行复制的时候
执行复制的时候
快照文件的存在位置在 redis的bin目录下，里面有一个 dump.rdb文件
快照的实现原理：redis会使用fork函数复制一份当前进程的副本（子进程），fork进程负责把内存的数据同步到磁盘的临时文件，父进程继续处理客户端请求
redis的优缺点：
1.redis会出现数据丢失的情况，执行快照到下一次快照的过程中可能丢失数据
2.可以最大化redis的性能。
AOF
AOF策略，每次执行命令后，把命令本身记录下来
aof会把redis执行的每一条命令追加到磁盘当中。
两种持久化策略可以同时使用，也可以只使用其中的一种，如果同时使用的话，那么redis重启时，会优先使用AOF文件来还原数据。
默认在redis当中aof是没有开启的，我们可以在 redis.conf 文件中开启aof持久化策略，找到 appendonly yes 这样就开启了持久化策略
在redis中执行set命令之后可以看到在redis的bin目录下生成了一个appendonly.aof文件，这个文件中记录了 aof持久化的数据
修改redis.conf中的 appendonly yes，重启后执行对数据的变更命令，会在bin目录下生成对应的aof文件，aof文件中会记录所有的操作命令，如下两个参数可以去对aof文件做优化。
在redis.conf文件中还有这样两个属性
auto-aof-rewrite-percentage 100 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写，如果之前没有重写过，以启动时aof文件大小为准
auto-aof-rewrite-min-size 64mb 限制允许重写最小aof文件大小，也就是文件大小小于64m的时候不需要进行优化。
aof重写的原理
aof重写的整个过程是安全的，
同步磁盘数据，redis每次更改数据的时候，aof机制都会将命令记录到aof文件，但是实际上由于操作系统的缓存机制，数据并没有实时的写入到硬盘，而是进入到硬盘的缓存，再通过硬盘缓存机制刷新保存到文件。
appendfsync always 每次执行写入都会进行同步，这个是最安全但是效率比较低的方式
appendfsync everysec 每一秒执行一次
appendfsync no 不主动进行同步操作，由操作系统去执行，这个是最快但是最不安全的方式
aof文件损坏之后如何修复
通过 redis-check-aof-fix 命令对原来的文件进行修复
redis的集群
复制 （master、slave）
哨兵机制
集群
安装redis，然后make，make install PREFIX=/usr/local/redis 然后把安装目录下的 redis.conf 文件拷贝到 启动目录下
redis集群操作，首先先找到 redis.conf目录下的
bind 127.0.0.1 注释掉
daemonize属性设置成 yes
protected-mode no
把改好的redis复制多份到其他的机器上
然后选择一台机器作为主master的redis节点，其他的作为 slave的节点，在slave的节点的 redis.conf中配置下面的信息。
找到 slaveof ip port 给这个属性配置上相应的 master节点的 ip和port（默认6379)
然后把三台服务器都重新启动
使用 redis-cli 命令进入到redis的控制台执行 info replication命令可以看到下面的信息：
代表这台机器是redis中的master机器
在master中set一条值 set aaa xxx
然后可以在slave这个节点中获取到 aaa的实际值 get aaa
但是如果在从服务器上set值的话会报错
实现原理
slave第一次或者重连接到master上以后，会向master发送一个 SYNC的命令
master收到 SYNC的时候会做两件事情，
a)执行 bgsave (rdb快照文件)
b)master会把新收到的数据修改命令存入到缓冲区，
可以通过 replconf listening-port 6379 这个命令来检测 master上发出的指令
为了不使slave读取的时候出现脏数据
需要在 slave那端的 redis.conf文件中更改上面的配置
slave-server-stale-data yes 这个配置的含义是必须要完成一个master的同步之后才能去做接下来的操作，否则，读取都会报错。
slave中无法对数据进行写的操作，没有办法对master进行动态选举
复制的方式
1.基于rdb文件的复制
2.无硬盘复制
3.增量复制
redis中的哨兵机制
通过哨兵机制去监控服务器master的状态。
使用redis当中的哨兵机制
首先把 redis安装包下的seentinel.conf 文件拷贝到运行目录下的 sentinel.conf下。
该文件中的port 参数表示的是哨兵监控的端口号，
有一个这样的配置 sentinel monitor mymaster 127.0.0.1 6379 2 ，后面的三个参数表示的意思是监控的主机、监控的端口号、控制有多少投票数（如果三个哨兵集群的话最少两个哨兵投票同意才生效）
sentinel down-after-milliseconds mymaster 30000，这个配置表示的意思是 30秒内如果没有连上则表示已经宕机
redis的哨兵启动
./redis-sentinel ../sentinel.conf
启动之后也同样出现了启动redis的界面
然后这里做一个 让主机 ./redis-cli shutdown 这样的操作，可以看到哨兵的控制台会进行 master的重新选举操作。
重新投票选举出来新的 master机器，
redis中的集群原理
slot槽的概念，在redis当中一共有 16384个槽
根据 key的 CRC16算法，得到的结果再对 16384进行取模，假如有三个节点 16384/3 = 5000多个槽
node1 0 5460
node2 5461 10922
node3 10923 16383
当出现第四个节点的时候，就会出现节点数据的重新分配，涉及到数据的迁移，会从每个节点拿个数据到node4节点
|