主从复制

       ****a,****方式一、新增redis6380.conf, 加入  slaveof 192.168.1.111 6379,  在6379启动完后再启6380，完成配置；

       ****b,****方式二、redis-server --slaveof 192.168.1.111 6379

       ****c,****查看状态：info replication

       ****d,****断开主从复制：在slave节点，执行6380:>slaveof no one

       ****e,****断开后再变成主从复制：6380:> slaveof 192.168.1.111 6379

       ****f,****数据较重要的节点，主从复制时使用密码验证： requirepass

       ****e,****从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致       

     ****h,****传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭

参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，

参数启用时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房

主从拓扑：支持单层或多层

A,一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响

B, 一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定

C,树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点1，再由从节点2推送到11，减轻主节点推送的压力。

复制原理

执行slave master port后，与主节点连接，同步主节点的数据,6380:>info replication：查看主从及同步信息

数据同步：redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制

全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）

部分复制：网络出现问题，从节占再次连主时，主节点补发缺少的数据，每次 数据增加同步

心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率

哨兵机制

1，为什么要讲哨兵机制？

A，我们学习了redis的主从复制，但如果说主节点出现问题不能提供服务，需要人工重新把从节点设为主节点，还要通知我们的应用程序更新了主节点的地址，这种处理方式不是科学的，耗时费事

B，同时主节点的写能力是单机的，能力能限

C，而且主节点是单机的，存储能力也有限

其中2，3的问题在后面redis集群课会讲，第1个问题我们用哨兵机制来解决

2,主从故障如何故障转移(不满足高可用)：

    A，主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点

    B，其它的节点成为新主节点的从节点，并从新节点复制数据

3，哨兵机制(sentinel)的高可用：

A，原理：当主节点出现故障时，由redis sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（感兴趣的同学可以查一下，其实就是个选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知

哨兵有三个定时监控任务完成对各节点的发现和监控：

任务1，每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到

任务2，每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的；

任务3，每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

主观下线和客观下线：

主观下线：刚知道哨兵节点每隔1秒对主节点和从节点、其它哨兵节点发送ping做心跳检测，当这些心跳检测时间超过down-after-milliseconds时，哨兵节点则认为该节点错误或下线，这叫主观下线；这可能会存在错误的判断。

客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（法定人数）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线

领导者哨兵选举流程：

**a,**每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；

**b,**当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；

**c,**如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

故障转移机制

A，由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

B，当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移,

C，由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行

流程： 1，将slave-1脱离原从节点，升级主节点，

           2，将从节点slave-2指向新的主节点

           3，通知客户端主节点已更换

           4，将原主节点（oldMaster）变成从节点，指向新的主节点

D，故障转移后的redis sentinel的拓扑结构图

哨兵机制－故障转移详细流程

A，过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点

B，选择salve-priority从节点优先级最高（redis.conf）

C，选择复制偏移量最大，指复制最完整的从节点

如何安装和部署Reids Sentinel?

我们以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署

1，前提：先搭好一主两从redis的主从复制，和之前复制搭建一样，搭建方式如下：

A主节点6379节点（/usr/local/bin/conf/redis6379.conf）：修改 requirepass 12345678，注释掉#bind 127.0.0.1

B从节点redis6380.conf和redis6381.conf:修改 requirepass 12345678 ,注释掉#bind 127.0.0.1, 加上masterauth 12345678 ,加上slaveof 127.0.0.1 6379

    注意****：当主从起来后，主节点可读写，从节点只可读不可写

2，redis sentinel哨兵机制核心配置(也是3个节点)：

       /usr/local/bin/conf/sentinel_26379.conf  

       /usr/local/bin/conf/sentinel_26380.conf

       /usr/local/bin/conf/sentinel_26381.conf

将三个文件的端口改成: 26379   26380   26381

然后：sentinel monitor mymaster 190.168.1.111 6379 2  //监听主节点6379

          sentinel auth-pass mymaster 12345678     //连接主节点时的密码

三个配置除端口外，其它一样。

3，哨兵其它的配置：只要修改每个sentinel.conf的这段配置即可：

sentinel monitor mymaster 192.168.1.10 6379 2  //监控主节点的IP地址端口，sentinel监控的master的名字叫做mymaster

2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了

sentinel auth-pass mymaster 12345678  //sentinel连主节点的密码

sentinel config-epoch mymaster 2  //故障转移时最多可以有2从节点同时对新主节点进行数据同步

sentinel leader-epoch mymaster 2

sentinel failover-timeout mymasterA 180000 //故障转移超时时间180s，

**a,**如果转移超时失败，下次转移时时间为之前的2倍；

*b,从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过180S***时，则故障转移失败

*c,从节点复制新主节点时间超过180S***转移失败

sentinel down-after-milliseconds mymasterA 300000//sentinel节点定期向主节点ping命令，当超过了300S时间后没有回复，可能就认定为此主节点出现故障了……

sentinel parallel-syncs mymasterA 1 //故障转移后，1代表每个从节点按顺序排队一个一个复制主节点数据，如果为3，指3个从节点同时并发复制主节点数据，不会影响阻塞，但存在网络和IO开销

4，启动sentinel服务:

            ./redis-sentinel conf/sentinel_26379.conf &

            ./redis-sentinel conf/sentinel_26380.conf &

            ./redis-sentinel conf/sentinel_26381.conf &

关闭：./redis-cli -h 192.168.1.111 -p 26379 shutdown

*5，测试：kill -9 6379*  杀掉6379的redis服务

看日志是分配6380 还是6381做为主节点，当6379服务再启动时，已变成从节点

假设6380升级为主节点:进入6380>info replication     可以看到role:master

打开sentinel_26379.conf等三个配置，sentinel monitor mymaster 127.0.0.1 6380 2

打开redis6379.conf等三个配置, slaveof 192.168.1.111 6380,也变成了6380

注意：生产环境建议让redis Sentinel部署到不同的物理机上。

重要：sentinel monitor mymaster 192.168.1.111 6379 2 //切记将IP不要写成127.0.0.1

不然使用JedisSentinelPool取jedis连接的时候会变成取127.0.0.1 6379的错误地址

注：我们稍后要启动四个redis实例，其中端口为6379 的redis设为master，其他两个设为slave 。所以mymaster 后跟的是master的ip和端口，最后一个’2’代表只要有2个sentinel认为master下线，就认为该master客观下线，选举产生新的master。通常最后一个参数不能多于启动的sentinel实例数。

哨兵sentinel个数为奇数，选举嘛，奇数哨兵个才能选举成功，一般建议3个

RedisSentinel如何监控2个redis主节点呢****？

sentinel monitor mymasterB 192.168.1.20 6379 2

……与上面一样 多一条配置…………。

部署建议：

a，sentinel节点应部署在多台物理机（线上环境）

b，至少三个且奇数个sentinel节点

c，通过以上我们知道，3个sentinel可同时监控一个主节点或多个主节点

    监听N个主节点较多时，如果sentinel出现异常，会对多个主节点有影响，同时还会造成sentinel节点产生过多的网络连接，一般线上建议还是， 3个sentinel监听一个主节点

sentinel哨兵的API

命令：redis-cli -p 26379  //进入哨兵的命令模式，使用redis-cli进入

26379>sentinel masters或sentinel master mymaster //查看redis主节点相关信息

26379>sentinel slaves mymaster  //查看从节点状态与相关信息

26379>sentinel sentinels mymaster //查sentinel节点集合信息(不包括当前26379)

  26379>sentinel failover mymaster //对主节点强制故障转移，没和其它节点协商

客户端连接（redis-sentinel例子工程）

    远程客户端连接时，要打开protected-mode no

   ./redis-cli -p 26380 shutdown //关闭

   在使用工程redis-sentinel，调用jedis查询的流程如下：

     1，将三个sentinel的IP和地址加入JedisSentinelPool

2，根据IP和地址创建JedisSentinelPool池对象

3，在这个对象创建完后，此时该对象已连接redis的主节点

（此时sentinel monitor mymaster 必须写成192.168.1.111 6379 2，不能为127.0.0.1，不然查询出来的主节点的IP在客户端就变成了127.0.0.1，拿不到连接了）查询出来了，当客户准备发起查询请求时，调用pool.getResource()借用一个jedis对象，内容包括主节点的IP和端口；

4，得到jedis对象后，可执行jedis.get(“age”)指令了……

@Test
    public void testJedis() throws InterruptedException {
        Set<String> sentinels = new HashSet<String>();
        String hostAndPort1 = "192.168.1.111:26379";
        String hostAndPort2 = "192.168.1.111:26380";
        String hostAndPort3 = "192.168.1.111:26381";
        sentinels.add(hostAndPort1);
        sentinels.add(hostAndPort2);
        sentinels.add(hostAndPort3);

        String clusterName = "mymaster";
        String password = "12345678";

        JedisSentinelPool redisSentinelJedisPool = new JedisSentinelPool(clusterName, sentinels, password);

        Jedis jedis = null;
        try {
            jedis = redisSentinelJedisPool.getResource();

            //jedis.set("name", "james11");
            System.out.println(jedis.get("name"));
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            redisSentinelJedisPool.returnBrokenResource(jedis);
        }

        redisSentinelJedisPool.close();
    }