7_Redis 主从复制和哨兵机制

1.是什么

        主机数据更新后根据配置和策略，自动同步到备机的master/slaver 机制，Master以写为主，Slave以读为主

2.能干什么

       1.读写分离

        2.容灾恢复

3.怎么玩

       1.配从（库）不配主（库）
       2.从库配置：slaveof  主库ip  主库端口
            每次与master断开之后，都需要重新连接，除非配置redis.conf文件
            info replication 查看当前redis 角色
            
        3.修改配置文件细节操作
            1.拷贝多个redis.conf文件
                cp /myredis/redis.conf redis6379.conf
                cp /myredis/redis.conf redis6380.conf
                cp /myredis/redis.conf redis6381.conf
                
                vim redis6379.conf
                    
            2.开启daemonize yes
            
            3.pid 文件名
                修改
                pidfile /var/run/redis.pid
                为
                pidfile /var/run/redis6379.pid
                
            4. 指定端口

                6379
                
            5.log文件名字
                修改
                logfile ""
                为
                logfile "6379.log"
                
            6.Dump.rdb名字
               修改
                dbfilename dump.rdb
                为
                dbfilename dump6379.rdb    
                
                修改6380，6381 重复上一步骤 将数字换成对应的6380和6381
                
                从机上要配置对应的主机(拜老大)
               从机分别执行    slaveof 127.0.0.1 6379

               或者 

                    在redis.conf 配置中 slaveof  master 的ip 空格 port 

               主机上有的数据，都拷贝到从机上

4.常用三招
           4.1.一主二仆（缺点主机压力大）
                1.1 主机挂了，从机还是从机，主机还原了，从机不需要配置依旧可以连主机
                1.2 从机挂了，要重新配置，连接主机 slaveof 127.0.0.1 6379 

           一主一从
              用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要）
    
         一主多从（线上不允许这么做：最多1-2个节点）
                针对“读”较多的场景，“读”有多个从节点来分担，但节点越多，主节点同步到多节点的次数越多，影响带宽，也加重主节点的稳定
            

           4.2.薪火相传 （缺点有延时）
                上一个slave可以是下一个slave的master,slave同样可以接收其他
                slaves的连接和同步请求，那么该slave作为了连接中下一个的master,可以
                有效减轻master的写压力
                中途变更转向：会清除之前的数据，重新建立拷贝最新的
                Slaveof新主库ip新主库端口
                
                将81的master 改成80
                slaveof 127.0.0.1 6380  
                继续主从复制
        
            4.3.反客为主 
                是当前数据库停止与其他数据库的同步，转成主数据库
                1.主机挂掉
                一个从机执行 --> slaveof no one --> 手动使当前的机器变为主机
                其他从机重新配置主机 ip 和端口号-->slaveof 127.0.0.1 6380

              传输延时：主从一般部署在不同机器上，复制时存在网络延时问题
                              redis提供repl-disable-tcp-nodely参数决定是否关闭TCP_NODELAY默认关闭
    
               参数关闭时
                      无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，
               参数启用时
                      主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，
                      主从的同步延时40毫秒，适用于网络环境复杂或带宽紧张，如跨机房
                 

          同步原理
                    执行完slave master port 后
                    与主节点连接，同步主节点的数据 info replication 查看主从及同步信息
        
                     配置完 slaveof 127.0.0.1 6379 
                     slave 6380启动
            
                     1.保存主节点信息
                     2.主从建立socket连接
                     3.发送ping命令
                     4.权限验证
                     5.同步数据集
                     6.命令持续复制
            
                      master:6379

            4.4 哨兵模式
                反客为主的自动版，能够后台监控主机是否故障
                如果后台故障了根据投票数自动将从库转换为主库
    
                1.调整机构
                2.自定义的/myredis目录下新建sentinel.conf文件，名字不能错
                    touch sentinel.conf
                    
                    配置哨兵，填写内容 sentinel monitor 被监控数据库名字（自己起名字）127.0.0.1 6379 1
                    sentinel monitor host6379 127.0.0.1 6379 1  得票数多余1票的称为主机
                    
                    上面最后一个数字1，表示主机挂掉后slave投票看谁接替成为主机，得票数多少后成为主机
                
                3.启动哨兵
                    redis-sentinel    /myredis/sentinel.conf
                    上述目录依照各自的实际情况配置，可能目录不同
                    
                4.正常主从演示
                    原有master挂掉
                    投票新选
                    重新主从继续开工info replication 查查看
                    问题：如果之前的master重新回来，会不会双master冲突？
                        主机回来了，然后被哨兵巡逻到，变成slave,80还是主机的不会变角色
                
                5. 一组sentinel能同时监控多个Master  类似于spring.xml配置多个bean 
                
                复制缺点 -- 复制延迟
                    由于所有的写操作都是现在master上操作，然后同步更新到slave上，所以从master同步到slave
                    机器有一定的延迟，当系统和繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会使
                    这个问题更加严重
    
                复制原理
                    Slave 启动成功连接到master后会发送一个sync命令Master接到命令启动后台的进程，同时收集
                所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,
                以完成一次完全同步
                
                全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，
                增量复制: Master 继续将新的所有收集到的修改命令一次传递给slave,完成同步，但是只要是重新
                          连接master,一次完全同步，
                （全量复制）将被自动执行

         

    一、什么是高可用
        1.它与被认为是不间断操作的容错技术有所不同，是目前企业防止核心系统因故障而无法
          工作的最有效保护手段
        
        2.高可用一般指服务的冗余，一个服务挂了，可以自动切换到另外一个服务上不影响客户体验
        
        
    哨兵机制
        哨兵有三个定时任务完成对各节点的发现和监控
        1.每隔10秒发送一次info  当有新节点的加入检测到新节点
        2.每隔2秒发一次publish/subscribe  发布和订阅
        3.每隔1秒发一次ping        
          
         当主机节点6379 挂掉了，主机换成6380 ,然后主节点6380同步到6381从节点数据过程是由哨兵监控
        完成的，哨兵之间也会推选出领袖。         
        
    领导者哨兵选举流程
        A.哨兵3发现主观下线
        B.发送is-masterdown-by-addr,征求其它哨兵判断
        C.其它哨兵1同意
        D.其它哨兵2同意
        E.哨兵3称为领导者，负责故障处理
    
        故障转移流程A
        A.由Sentinel节点定期监控发现主节点是否出现故障，Sentinel回向master发送心跳PING来确认master
          是否存活，如果master在“一定时间范围”，内不回应PONG或者是回复了一个错误消息，那么这个sentinel
          会主观地（单方面）认为这个master已经不可用了。
    
        故障转移流程B
        B.当主节点出现故障，此时假设3个Sentienl节点共同选举了Sentinel3节点为领导者sentinel,负载处理
        主节点的故障转移
        
        故障转移流程C
        C.由Sentinel3领导者节点故障转移，过程和主从复制一样，但是自动执行
        1.slave-1执行，slaveof no one 解除从节点身份，变成新master
        2.slave-2变成新master的从节点 slaveof new master
        3.同样，若原主节点恢复也变成新主节点的从节点
        4.通知应用程序新主节点的地址
        
         故障转移详细流程
         1.sentinel有一份从节点列表
         2.过滤掉不健康的节点，没有回复哨兵ping消息
         3.选择slave-priority优先级最高的从节点
          3.1是，选择完毕
          3.2否，继续选择，选择复制最完整的节点--选择完毕
         
        哨兵的安装部署
        之前的redis6379.conf的配置不变，作为主节点，并且复制出两个配置文件，redis6380.co
        redis6381.conf 这两个配置文件启动后的redis作为6379节点的从节点

        注意：redis6380.conf和redis6381.conf加上 slaveof 127.0.0.1 6379
              修改requirepass 12345678,注释掉bind 127.0.0.1 加上masterauth 12345678
              
        redis sentienl哨兵机制配置（也是3个节点）
                /usr/local/bin/conf/sentienl_26379.conf
                /usr/local/bin/conf/sentienl_26380.conf
                /usr/local/bin/conf/sentienl_26381.conf
        
        将三个文件的端口改为26379、26380、26381
        然后：sentienl monitor mymaster 127.0.0.6379 2  //监听主节点 6379
              sentinel auth-pass mymaster 12345678      //连接主节点是的密码
              
        三个配置出端口外，其他一样
                启动sentienl服务
                        ./redis-sentinel conf/sentinel_26379.conf &
                        ./redis-sentinel conf/sentinel_26380.conf &
                        ./redis-sentienl conf/sentienl_26381.conf
                    
                测试：kill -9 6379 的redis 服务

        看日志是分配6380，还是6381作为主节点，当6379服务在启动时，已变成从节点
        
        如果6380升级为主节点：进入6380> info replication 可以看到role:master 
        打开sentinel_26379.conf等三个配置，sentinel monitor mymaster 127.0.0.1 6380 2
                外部应用连接sentinel时，sentinel.conf的protected-mode no 改为no 
                ./redis-cli -p 26380 shutdown  //关闭
            
        
        RedisSentinel如何监控2个reids主节点？
            在原配置上加一句：sentinel monitor mymasterB 192.168.1.112. 6379  2
            
        
        部署建议
        a.sentinel 节点应部署在多台物理机（线上环境）
        b.至少三个且奇数个sentinel节点
        c.3个sentinel 可同时监控一个主节点或多个主节点，当监听N个主节点较多时，如果
          sentienl出现异常，会对多个主节点有影响，同时还会造成sentinel节点产生过多的
          网络连接，一般线上建议还是，3个sentinel监听一个主节点
          
         哨兵的API
         命令：reids-cli -p 6379  // 进入哨兵的命令模式，使用redis-cli进入
         
         sentinel master 或sentinel master mymaster 
         sentinel slaves mymaster 
         sentinel sentinels mymaster //查sentinel节点集合（不包含当前26379）
         sentinel failover mymaster //对主节点强制故障转移，没和其它节点协商
         
         ./redis-cli -p 26380 shutdown //关闭