主从复制, 读写分享! 80%的情况下都是在进行读操作! 减缓服务器的压力!架构中经常使用
只要在公司主从复必须要使用
最低配制: 一主二从
数据冗余: 主从复制实现了数据的执备份,是持久化之外 的一种数据冗余方式
故障恢复:当主节点出现 问题时可以由从节点提供服务,实现快速的故障恢复,实际上是冗余的一种
负载均衡:在主从复制的基础上,配合读写分享,可以由主节点提供写服务,由从节点提供读服务,
分担服务器负载尤其是在写少读多的场景下大大提高Redis服务器的并发量
高可用基石:主从复制 还是哨兵和集群能够实施的基础,所以主从复制是高可用的基础
? 一般来说,要将Redis运用于工程项目中,只使用一台Redis是万万不能的,原因如下:
? 电商网站上的端口,一般都是一次上传,无数次浏览的,(读多写少)
? 对于这种场景,我们可以使如下 这个 架构
info replication 查看 节点信息
复制 3 个配制文件,然后修改对应的信息
1.端口 6380
2.pid 名字 fidfile redis_6380.pid
3 log 文件名字 6381.log 日志文件
4.dbfilename dump6380.rdb 备份文件名字
启动 redis-server xxx/redis80.conf
redis-server xxx/redis81.conf
redis-server xxx/redis79.conf
配制主从 一主二从
默认情况下每台都是主机,
配制命令:
SLAVEOF 127.0.0.1 6379 认 6379当老大
测试
127.0.0.1:6379> info replication
# Replication
role:master 角色
connected_slaves:0 # 从机
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379>
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_repl_offset:141
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6380>
replicaof 127.0.0.1 6379 主机 ip:port
masterauth 123456 主机密码
细节
主机可以写, 从机不能写只能读, 主机中的所有信息和数据都会自动的被从机保存
主机断了 从机依旧连接到主机的. 如果没有配制哨兵 从机不可能变成主机
从机断了 如果主机这个 时候写入了值, 从机在次连接上,所有数据会恢复
复制原理
Master 接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令, 在后台
进程执行完毕之后,master将传送整个数据文件到slave,并完成一次完全同步
全量复制: 而slave 服务在接收到数据库文件数据后,将其存盘并加载到内存中.
增量复制: Master 继续将新的所有收集到的修改命令依次传给slave 完成同步
层层链路
m -> [s, m] -> s 这个时候也可以完成主从复制
如果主机断了 可以使用 SLAVEOF no one 让自己变成主机 其他的从机可以连接到新的主机 (手动的)
! 如果这个时候断了的主机回来了 就要从新配制这个机器
能够自动监控主机是否故障,如果故障了,根据投票数自动将从库变成主库
哨兵模式是一种特殊的模式,首先Redis 提供了哨兵的命令,哨兵是一个独立的进程
作业为进程,它会独立运行.其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例
哨兵的十个作用
通过发送命令, 让Redis服务器返回监控其运行状态,包括主服务和从服务.
当哨兵监测到master宕机, 会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器
切换主机
然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控,
各个哨兵之间还会进行监控,这样就形成了多哨兵模式
假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1认为主服务器
不可用,这个现象成为主观下线,当后面的哨兵也检测到主服务器不可用,并且数据达到一定值时, 那么哨兵之间就会进行一次投票,投票的结果由一人发起,进行failover故障转移操作,切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个 过程称为客观下线
测试
vim sentiner.conf 新建一个哨兵配制
#是否为守护进程
daemonize yes
pidfile "/var/run/redis/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"
bind 127.0.0.1
port 26379
#工作目录
dir "/var/lib/redis"
#声明该哨兵的主库是mymaster，主库的ip和端口分别为127.0.0.1和6379
#最后一个2的含义是，在哨兵发生领导选举时，该哨兵需要获得2票才能成为leader
sentinel monitor mymaster 127.0.0.1 6379 2
#在mymaster宕机30秒后进行主观下线
sentinel down-after-milliseconds mymaster 30000
#指定在发生failover故障转移时最多可以有1个slave同时对新的master进行同步
sentinel parallel-syncs mymaster 1
#设置故障转移超时时间为180秒
#这个参数的意义比较复杂，详细可以参考官方的注释说明
sentinel failover-timeout mymaster 180000
#发现两个从节点
sentinel known-slave mymaster 127.0.0.1 6380
sentinel known-slave mymaster 127.0.0.1 6381
#epoch实现类似版本号的功能
sentinel current-epoch 0
优点:
1.哨兵集群,基于主从复制模式,所有主从配置优点,全有
2.主从可以切换,故障可以转移,系统可用性就会更好
3.哨兵模式就是主从模式的升级,手动到自动,更加健壮
缺点:
1.Redis 不好在线扩容,集群容量一旦到达上限,在线扩容就十分麻烦
2.实现哨兵模式的配置其实是很麻烦的,里面有很多 选择
哨兵模式的全部配置
# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379
port 26379 # 有多个哨兵,就有多个配制文件
# 哨兵sentinel 的工作目录
dir /tmp
# 哨兵sentinel监控的redis主节点的ip port
# master-name 可以自己命名主节点名字
# quorum 配制多少个sentinel 哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开记了requirepass foobared 授权密码,这样所有连接redis都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
# sentinel auth-pass mymaster 123456
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵观认为主节点下线 默认30秒
sentinel down-after-milliseconds mymaster 30000
# 这个 配制项指定了在发生failover 主备切换时最多可以有多少个slave同时对新的master进行同步
# 这个数字越小完成failover所要的时间越长 但是如果这个数字越多意味着越多的slave 因为replication而不可用
# 可以通过将这个 值设为1 来保证每次只有一个slave 处于不能处理命令请求的状态
# sentinel parallel <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障转移超时时间 failover-timeout 可以用在以下这些方面
# 1. 同一个sentinel 对同一个master 两次failover之间的间隔时间
# 2. 当一个slave从一个错误的master那里同步数据开始计算时间, 直到slave被纠为向正确的master哪里 同步 数据时
# 3 当想要取消一个正在进行的failover所需要的时间
# 4 当进行failover时配置所胡slaves指向新的master所需的最大时间不过,即使过了这个 超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来
# 默认三分种
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
# scripts execution
# 配置当某一事件发生时所需要执行的脚本,可以通过脚本来通知管理员,例如当系统运行不正常时发邮件通知相关人员.
# 对于脚本的运行结果有以下规则
# 若脚本执行后返回1,那么 该脚本 稍后将会被再次执行,重复次数目前默认为10
# 若脚本执行后返回2 ,或者比2更高的一个返回值,脚本将不会重复执行
# 如果脚本在执行过程中由于收到系统中断信号被终止了,则和返回为1时的行为相同
# 一个脚本 的最大执行时间为60s如果超过这个时间,脚本 将会被一个SIGKILL信号终止之后重复
# 通知型脚本:当sentinel 有任何警告级别的事件发生(比如说redis实例的主观失效和客观失效等等)将会去调用这个脚本,这时这个脚本应该通过邮件,SMS等方式通知系统管理员关于系统不正常运行的信息,调用该脚本时将传给脚本两个参数,一个是事件类型,一个是事件的描述 如果sentinel.conf配置文件中配置了这个脚本路径,那么 必须保证这个脚本存在于这个路径,并且是可执行的否则sentinel无法启动成功
# 通知脚本
# sentinel notification-script mymaster /var/redis/notify.sh
# 客户端重新配置主节点参数
# 当一个master由于failover而发生改变时,这个脚本将会被调用,通知相关的客户端关于master改变通知
# 以下参数将会在调用脚本是传给脚本
#<master-name> <roke> <state> <from-id> <from-port> <to-ip> <to-port>
# 目前<state>总是 "failover"
#<role> 是leader 或者observer中的一个
# 参数from-ip, from-port, to-ip, to-port 是用来和旧的master和新的master通信的
# 这个脚本应该是通用的,能被多次调用,不是针对性的
# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh 一搬由运维配制
原文：https://www.cnblogs.com/yuhaipeng/p/13372723.html