Redis持久化、主从复制、哨兵高可用

Redis持久化、主从复制、哨兵高可用

Redis持久化

1.什么是持久化？
Redis的所有数据保存在内存中，对数据的更新将异步的保存到硬盘上
2.持久化的实现方式？

快照：某时某刻数据的一个完成备份
    mysql---->Doump
    redis---->RDB
写日志：任何操作记录日志，要恢复日志，只要吧日志重新走一遍即可
	mysql---->Binloog
    Hhase----->Hlog
    Redis----->AOF

RDB

RDB 持久化在指定的时间间隔生成数据集的时间点快照

触发机制有三种：
1.save(同步)
    1 客户端执行save命令----》redis服务端----》同步创建RDB二进制文件
    2 会造成redis的阻塞（数据量非常大的时候）
    3 文件策略：如果老的RDB存在，会替换老的
    4 复杂度 o(n)
    
2.bgsave(异步，Backgroud saving started)	
    1 客户端执行save命令----》redis服务端----》异步创建RDB二进制文件（fork函数生成一个子进程（fork会阻塞reids），执行createRDB，执行成功，返回给reids消息）
    2 此时访问redis，会正常响应客户端
    3 文件策略：跟save相同，如果老的RDB存在，会替换老的
    4 复杂度 o(n)

3.自动(通过配置)
    配置   seconds   changes
    save   900        1
    save   300        10
    save   60         10000
    如果60s中改变了1w条数据，自动生成rdb
    如果300s中改变了10条数据，自动生成rdb
    如果900s中改变了1条数据，自动生成rdb
    
'''以上符合任意一条，就能够自动生成rdb,内部使用bgsave'''

AOF

利用 AOF 持久化将服务器收到的所有写操作命令记录下来，并在服务器重新启动的时候，利用这些命令来恢复数据集。
AOF 的命令使用的是与 Redis 本身协议的命令一致，通过追加的方式将数据写入备份文件中，同时当备份文件过大时，Redis 也能对备份文件进行重压缩。

客户端每写入一条命令，都记录一条日志，放到日志文件中，如果出现宕机，可以将数据完全恢复

AOF的三种策略：
1.always：redis–》写命令刷新的缓冲区—》每条命令fsync到硬盘—》AOF文件
2.everysec（默认值）：redis——》写命令刷新的缓冲区—》每秒把缓冲区fsync到硬盘–》AOF文件
3.no:redis——》写命令刷新的缓冲区—》操作系统决定，缓冲区fsync到硬盘–》AOF文件

AOF重写

# 随着命令的逐步写入，并发量的变大， AOF文件会越来越大，通过AOF重写来解决该问题
本质就是把过期的，无用的，重复的，可以优化的命令，来优化存储，这样可以减少磁盘的占用量，加速恢复速度。

重写的流程：

AOF持久化配置

# AOF重写配置参数
	auto-aof-rewrite-min-size：500m
    auto-aof-rewrite-percentage:增长率
        
# aof持久化的配置
appendonly yes #将该选项设置为yes，打开
appendfilename "appendonly.aof" #文件保存的名字
appendfsync everysec #采用第二种策略
no-appendfsync-on-rewrite yes #在aof重写的时候，是否要做aof的append操作，因为aof重写消耗性能，磁盘消耗，正常aof写磁盘有一定的冲突，这段期间的数据，允许丢失

混合持久化

# 可以同时开启aof和rdb，他们是相互不影响的

# redis 4.x以后，出现了混合持久化，其实就是aof+rdb，解决恢复速度问题

开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理

# 配置参数：必须先开启AOF
# 开启 aof
appendonly yes
# 开启 aof复写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 开启 混合持久化
aof-use-rdb-preamble yes  # 这正有用的是这句话
# 关闭 rdb
save ""

# aof重写可以使用配置文件触发，也可以手动触发：bgrewriteaof

主从复制原理和方案

# 为什么需要主从？
因为会出现以下的问题：
1.机器故障
2.容量瓶颈
3.QPS瓶颈

# 主从解决了QPS瓶颈，机器故障问题
# 主从实现的功能
	一主一从，一主多从
    做读写分离
    做数据副本
    提高并发量

一个master可以有多个slave
一个slave只能有一个master
数据流向是单向的，从master到slave，从库只能读，不能写，主库既能读又能写

# redis主从赋值流程，原理
1. 副本(从)库通过slaveof 127.0.0.1 6379命令,连接主库,并发送SYNC给主库 
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照，load进内存
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.
7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.
8. 如果发生主从关系断开时,从库数据没有任何损坏,在下次重连之后,从库发送PSYNC给主库
9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的

# 主从同步主库是否要开启持久化？
如果不开有可能，主库重启操作，造成所有主从数据丢失！

# 主从复制配置
	-1 命令方式，在从库上执行
    	slaveof 127.0.0.1 6379 #异步
    	# 从库不能写了，以后只能用来读
        
        slaveof no one  # 从库：断开主从关系
    
    -2 配置文件方式，在从库加入
    	slaveof 127.0.0.1 6379 #配置从节点ip和端口
		slave-read-only yes #从节点只读，因为可读可写，数据会乱
    	autpass 123456
	
# 辅助配置（给主库用的）
min-slaves-to-write 1
min-slaves-max-lag 3
#那么在从服务器的数量少于1个，或者三个从服务器的延迟（lag）值都大于或等于3秒时，主服务器将拒绝执行写命令

哨兵高可用

高可用:服务可用性高
# 主从复制不是高可用
#主从存在问题
1 主从复制，主节点发生故障，需要做故障转移，可以手动转移：让其中一个slave变成master --》  哨兵
2 主从复制，只能主写数据，所以写能力和存储能力有限---》集群

# 哨兵：Sentinel  实现高可用

# 工作原理：
    1 多个sentinel发现并确认master有问题
    2 选举触一个sentinel作为领导
    3 选取一个slave作为新的master
    4 通知其余slave成为新的master的slave
    5 通知客户端主从变化
    6 等待老的master复活成为新master的slave
    
#高可用搭建步骤
	第一步：先搭建一主两从
    第二步：哨兵配置文件，启动哨兵（redis的进程，也要监听端口，启动进程有配置文件）
    port 26379
    daemonize yes
    dir /root/redis/data
    bind 0.0.0.0
    logfile "redis_sentinel.log"
    sentinel monitor mymaster 127.0.0.1 6379 2
    sentinel down-after-milliseconds mymaster 30000


    port 26390
    daemonize yes
    dir /root/redis/data1
    bind 0.0.0.0
    logfile "redis_sentinel.log"
    sentinel monitor mymaster 127.0.0.1 6379 2
    sentinel down-after-milliseconds mymaster 30000


    port 26381
    daemonize yes
    dir /root/redis/data2
    bind 0.0.0.0
    logfile "redis_sentinel.log"
    sentinel monitor mymaster 127.0.0.1 6379 2
    sentinel down-after-milliseconds mymaster 30000
	
    第三步：启动三个哨兵
    
	./src/redis-sentinel ./sentinal_26379.conf
    ./src/redis-sentinel ./sentinal_26380.conf
    ./src/redis-sentinel ./sentinal_26381.conf

    第四步：停止主库，发现80变成了主库，以后79启动，变成了从库