Liunx搭建redis集群的整个过程【redis的缓存原理分析】

 2021-03-02 22:36:48







redis缓存原理的机制，半成品

学习笔记

举报

猜你喜欢

大纲/内容

解决maketest问题

分支之间是可以相互连接的

故障转移无法执行

生成dump.rdb

每次copy备份的时候，都将旧的备份数据删除

没有找到offset

AOF持久化机制的缺点

RDB快照

AOF文件快照

4.如果当前机器上的所有RDB文件全部损坏，那么从远程的云服务上拉去最新的RDB快照恢复数据

wget http://www.cpan.org/src/5.0/perl-5.16.1.tar.gz

redis中的数据是有一定限制的，不可能让redis中的数据无线增长，因为内存大小是有限制的，到达一定时间，redis会使用内部的淘汰算法例如：LRU算法，自动将一部分缓存数据，在内存中删除

冷备共性

子进程尝试将数据dump到临时的rdb快照文件中

压测进入

redis持久化机制对于故障恢复的意义

一般不是机器故障，一般是人为故障，找到RDB最新的备份，使用小时级的备份copy到redis中去，就可以恢复到某一个小时的数据

auto-aof-rewrite-min-size 64mb 这个配置可以根据自己的缓存数据量来定

输入crontab-e后，插入新的脚本

ssh-keygen -t rsa，然后一直回车生成秘钥即可

选拔从节点slave

为什么redis哨兵集群只有两个节点无法正常工作？

数据同步的核心机制

新建好四个虚拟机后，将hostname映射配置

三个实例健壮性

在redis.conf，/etc/redis_6379.conf文件配置文件为： save 60 1000

选举投票从R2，R3中选举出一个执行故障转移，自动升为master

此时再次重启redis，发现数据恢复过来了。

否则如果是slave node 第一次连接master node，那么会发送一次full resynchroization【也就是全量推送】

8.口令认证

slave node

此时客户端还再向master写入数据

第一种：repl-diskless-sync 立刻第二种：repl-diskless-sync-delay XX 等待一定时长再开始复制，因为要等更多slave重新连接过来

保证高可用

对项目的主从redis架构进行QPS压测以及水平扩容支撑更高的QPS高并发

在redis目录下新建snapshotting目录

哨兵是redis集群架构中非常重要的一个组件，主要功能如下

copy到磁盘上面，然后启动redis，在启动redis会自动从磁盘上加载丢失或者是内存中的数据

在redis.conf配置文件中将：appendonly yes 设置为yes，就可以打开AOF持久化机制

再次恢复，会被作为一个slave挂到新的master上去，自己的数据清空，重新从新的master复制数据

但是如果没有找到对应的offset，那么就会执行一次full resynchroization全量复制

向redis读取数据

大力测试

vi /etc/hosts

恢复数据

然后连接本机：ssh 本机名/IP连接就无需密码了《四台机器都需要这样操作一边》

4.有新master

如果采用了主从架构，那么必须建议开启master node的持久化机制！！！

至少要两台以上的虚拟机

时间可能是几分钟生成一次，也可以是几个小时写入一次，也可以是几天写入一次

AOF的rewrite机制回顾

故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题

例如现在是12点整，redis中有1000条数据，redis会自动生成一份RDB快照，这份RDB快照中就有1000条数据【再过了五分钟，又来了500条数据，继续生成RDB，此时RDB为1500条】

RDB持久化机制的优点：

重新连接

最后备份是在这个目录下的

font color=\"#ff0000\

故障情况

开始full resynchroization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中，RDB文件生成完毕之后，master node会将这个RDB发送给slave node，slave node会先写入本地磁盘，然后再从本地磁盘加载到内存中，然后master会内存中缓存的写命令发送给slave，slave也会同步这些数据。

启动顺序：先主后从

输入命令：./redis-benchmark -h IP地址 -c [多少客户端默认：50] -n [每秒多少QPS 默认10w] -d [多少个字节]

AOF文件出现破损，可以使用：redis-check-aof --fix命令来修复破损的AOF文件

主从复制的断点续传

命令跑下脚本：chmod 777 redis_rdb_copy_hourly.sh

redis数据写入AOF文件

redis.conf文件

PS:如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的持久化机制，如果同事使用RDB和AOF两种持久化的机制，那么redis重启的时候，会使用ADF来重新构建数据，因为ADF的数据更加完整

什么是AOF

redis_slave分支

数据写入

redis根据配置也就是redis.conf文件下的save配置，去自己尝试去生成rdb快照文件

master node不关要开启持久化机制，也最好是在云上做好冷备

slave node如果跟master node有网络故障，断开了连接，会自动重连，master如果发现多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

使用redis-3.2.8.tar.gz

AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写，因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来，再创建新日志文件的时候，老的日志文件还是照常写入，当新的merge后的日志文件ready的时候，再交换新老日志文件即可。

1.企业级持久化的配置策略

rdb save

sentinal集群

什么是RDB

cd /root/.ssh/

此时如果没有完成持久化工作，那么一但redis发生故障和出现宕机，那么所有的缓存数据就会丢失；

重新恢复

进入/usr/local

redis的配置问文件

进入/root/.ssh目录查看：cat authorized_keys应该能看到所有的秘钥

哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作

进入/etc/redis下，修改刚刚cp过来的redis.conf文件1.将daemonize 改为yes【作用：使用的是后台守护进程去跑】2.pidfile 设置成：/var/run/redis_6379.pid【作用:设置redis的pid文件位置】3.port 修改为6379【设置redis的监听端口号】4.dir【可以先搜索dbfilename】设置为：/var/redis/6379【设置持久化文件的存储位置，工作目录】

2.redis-cli -h 127.0.0.1 -p 6379 shutdown 制定要连接的ip和端口号

AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

redis将内存中的数据持久化到磁盘中

相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，会更加快速。

水平扩容，也就是说，如果服务的读取QPS增加，也很简单，继续增加redis_slave节点就可以了

RDB快照文件

在每台redis服务器上面写crontab脚本去做数据备份

linux修改静态ip地址

RDB和AOF持久化数据的工作原理

slave node

这块需要重新理解：1. master和slave都会维护一个offsetmaster会在自身不断累加offset给master，slave也会在自身不断累加offset；slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset 2. backlogmaster node有一个backlog，默认是1MB大小master node给slave node复制数据的时候，也会将数据在backlog中同步写一份 3. master run idinfo server，可以看到master run id如果根据host+ip定位master node，是不靠谱的，如果master node重启或者是数据出现了变化，那么slave node应该根据不同的run id去分，run id不同就要做全量复制的操作，如果需要不改run id 重启redis 可以使用【redis-cli debug reload】命令 4. psync从节点使用psync从master node进行复制，psync runid offsetmaster node会根据自身的情况返回响应信息，可能是 fullresync runid offset触发全量复制，可能是continue触发增量复制

master node

AOF机制对于每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重构整个数据集

即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了

如何配置RDB持久化机制:

linux os cache

可能用到的两个操作命令1.rm -rf /var/run/redis_6379.pid2.ervice redisd start

5.如果是发现重大的数据错误，比如某个小时上线的程序一下子将数据全部污染了，数据全部出错了，就可以选择一个比较早的点，对数据进行净化恢复

过期key处理

待定！！！！

full 全量推送

redis主从架构的核心原理

AOF文件没有破损是可以恢复的，也可以修复一下AOF数据redis-check-aof fix

AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复，比如，某人不小心用flushall命令清空了所有的缓存数据，这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flush all命令给删除，然后再将AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。

针对的就是数据读取的QPS并发量

每次生成一个新的数据快照文件，都会覆盖一个老的jump.rdb快照文件

每个小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份

6. 建立socket长连接

redis的生产环境启动方案

强制实现读写分离，redis slave node，默认就是开启的，也是在conf目录下面的，slave-read-only

可以配置AOF的fsync策略有三种策略可以选择，一种是每次如写入一条数据旧执行一次fsync，一种是每隔一秒执行一次fsync，一种是不主动执行fsync

mkdir创建redis目录

没有开启master主支持久化可能存在的问题

redis高并发QPS承载

master直接在内存中直接创建rdb文件，然后直接发送给slave，不会再自己本地落地磁盘

redis采用异步方式复制数据到slave节点，不过从redis2.8开始，slave node分支会周期性的确认自己每次复制的数据量。

最后输入命令：ssh-copy-id -i 主机名/IP 【将自己的机器秘钥copy到其他机器上面】

1.哨兵至少需要3个实例，来保证自己的健壮性

master node出现宕机

AOFrewirte操作机会基于当时redis中的内存数据重新构造一份较小AOF文件，膨胀的比较大的AOF文件会自动的删掉

同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移

AOF持久化机制要打开，fsync机制，使用默认的everysec基本上满足需求

save可以设置多个，就是多个数据快照检查点，每到一个检查点，就回去check一下，检查是否有指定的key数量发生了变更，如果有，就会生成一个新的dump.rdb文件

进入redis目录中：cd redisXXX

client客户端

内存中最新的部分数据

如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据；

哨兵集群必须要部署2个以上节点 quorum【选举人数】 = 1

MySQL使用内存策略，大量都是磁盘操作，QPS到正常可以达到1-2k；redis基于内存，磁盘持久化，QPS一般来说，10000QPS

例如redis存放的大小限定了只能存放1G的缓存数据

redis每间隔一秒钟就会调用fsync操作，强制将os cache中的数据，刷入磁盘文件中

所有操作基本上都是一样的，脚本微调

对于哨兵+redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。【尽可能的能把线上的数据丢上去实际测试】

fsync的三种配置策略

AOF也发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来，所以说，类似AOF这种较为复杂的基于命令日志/merger/回放的方式，比基于RDB每次持久化一份完整的数据快照文件，会更加脆弱，容易由bug，不过AOF就是为了避免reweite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多

内存数据

然后makemake testmake install最后回退local目录，perl -v 查看安装是否成功

slave node连接口令 conf下面：masterauth读写分离的架构测试，主分支主要完成写功能，从分支主要完成读，水平扩展读取。

AOF持久化机制的优点：

进入目录后，将id_rsa.pub拷贝到authorized_keys中命令：cp id_rsa.pub authorized_keys

10min

投票选举

(新)dump.rdb快照文件

redis主从架构核心原理的图解

网络波动故障，出现脑裂

单机版的redis如何能支支持每秒10万+的QPS呢？

在redis.conf的配置文件中，将appendonly的状态调整为no

当redis出现非正常情况宕机的时候，redis进程重新启动的时候，就会从appendonly.aof日志中自动加载所有的日志文件，进行缓存数据的恢复

aof和rdb持久化机制双开完美解决方案

(新)master node

综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择；用RDB来做不同程度的冷备份，在AOF文件都丢失或者是损坏不可用的时候，还可以使用RDB来进行快速的数据恢复

即使采用了后续讲解的高可用机制【铺垫redis的哨兵模式】，slave node可以自动接管master node，但是也有可能sentinel还没有检查到master failure，master node就自动重启了，还是可能导致slave分支的数据清空故障

redis replication的基本原理

redis的AOF持久化深入讲解各种操作和相关实验

RDB非常适合做冷备份，每次生成备份之后，就不会再有修改了

AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易受破损，即使文件尾部破损，也很容易修复

跑完脚本后回到/usr/local/redis下输入命令：crontab -e

第一次连接

输入命令就开始进行测试，这是对单机的QPS进行测试

2.如果redis进程所在的机器挂掉，重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复

异步复制

检查发现master宕机

2.消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员

PS:小时级别的数据备份可以和天级别的备份，可以完成并行备份

故障检查发现已宕机

也可以写入到其他的位置

再次打开aof的存持久化机制

能够保证redis的性能是最高的

AOF是存放每天写命令的，所以会不断的膨胀，当达到一定程度，AOF会做REWIRTEC操作

redis如何通过读写分离来承载读写分离来承载请求的QPS超过10万+

将redis缓存架构做成一主多从，主分支master主要负责写入数据，并且将数据同步复制到其他的slave分支节点，其余的从分支主要负责读取请求，所有的读取数据的请求全部走从节点，也就是slave节点。

在redis的平级目录下载：wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz

RDB持久化文件

AOF快照文件存放的是指令日志，需要重新走一份指令【而RDB就是一份数据文件，恢复的时候直接加载到数据文件中即可】

进入perl目录后：输入：./Configure -des -Dprefix=/usr/local/perl

杀死进程后

RDB持久化的工作原理：

安装gcc环境yum istall -y gcc

3.slave node定时任务检查

此时再这个旧的master node的内存数据，还没有来得及给slave node就出现了宕机，slave node就成为master node了，那些内存中没来得及复制的数据，就丢失了。

脚本

配置ssh免密码登陆

也就是又重新到了这个步骤

然后source vi ~/.bashrc

集群安全认证：master上启用安全认证，conf下面：requirepass XXX

这个策略配置也是再redis.conf文件中配置的【appendfsync，三种模式的配置】

请求fork子进程

可能会出现的故障或者是问题

redis.conf的配置文件修改

save触发

redis哨兵架构的相关基础知识【sentinel(哨兵)】

在项目中部署redis企业级数据备份以及各种“踩坑”的数据恢复容灾演戏

内存中最新数据

出现脑裂

redis数据备份方案

做数据恢复的时候会比较慢，做冷备会比较不方便，需要手写一些复杂的脚本。

选举升级为master node

AOF可以更好的保护数据不丢失，一般AOF会每隔一秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据

2.slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是此时复制是还没有开始的；

如果想要在redis故障时，尽可能最少的丢失数据，那么RDB没有AOF好，一般来说，RDB数据快照文件都是每隔5分钟或者是更长的时间生成一次额快照文件，这个时候就得接受一旦redis进程kill掉或者是宕机，那么会丢失最新5分钟的数据甚至更长时间的数据；

master如果发现多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

master node主支的各种备份方案是否要做

1.首先还是先装好redis的单机版本设置为生产者模式

企业级的数据备份和各种灾难的数据恢复，是如何做的

在etc下创面redis目录【主要作用用来存放redis的配置文件】

单机版redis

解压：tar -zxvf 压缩包名

集群的安全认证，在从节点配置主节点的IP【可以不配置】

每隔60S，如果有超过1000个key发生了数据变更，那么就生成一个新的dump.rdb文件，也可以手动调用save或者是bgsave命令，同步或者异步执行rdb快照的生成。【这个dump.rdb文件就是redis完整的数据快照】

redis数据库

然后就在unix目录进行：makemake install

redis

此时如果磁盘上的数据也丢失了，那么就可以从阿里云或者是亚马逊服务器上面copy

redis replication的核心机制

master的各种备份方案，究竟要不要做，万一说本地的所有数据文件丢失了，从备份中挑选一份rfb去恢复master，这样才能确保master主支启动的时候，是有数据的；

如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制

makemake testmake install

数据复制同步/异步

RDB会生成多个数据文件，每个数据文件都代表了某个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备份，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如亚马逊或者是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据

sentinel集群

这个还是有点疑惑的

#!/bin/shcur_date=`date +%Y%m%d%k`rm -rf /usr/local/redis/snapshotting/$cur_datemkdir /usr/local/redis/snapshotting/$cur_datecp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_datedel_date=`date -d -48hour +%Y%m%d%k`rm -rf /usr/local/redis/snapshotting/$del_date

1.vim /etc/sysconfig/network-scripts/ifcfg-ens33 TYPE=\"Ethernet\"PROXY_METHOD=\"none\"BROWSER_ONLY=\"yes\" BOOTPROTO=\"static\" /最重要的是这个DEFROUTE=\"yes\" IPV4_FAILURE_FATAL=\"no\"IPV6INIT=\"yes\"IPV6_AUTOCONF=\"yes\"IPV6_DEFROUTE=\"yes\"IPV6_FAILURE_FATAL=\"no\"IPV6_ADDR_GEN_MODE=\"stable-privacy\"NAME=\"ens33\"UUID=\"4f39972b-e69f-4be5-b49f-6591c4032718\"DEVICE=\"ens33\"ONBOOT=\"yes\"IPADDR=192.168.0.103 【修改的静态ip网段必须要一致】NETMASK=255.255.255.0 DNS1=192.168.0.3 【本地网关，网段必须要一致】

正常流程复制

3.数据恢复方案

在redis的目录下，有一个utils目录，cd utils

redis启动的时候，自动重新恢复基于内存的数据，会生成一份新的rdb持久化快照文件，直接用空的数据，覆盖掉了有数据的快照【也就是手动拷贝的dump.rdb快照文件】

cd perl-5.16.1

redis单机支持每秒10万+QPS【主从架构】

例如：192.168.0.103 hello

图解

在/etc/init.d/目录下:1.在redis_6379脚本中，最上面加入两行注释# chkconfig：2345 90 10# description Redis is a persistent key-value database然后再init.d/目录下输入命令：chkconfig redis_6379 on

AOF配置文件的改变，【auto-aof-rewrte-percentage 100】这段配置的意思是，当前AOF大小膨胀到超过上次100%，上次的两倍

开启AOF持久化机制

第一次连接full全量推送内存中最新的数据

核心思想

【AOF】如果使用fsnyc的默认配置【everysec】，最多就丢1秒钟的数据

everysec:每秒将os cache操作系统内存中的数据fsync到磁盘上面【这个最常用，通常在生产环境中使用，性能很高，QPS是可以上万的】；always ：每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能最差，吞吐量很低；no：仅仅reids负责将redis写入os cache就撒手不管了，然后os有自己的策略自己会时不时的将系统内存中的数据刷入磁盘

redis如果只是将缓存的数据放入内存中，一旦发生宕机等问题，将会是灾难性的企业故障，在大型电商网站中

master node会在内存中常见一个backlog

现代的操作系统中，写文件不是直接写入磁盘，会先写入os cache，然后到一定的时间再从os cache到disk file

JDK环境

替换旧的RDB快照文件

安装单机版的redis

内存中的数据始有一定量的，是有限度的，

选举

1.redis进程挂掉，重启redis即可，直接会基于AOF日子文件自动在启动的时候恢复数据

选举提升

redis client客户端的使用： 1.redis-cli shutdown 连接本机的6379端口停止redis进程

发起自动重连机制

停止redis后，删除了appendonly.aof，然后将有数据的dump.rdb快照文件拷贝到指定的持久化目录，再重启redis，会出现这种情况，数据还是没有恢复过来，原理：虽然删除了appendonly.aof，但是因为打开了aof持久化机制，redis就一定会基于aop去恢复，即使这个appendonly.aof已经不存在，redis会自动创建一个新的空的appendonly.aof文件，所以导致数据还是没有；

如果第一优先方案选择RDB持久化机制，那么会导致如果redis出现宕机，那么数据会丢失比较多。

数据未写入

redis搭建主从架构的实操

为什么RDB比AOF快

可以写入到国外的亚马逊上面或者是国内的阿里云服务器中

QPS相关的数据【QPS每秒中的请求数量】

修改【vi ~/.bashrc】

异步复制数据给slave node

在slave node的conf文件上配置：slaveof 主节点【master node IP地址，如果做了映射可以配置主机名

哨兵的核心知识点

master node主支

fork子进程

slave node在做复制的时候，也不会block阻止对自己的查询操作，它会用旧的数据集来提供服务，【但是完成复制的时候，需要删除旧的数据集，加载新的数据集，这个时候可能会暂停对外的服务了】

当AOF累计到一定程度的时候，redis会触发rewirte机制

redis_master主支

不建议用slave node 作为master node的数据冷备份，这样的话，如果关闭了master的持久化机制，可能在master宕机重启的时候，数据是空的，然后经过复制，如之前操作的aof日志的优先机制，slave node数据也丢失了。

AOFappentonly三种策略的模式

AOF持久化机制的工作原理：

每天都保留一份当天的rdb备份，到一个目录中去，仅仅保留最新一个月的数据备份

每个小时备份，保留近48小时的

master node

redis config set热修改配置参数，可能配置文件中的实际的参数没有被持久化的修改，再次停止redis，手动修改配置文件，打开aof，再次重启redis；

[root@192 ~]# cat /etc/sysconfig/network# Created by anacondaGATEWAY=192.168.0.3 /这个就是自己的ip地址网关NETWORKING=yes[root@192 ~]# cat /etc/resolv.conf# Generated by NetworkManagernameserver 192.168.0.3

如果多个分支发起重连

网络断开处理

1.集群监控，负责监控redis master和slave进程是否能正常工作

对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大;

Linux需要准备的环境

关闭aof持久化机制

单机版的redis大概QPS大概能支撑1-5万左右的并发，也就是每秒1-5万的请求量(含糊理解)

为什么要装perl(语言包)，大型的电商网站的详情页系统，比较复杂，Java+nginx+lua，需要perl=========perl是一个基础的编程语言的安装，和Java一样，需要跑一些tomcat，Javaweb应用

ps -ef | grep redis

RDB和AOF到底该如何选择：

RDB持久化机制的缺点

7.发送ping

ping

解压:tar -zxvf perl-5.16.1.tar.gz

磁盘(自己做一份备份)

但是对应的写日志的命令脚本还停留在AOF日志文件中，然后AOF文件会不断的膨胀变大，所以AOF会自动在后台每隔一定的时间做rewrite操作

5.socket长连接

在数据安全丢失的情况下，基于rdb备份，重启redis，确认数据恢复，直接在命令行热修改redis配置文件，打开aof，这个redis就会将内存中的数据对应的日子，写入aof文件中，此时aof和rdb两份数据文件的数据就同步了。

3.故障转移，如果master node挂掉了，会自动转移到slave node上

打开AOF持久化机制之后，redis每次接收到一条写的命令，就会写入日志文件中，当然首先是写入到os cache的，然后每隔一定的时间，redis触发机制再fsync一下

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh【上面的命令代表的是每月每周每天的0分，也就是每小时就去执行shell脚本】0 0 * * * 这个代表的就是每年的每月的每周的每天的0.0分去执行这个shell脚本

从redis2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份

master和slave两个节点都会保存一个relica offset还有一个master id，offset就是保存在backlog中的

此时master node出现宕机后没有即使的将数据异步到slave节点，出现数据丢失

1.异步复制导致的数据丢失因为master复制数据到slave的复制是异步的，所有可能有部分数据还没有复制到slave，master就宕机了，此时这些部分数据就丢失了

redis持久化机制对于故障恢复的意义和作用

连接出现网络故障

slave不会过期key，只会等待master过期key，如果master过期了一个key或者是通过LRU内部淘汰算法淘汰了一个key，那么会自动模拟一条del命令发送给slave，执行这个指令完成删除key的操作

那么打开redis.conf文件，将redis的aof持久化机制手动修改为yes，再次重启redis，重新再去get数据的时候，发现，数据还是丢失了。

如果M1所在的机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致的认为master出现宕机，然后选举出一个来执行故障转移；

提升为master

why？

创建新的脚本文件vi redis_rdb_copy_hourly.sh

perl环境

10.第一次进行连接，masterfull全量复制给slave node分支

如果要更改一个月周期的脚本，将日期后面的%k删掉即可，hour改成month即可

5min

目前采用的是sentinel 2版本，对已1来说，重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单

导致从节点可能连接不到主节点

经典的3节点哨兵集群

哨兵 + redis主从的部署架构，是不会保证数据的零丢失的，只能保证redis集群的高可用性

1.启动slave node

【开启了只读功能，会拒绝所有的写操作，这样可以强制搭建成读写分离的架构】

RDB对redis对外提供给的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可

utils目录中有：【redis_init_script脚本】

export JAVA_HOME=/jdk解压包的完整路径export PATH=$PATH:$JAVA_HOME/bin

redis中的数据是有限的，redis中的很多数据可能会自动过期，可能会被用户删除，可能会被redis用缓存清楚的算法清理掉，redis中的数据会不断淘汰掉旧的数据，就一部分常用的热数据会被自动保存在redis内存中

进入redis安装包：cd /usr/local/redis-3.2.8/src下

请求

slave node分支

通过reids-cli shutdown这种方式去停掉redis，其实是一种安全退出的模式，redis在退出的时候会将内存中的数据立即生成一份完整的数据快照【dump.rdb文件】

2.企业级的数据备份方案

强制开启读写分离

此时假如redis中已经有100w条数据，已经快到1G或者是已经到了1G内存

9.发送masterauth口令认证

故障检查

要将redis作为一个系统的daemonize进程去运行的，每次系统启动，redis进程要一起启动

RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致客户端提供的服务暂停几毫秒或则是几秒。

每天晚上将当前服务器上所有的数据备份，发一份到远程云服务上去

11. master node 后续持续将写命令同步或者是异步复制给slave node

修改redis的配置文件，默认是放在redis的根目录下面的【redis.conf这个文件】----->将这个redis.conf文件放置/etc/redis目录下【并修改文件名为6379.conf】

master持久化对于主从架构的安全保障的意义

集群脑裂

无磁盘化复制

redis只会写一个AOF文件，所以AOF文件会越来越来大，当AOF达到一定程度后，redis会创建一个新的AOF文件

redis客户端的使用cli

2.脑裂导致的数据丢失：脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际在master还运行着，此时哨兵可能就会认为master宕机了，然后开始进行选举，将其他的slave切换成了master，这个时候，集群了就会有两个master，也就是所谓的脑裂此时虽然摸个slave被切换成了master，但是可能client客户端还没来得及切换到新的master，还在继续向旧的master写的数据，就可能丢失了，因此就的master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据

单机版的redis的安装以及redis生产环境的启动方案

此时新的master没有外界数据

redis的RDB持久化配置以及数据恢复实验

在/var下创建redis目录--->然后在/var/redis目录下创建一个6379目录【这个6379的目录主要存放redis持久化文件】

数据复制的完整流程

启动redis：cd /etc/init.d/再使用命令：./redis_6379

AOF持久化，redis默认是关闭状态的，RDB持久化，默认是自己会开启三个save的

此时会触发redis的内部的淘汰算法例如:LRU算法，会将一些冷门的数据进行删除，然后再继续写入，如果例如还剩20w热们数据，那么现在又写入了redis80w的数据【此时AOF中的数据已经又180w条写入指定日志文件】

内存

文本备注：1. slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是此时复制是还没有开始的； 2. slave node 内部有一个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就和master node建立socket网络连接 3. slave node 发送ping命令给master node 4. 口令认证，如果master设置了requirepass，那么slave node必须发送masterauth的口令过去进行认证 5. master node第一次执行全量复制，将所有的数据发送给slave node 6. master node 后续持续将写命令，同步或者是异步复制给slave node

而且即使AOF和RDB都开启了，redis重启的时候，也是优先通过AOF进行数据恢复的

自认定master已经宕机

在aof和rdb持久化机制全部开启的时候，可能会引发的操作失败问题

3.redis-cli 进入交互式命令行

slave node节点主要用来进行横向扩容，做读写分离，扩容的slave node可以提高【读】的吞吐量；

4.配置中心，如果故障转移发生了，通知client客户端新的master地址

重新生成AOF日志快照文件，此时生成的AOF快照，会基于当前redis中的内存数据重新生成一份，也就是80w写入指令的日志文件

RDB持久化的工作流程

slave node 也可以连接其他的slave node的

将RDB文件全量复制full

数据写入redis本地缓存

redis单机版的安装和注意事项，和生产环境下的redis启动需要修改的配置文件和环境的准备