[redis-持久化，主从复制原理，Redis-Sentinel]

1 持久化

# redis的所有数据保存在内存中，对数据的更新将异步的保存到硬盘上

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

1.1 rdb方式

# 原理是：某一时刻，把数据完整备份，重启，把数据加载回内存

# 三种方式实现
	-在客户都命令行中敲命令
    	-save ---》同步操作
    -在客户都命令行中敲命令
    	-bgsave---》异步操作（又起了一条保存线程，单独保存，不会阻塞其他命令的执行）
    -在配置文件中写
    	save   900        1
        save   300        10
        save   60         10000
        如果60s中改变了1w条数据，自动生成rdb
        如果300s中改变了10条数据，自动生成rdb
        如果900s中改变了1条数据，自动生成rdb
        
# 注意：如果是正常关闭redis，会触发bgsave---》要强行关闭
# 缺点
	-可以能会丢失数据
    
    
# 缓冲相关用这种方式，如果对数据要求严格，保证不丢，不能使用这种方式

1.2 aof 方式

# 客户端每写入一条命令，都记录一条日志，放到日志文件中，如果出现宕机，可以将数据完全恢复
# 三种策略
    日志不是直接写到硬盘上，而是先放在缓冲区，缓冲区根据一些策略，写到硬盘上
    always：redis–》写命令刷新的缓冲区—》每条命令fsync到硬盘—》AOF文件
    everysec（默认值）：redis——》写命令刷新的缓冲区—》每秒把缓冲区fsync到硬盘–》AOF文件
    no:redis——》写命令刷新的缓冲区—》操作系统决定，缓冲区fsync到硬盘–》AOF文件
        
# AOF 重写
	本质就是把过期的，无用的，重复的，可以优化的命令，来优化
	这样可以减少磁盘占用量，加速恢复速度
    
    
    
# 实际配置
appendonly yes #将该选项设置为yes，打开
appendfilename "appendonly-${port}.aof" #文件保存的名字
appendfsync everysec #采用第二种策略
dir /bigdiskpath #存放的路径
no-appendfsync-on-rewrite yes #在aof重写的时候，是否要做aof的append操作，因为aof重写消耗性能，磁盘消耗，正常aof写磁盘有一定的冲突，这段期间的数据，允许丢失

1.3 RDB-AOF混合持久化

# 配置文件写
save   60        10
save   30        5
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-use-rdb-preamble yes 
# 在aof文件中，既有rdb的东西，又又aof日志的记录

2 主从复制原理与优化

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


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


# 主从同步的辅助配置
min-slaves-to-write 1
min-slaves-max-lag 3
#那么在从服务器的数量少于1个，或者三个从服务器的延迟（lag）值都大于或等于3秒时，主服务器将拒绝执行写命令



# 主从复制方案
	-命令
    	-在从库上
        	slaveof 127.0.0.1 6379
            slaveof no one  # 取消主从
		-通过info可以查看主从信息
    -配置文件（从库配）
        slaveof 10.0.0.101 6379
        slave-read-only yes

3 Redis-Sentinel

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


# 高可用：哨兵

# 原理
1 多个sentinel发现并确认master有问题
2 选举触一个sentinel作为领导
3 选取一个slave作为新的master
4 通知其余slave成为新的master的slave
5 通知客户端主从变化
6 等待老的master复活成为新master的slave



# 搭建
	-一主两从
    -sentinel是特殊的redis，单独进程，需要额外启动，也有配置文件，客户端也可以链接

    
# sentinel配置文件
port 26379
daemonize yes
dir data
protected-mode no
bind 0.0.0.0
logfile "redis_sentinel.log"
# mymaster随便写，127.0.0.1 6379主库地址和端口  2 个哨兵认为主库挂了，才算挂
sentinel monitor mymaster 127.0.0.1 6379 2 
#这个配置项指定了需要多少失效时间，一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒，默认为30秒
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000


daemonize yes
pidfile /var/run/redis.pid
port 6379
dir "/root/s17/redis/redis4/data"
logfile 6379.log


daemonize yes
pidfile /var/run/redis2.pid
port 6380
dir "/root/s17/redis/redis5/data"
logfile “6380.log”
slaveof 127.0.0.1 6379
slave-read-only yes


port 26379
daemonize yes
dir ./redis4/data
protected-mode no
bind 0.0.0.0
logfile "redis_sentinel3.log"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

import redis
from redis.sentinel import Sentinel

# 连接哨兵服务器(主机名也可以用域名)
# 10.0.0.101:26379
sentinel = Sentinel([('10.0.0.101', 26379),
                     ('10.0.0.101', 26378),
                     ('10.0.0.101', 26377)
		     ],
                    socket_timeout=5)

print(sentinel)
# 获取主服务器地址
master = sentinel.discover_master('mymaster')
print(master)

# 获取从服务器地址
slave = sentinel.discover_slaves('mymaster')
print(slave)



##### 读写分离
# 获取主服务器进行写入
# master = sentinel.master_for('mymaster', socket_timeout=0.5)
# w_ret = master.set('foo', 'bar')

# slave = sentinel.slave_for('mymaster', socket_timeout=0.5)
# r_ret = slave.get('foo')
# print(r_ret)