目录

redis主从复制

是什么

行话:也就是我们所说的主从复制,主机数据更新后根据配置和策略, 自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主

能干嘛

  • 读写分离
  • 容灾恢复

怎么用

准备工作

  • 配从(库)不配主(库)

  • 从库配置命令:

    1
    
    slaveof 主库IP 主库端口
    
    • 每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件(具体位置:redis.conf搜寻#### REPLICATION ####
    • info replication
  • 修改配置文件细节操作

    • 拷贝多个redis.conf文件,按’redis[port].conf’重命名

      https://gitee.com/lienhui68/picStore/raw/master/null/image-20200926193252977.png

    • 开启daemonize yes

    • pid文件名字

      https://gitee.com/lienhui68/picStore/raw/master/null/image-20200926193335436.png

    • 指定端口 6380/6381

    • log文件名字

      https://gitee.com/lienhui68/picStore/raw/master/null/image-20200926193425859.png

    • dump.rdb名字

      https://gitee.com/lienhui68/picStore/raw/master/null/image-20200926193457133.png

上面是通过配置3个端口模拟3个redis服务器,也可以使用docker开3个redis服务器进行模拟

常用三招

一主二仆

  • 启动

    https://gitee.com/lienhui68/picStore/raw/master/null/image-20200926195243419.png

  • 设置从属关系

    1
    
    $ slaveof 127.0.0.1 6379
    

    https://gitee.com/lienhui68/picStore/raw/master/null/image-20200926195528255.png

  • 查看主从信息

    1
    
    $ info replication
    

    https://gitee.com/lienhui68/picStore/raw/master/null/image-20200926195704073.png

  • 查看日志

    • 主机日志

      https://gitee.com/lienhui68/picStore/raw/master/null/image-20200926195919330.png

    • 备机日志

      https://gitee.com/lienhui68/picStore/raw/master/null/image-20200926200154634.png

主从问题演示

  1. 切入点问题?slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来,那之前的123是否也可以复制?

    • 答:从头开始复制;123也可以复制
  2. 从机是否可以写?set可否?

    • 答:从机不可写,不可set,主机可写

      https://gitee.com/lienhui68/picStore/raw/master/null/image-20200926200309643.png

  3. 主机shutdown后情况如何?从机是上位还是原地待命

    • 答:从机还是原地待命(咸鱼翻身,还是咸鱼)
  4. 主机又回来了后,主机新增记录,从机还能否顺利复制?

    • 答:能
  5. 其中一台从机down后情况如何?依照原有它能跟上大部队吗?

    • 答:不能跟上,每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件(具体位置:redis.conf搜寻#### REPLICATION ####)参考{%post_link 工作/400_开发环境/缓存/redis/配置文件解析 配置文件解析%}

薪火相传

  • 上一个Slave可以是下一个slave的Master,Slave同样可以接收其他 slaves的连接和同步请求,那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力(奴隶的奴隶还是奴隶)

  • 中途变更转向:会清除之前的数据,重新建立拷贝最新的

  • slaveof 新主库IP 新主库端口

  • 演示

    https://gitee.com/lienhui68/picStore/raw/master/null/image-20200926204644733.png

反客为主

1
$ SLAVEOF no one
  • 使当前数据库停止与其他数据库的同步,转成主数据库,形成一个新的中心节点,其他从库可以slaveof 挂到这个新的主库上。

复制原理

  • slave启动成功连接到master后会发送一个sync命令
  • master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令, 在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步
  • 全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
  • 增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步
  • 但是只要是重新连接master,一次完全同步(全量复制)将被自动执行

复制的缺点

复制延时

由于所有的写操作都是先在Master上操作,然后同步更新到slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。

哨兵模式

一组sentinel能同时监控多个master

是什么

反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库

怎么用(使用步骤)

  1. 调整结构,6379带着6380、6381
  2. 新建sentinel.conf文件,名字绝不能错
  3. 配置哨兵,填写内容
    1. sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
    2. 上面最后一个数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机(PS. 跟官网的描述有出入,下面有官方文档说明)
  4. 启动哨兵
    1. redis-sentinel /sentinel.conf (上述目录依照各自的实际情况配置,可能目录不同)
  5. 正常主从演示
  6. 原有的master挂了
  7. 投票新选
  8. 重新主从继续开工,info replication查查看

问题:如果之前挂了的master重启回来,会不会双master冲突? 答: 不会,原master,变成slave

1
sentinel monitor <master-group-name> <ip> <port> <quorum>

For the sake of clarity, let’s check line by line what the configuration options mean:

The first line is used to tell Redis to monitor a master called mymaster, that is at address 127.0.0.1 and port 6379, with a quorum of 2. Everything is pretty obvious but the quorum argument:

  • The quorum is the number of Sentinels that need to agree about the fact the master is not reachable, in order to really mark the master as failing, and eventually start a failover procedure if possible.
  • However the quorum is only used to detect the failure. In order to actually perform a failover, one of the Sentinels need to be elected leader for the failover and be authorized to proceed. This only happens with the vote of the majority of the Sentinel processes.

So for example if you have 5 Sentinel processes, and the quorum for a given master set to the value of 2, this is what happens:

  • If two Sentinels agree at the same time about the master being unreachable, one of the two will try to start a failover.
  • If there are at least a total of three Sentinels reachable, the failover will be authorized and will actually start.

In practical terms this means during failures Sentinel never starts a failover if the majority of Sentinel processes are unable to talk (aka no failover in the minority partition).

Source

基本原理

关于哨兵的原理,关键是了解以下几个概念: 主观下线:在心跳检测的定时任务中,如果其他节点超过一定时间没有回复,哨兵节点就会将其进行主观下线。顾 名思义,主观下线的意思是一个哨兵节点“主观地”判断下线;与主观下线相对应的是客观下线。 客观下线:哨兵节点在对主节点进行主观下线后,会通过sentinel is-master-down-by-addr命令询问其他哨兵节点 该主节点的状态;如果判断主节点下线的哨兵数量达到一定数值,则对该主节点进行客观下线。 需要特别注意的是,客观下线是主节点才有的概念;如果从节点和哨兵节点发生故障,被哨兵主观下线后,不会再 有后续的客观下线和故障转移操作。

定时任务:每个哨兵节点维护了3个定时任务。定时任务的功能分别如下:

1.每10秒通过向主从节点发送info命令获取最新的主从结构; 发现slave节点 确定主从关系

2.每2秒通过发布订阅功能获取其他哨兵节点的信息;SUBSCRIBE c2 PUBLISH c2 hello-redis

交互对节点的“看法”和自身情况 3.每1秒通过向其他节点发送ping命令进行心跳检测,判断是否下线(monitor)。 心跳检测,失败判断依据

选举领导者哨兵节点:当主节点被判断客观下线以后,各个哨兵节点会进行协商,选举出一个领导者哨兵节点,并 由该领导者节点对其进行故障转移操作。 监视该主节点的所有哨兵都有可能被选为领导者,选举使用的算法是Raft算法;Raft算法的基本思路是先到先得: 即在一轮选举中,哨兵A向B发送成为领导者的申请,如果B没有同意过其他哨兵,则会同意A成为领导者。选举的 具体过程这里不做详细描述,一般来说,哨兵选择的过程很快,谁先完成客观下线,一般就能成为领导者。

故障转移:选举出的领导者哨兵,开始进行故障转移操作,该操作大体可以分为3个步骤:

在从节点中选择新的主节点:选择的原则是,

1.首先过滤掉不健康的从节点;

2.然后选择优先级最高的从节点(由replica-priority指定);如果优先级无法区分,

3.则选择复制偏移量最大的从节点;如果仍无法区分,

4.则选择runid最小的从节点。

更新主从状态:通过slaveof no one命令,让选出来的从节点成为主节点;并通过slaveof命令让其他节点成为其从节点。

将已经下线的主节点(即6379)保持关注,当6379从新上线后设置为新的主节点的从节点

高可用集群

redis cluster集群是什么?

redis cluster集群是一个由多个主从节点群组成的分布式服务器群,它具有复制、高可用和分片特 性。Redis cluster集群不需要sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点 设置成集群模式,这种集群 模式没有中心节点,可水平扩展,据官方文档称可以线性扩展到 1000节点。redis cluster集群的性能和高可用性均优于之前版本的哨兵模式,且集群配置非常简单

总结

1.单机版

核心技术:持久化

持久化是最简单的高可用方法(有时甚至不被归为高可用的手段),主要作用是数据备份,即将数据存储在硬盘, 保证数据不会因进程退出而丢失。

2.主从复制

复制是高可用Redis的基础,哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份,以及 对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化;写操作无法负载均衡;存储能力受到单机 的限制。

3.哨兵

在复制的基础上,哨兵实现了自动化的故障恢复。缺陷是写操作无法负载均衡;存储能力受到单机的限制。

4.集群

通过集群,Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案

参考

本地:redis资料.pdf