Redis主从复制

    主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性

一. 主从复制的相关操作

    a,配置主从复制方式一、新增redis6380.conf, 加入 slaveof 192.168.152.128 6379, 在6379启动完后再启6380，完成配置；
    b,配置主从复制方式二、redis-server --slaveof 192.168.152.128 6379 临时生效

    c,查看状态：info replication

     d,断开主从复制：在slave节点，执行6380:>slaveof no one
     e,断开后再变成主从复制：6380:> slaveof 192.168.152.128 6379
     f,数据较重要的节点，主从复制时使用密码验证： requirepass
    e,从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致
    h,传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭
    参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，
    参数启用时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房

二. Redis主从拓扑

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

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

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

三. 主从复制原理

四. 数据同步

    redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制
    全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）
    部分复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步
    心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率

五. 主从的缺点

    a)主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主
    b)主从复制主节点的写能力单机，能力有限
    c)单机节点的存储能力也有限

六.主从故障如何故障转移

    a)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；
    b)其它的节点成为新主节点的从节点，并从新节点复制数据；
    c)需要人工干预，无法实现高可用。

Redis主从复制

    主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性

一. 主从复制的相关操作

    a,配置主从复制方式一、新增redis6380.conf, 加入 slaveof 192.168.152.128 6379, 在6379启动完后再启6380，完成配置；
    b,配置主从复制方式二、redis-server --slaveof 192.168.152.128 6379 临时生效

    c,查看状态：info replication

     d,断开主从复制：在slave节点，执行6380:>slaveof no one
     e,断开后再变成主从复制：6380:> slaveof 192.168.152.128 6379
     f,数据较重要的节点，主从复制时使用密码验证： requirepass
    e,从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致
    h,传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭
    参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，
    参数启用时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房

二. Redis主从拓扑

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

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

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

三. 主从复制原理

四. 数据同步

    redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制
    全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）
    部分复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步
    心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率

五. 主从的缺点

    a)主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主
    b)主从复制主节点的写能力单机，能力有限
    c)单机节点的存储能力也有限

六.主从故障如何故障转移

    a)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；
    b)其它的节点成为新主节点的从节点，并从新节点复制数据；
    c)需要人工干预，无法实现高可用。