redis学习-主从、哨兵搭建和原理

主从：

先搭建一把，上手撸一个主从，配置相对比较简单

步骤：

1、mkdir redis8000（主）  mkdir redis8001（从）  mkdir redis8002 （从）

2、从单击版复制一份redis.conf 放入到上面新建的文件夹中，修改8000的配置文件

  修改内容如下： 主机 bind   port  daemonize  pidfile   logfile   requirepass（密码，最好设置下）

                            从机：除了配置主机的内容 ，还需要配置 replicaof   masterauth

      从机的redis.conf 可以采用批量更新的方式 sed 's/8000/8001/g' redis.conf >redis.conf 偷懒，直接将所有的8000 换成8001

3、分别启动三个服务端  /usr/local/bin/redis-server ip:port

4、再分别启动三个客户端  /usr/local/bin/redis-server redis8000/redis.conf

5、在主服务器上set k1 v1  在从机上get k1 能获取到，就说明搭建成功

备注： 主从可以搭建成树状，也可以搭成线状

 

思想： 

1、为什么要搭主从，和单击相比，解决了什么问题?

      读写分离 主写从读 在一定程度上提高了吞吐量

      数据相对安全，主从会同步，容灾备份能力提升

缺点： 并没有实现高可用，一台服务器挂了，还是需要手动切换。一个主机可以有多个从，但是从只能有一个主

 

原理如下图（没看过源码，只是个人理解，仅作参考）：

 

 

哨兵：

 手动来一个，步骤如下：

1、创建三个哨兵节点 mkdir sentinel28000 mkdir sentinel28001 mkdir sentinel28002

2、拷贝配置文件 从安装目录到刚创建的目录 cp /usr/zk/redis-5.0.9/sentinel.conf sentinel28000/

3、修改配置文件：

基础配置：bind port daemonize pidfile logfile  dir

核心配置：配置master节点：sentinel monitor mymaster 主节点ip 主节点port  2

                  master节点身份验证：sentinel auth-pass

批量修改：sed 's/28000/28001/g' sentinel28000/sentinel.conf > sentinel28001/sentinel.conf

4、分别启动: /usr/local/bin/redis-sentinel sentinel28001/sentinel.conf 

 

验证：

操作步骤：将master节点（8000）shutdown掉，制造切换的场景。

变化：1、从节点（8001）的info信息变成master  2、哨兵的配置文件master节点信息切换

再将8000重启，看下8000是否变成从节点（注意master密码配置，可动态设置CONFIG set masterauth 密码  ）

看了下哨兵的日志信息，大概猜测了下：

 

能做哪些事：

1、监控：不断检测主节点和从节点是否正常工作

2、自动故障转移：主节点挂了以后，按照一定规则，从主节点的所有从节点中选择出一个从机，切换成主节点；

3、配置的提供者： 客户端连接哨兵节点，从而实现连接redis（哨兵配置主节点，主节点又可以获得从节点）

架构：

redis整体分为两部分，数据节点（主、从，存储数据）和哨兵节点（特殊节点，不存储数据）

解决了哪些问题：

利用哨兵来，实现主机挂了，从机自动切换成主机，提高可用性，

缺点：主机的服务压力大，所有的写操作都在主机

哨兵的原理：

主观下线：在心跳检测的定时任务式，哨兵节点发现其他节点超过一段时间没有回复，哨兵节点会将他主观下线

客观下线：哨兵在对主节点，主观下线后，会询问其他哨兵节点，主节点的状态。（配置文件配的2）如果数量达到配置的阈值，就客观下线，故障转移。

注意：只有主节点会客观下线。

哨兵内部维护的定时任务：

1、10秒一次，询问主节点，返回info命令信息，用来维护主从信息的准确性

2、2秒一次，用来和其他的哨兵节点通信，交互对节点的判断信息

3、1秒一次，心跳机制，用来监听所有数据节点信息（主从）。

哨兵的选举（日志中的vote for leader）：

当客观下线通过后，哨兵节点中需要选举出一个leader，由leader的哨兵来进行故障转移。

选举使用Raft算法，该算法是先到先得的思想。即A节点向B发起选举申请，如果B没有选举其他的节点，就会投票A（vote），一般是最先发现主节点失败的哨兵节点（发起主观下线的节点）会发起一次选举。

故障转移原理：

    转移的本质就是从节点中选一个出来变成主节点

筛选规则：

  1、筛选出不健康的节点

  2、选出优先级最高的从节点（replica-priority ），若未涉及优先级

  3、根据复制的偏移量，大的优先级高（偏移量类似于zk的事务id，越大表示数据越全）

  4、选择runid最小的节点（runid类似于zk的myid，sid，发现选举思路各框架都有共通的地方）

 

集群的选举：

集群规模  3*3  三个master 每个master有两个slave

当其中一个master挂了之后，slave发现通信失败，master节点存在问题。在timeout时间后，尝试failover，以期望称为master，具体步骤如下：

1、slave发现自己的master变成FAIL

2、将自己的epoche + 1 并且广播FAILOVER_AUTH_REQUEST

3、其他的matser响应该信息，并且对该epoche 只做一个FAILOVER_AUTH_ACK

4、尝试failover的slave收到ack，判断是否过半，过半，就广播信息，选举成功

注意： slave并不会立刻发送failover请求，会有一定延时，防止其他master未意识到该主节点挂了，拒绝请求

            延时时间 ：  500ms +  random（0~500ms） + rank*1000ms  (rank越小，代表数据越新，对比zk可以理解为zxid大)

                                猜测 随机数是为了错开两个请求，防止同时发送，需要重试    rank为了让数据最新的slave先成为master 

 

集群水平扩容：

 

目前已有三主三从，6台机器，想下需要做的操作：

1、启动三台redis实例（7006  7007 7008），启动时和集群无关联

2、将7006加入集群

   7006： 需要加入的实例   7000：集群中已有的实例

   redis-cli -a  密码 --cluster add-node ip:7006 ip:7000
3、给集群分配槽位

redis-cli -a 123456 --cluster reshard 172.16.179.62:7006

4、7006 被分配到1000个槽位 

5、启动7007 ，将7007加入集群

   redis-cli -a  密码 --cluster add-node ip:7007 ip:7006

6、redis-cli 联入客户端，CLUSTER REPLICATE  Node-id

7、7008 重复7007即可