过时的技术：在Redis2.x单物理节点上借助redis-sentinel实现redis“一主二仆”模式的高可用

1、理论基础 

1、redis主从复制机制:
    主节点数据更新后通过相关配置自动同步数据到从节点上的机制称之为redis的主从复制机制。
    

    意义：
        读写分离
        容灾恢复

2、读写分离
    redis的Master-Slave机制中，主节点Master以写为主（可以读），备节点Slave以读为主（不可写）。

2、redis安装

1、yum -y install gcc tcl  
#####这个tcl是后续执行完第3步检查安装时“make test”要用的，不检查可以不装，对后续不会有任何影响
 
2、cd /opt/source && tar zxvf redis-3.0.0.tar.gz -C ../apps
 
3、cd ../apps/redis-3.0.0 && make
 
4、make PREFIX=/opt/apps/redis-3.0.0 install 
 
5、vi + /etc/profile
 
        export REDIS_HOME=/opt/redis-3.0.0
 
        export PATH=$PATH:$REDIS_HOME/bin
 
    source /etc/profile

3、配置redis.conf

配置redis.conf的理论基础：
    由于我们集群模式是一主二从，所以我们在单机上启动三个redis服务模拟redis的三个节点。

1、cd /opt/apps/redis-3.0.0/ && mkdir sentinel-cluster  

2、cd sentinel-cluster && mkdir node7001 node7002 node7003

3、cp ../redis.conf node7001/ && cp ../redis.conf node7002/ && cp ../redis.conf node7003/

4、vi node700*/redis.conf    
    daemonize no改为daemonize yes
    port 6379改为port 700*
    pidfile /var/run/redis.pid改为pidfile /var/run/redis-sentinel/redis700*.pid
    logfile ""改为logfile "/opt/apps/redis-3.0.0/sentinel-cluster/node700*/700*.log"
    dir ./改为dir /opt/apps/redis-3.0.0/sentinel-cluster/node700*/

    注意：
        #####700*代表7001、7002、7003

5、vi node700*/redis.conf
    添加：
        slaveof 127.0.0.1 7001

     注意：
        1、700*代表7002、7003
        2、这一步其实可以不配置，可以在从节点进入客户端后执行“slaveof 主节点ip 主节点端口 ”也可以。只不过这样的话每次从节点宕机，重新连接后都需要执行该命令。配置文件方式则不用。

4、配置sentinel

1、cd /opt/apps/redis-3.0.0/sentinel-cluster && mkdir sentinel.conf

2、vi sentinel.conf
    sentinel monitor Linux005 127.0.0.1 7001 1
    
    解释：
        Linux005:主节点的名字
        127.0.0.1：主节点的IP。
        7001：主节点redis服务的端口
        1:主节点宕机后从节点票数超过1则升级为主节点

    注意：
        主节点宕机后续选举新的主节点端口就不一样了，但这儿写7001当新的主节点7002宕机后，哨兵依然能够监控到。IP不同的情况没测试过。

5、启动集群

打开四个会话窗口，执行以下命令

1、cd /opt/apps/redis-3.0.0/sentinel-cluster/ && redis-server node7001/redis.conf && redis-cli -p 7001
    #####第一个会话窗口

2、cd /opt/apps/redis-3.0.0/sentinel-cluster/ && redis-server node7002/redis.conf && redis-cli -p 7002
    #####第二个会话窗口

3、cd /opt/apps/redis-3.0.0/sentinel-cluster/ && redis-server node7003/redis.conf && redis-cli -p 7003
    #####第三个会话窗口

4、cd /opt/apps/redis-3.0.0/sentinel-cluster/ && redis-sentinel sentinel.conf
    #####第四个会话窗口

6、测试

1、查看三个节点的状态

    7001：
    127.0.0.1:7001> info replication
    # Replication
    role:master    #####主节点
    connected_slaves:2    #####有两个从节点
    slave0:ip=127.0.0.1,port=7002,state=online,offset=22585,lag=1    #####从节点1状态
    slave1:ip=127.0.0.1,port=7003,state=online,offset=22718,lag=0    #####从节点2状态


    7002：
    127.0.0.1:7002> info replication
    # Replication
    role:slave    #####从节点
    master_host:127.0.0.1    #####主节点ip
    master_port:7001    #####主节点端口
    master_link_status:up    #####与主节点建立连接


    7003：
    127.0.0.1:7003> info replication
    # Replication
    role:slave    #####从节点
    master_host:127.0.0.1    #####主节点ip
    master_port:7001    #####主节点端口
    master_link_status:up    #####与主节点建立连接


2、读写分离

    127.0.0.1:7001> set k1 v1
    OK
    127.0.0.1:7001> get k1
    "v1"            #####主节点能读能写

    127.0.0.1:7002> get k1
    "v1"
    127.0.0.1:7002> set k2 v2
    (error) READONLY You can't write against a read only slave.
                    #####从节点只能读

    127.0.0.1:7003> get k1
    "v1"
    127.0.0.1:7003> set k2 v2
    (error) READONLY You can't write against a read only slave.
                    #####从节点只能读
    注意：
        从节点能够读取主节点所有的数据，无论是与主节点建立连接前的还是建立连接后的。


3、主节点宕机

    127.0.0.1:7001> shutdown
    not connected> exit

    
    127.0.0.1:7002> info replication
    # Replication
    role:master    #####7002从节点切换成主节点
    connected_slaves:1    #####有一个从节点
    slave0:ip=127.0.0.1,port=7003,state=online,offset=3965,lag=1    #####从节点状态

    127.0.0.1:7003> info replication
    # Replication
    role:slave
    master_host:127.0.0.1
    master_port:7002    #####依然是从节点，但是主节点变成了7002  
    master_link_status:up    #####与主节点处于连接状态



    注意：
        1、主节点宕机后，哨兵会自动从从节点中切换选举出一个主节点。
        2、哨兵将从节点切换成主节点的这个过程需要一定的时间，网络良好可能零点几秒，网络不好可能一两秒。
        3、在高并发的情况下，一秒可以写数十万条数据，所以主节点切换这一时间可能导致大量数据丢失。
        4、这种情况我们只能通过java代码来控制。在主节点宕机，从节点还未上位前，会抛出一个“cluster is down”的Exception。我们可以捕获该异常后让程序sleep一两秒的时间，然后重新执行try块内容。
        
        5、主节点宕机再次恢复时，该主节点就成了新主节点的从节点了。

7、总结

总结：
    1、 “一主二仆”模式的中心化太过于严重。redis还有一种“薪火相传式”的集群，即上一个slave是下一个slave的master，有兴趣的同学可以自己研究下。
    2、哨兵式集群HA的切换耗时较长，在高并发的情况下可能会导致大量数据丢失。
    3、这种情况我们只能通过java代码来控制。在主节点宕机，从节点还未上位前，会抛出一个“cluster is down”的Exception。我们可以捕获该异常后让程序sleep一两秒的时间，然后重新执行try块内容。

    4、在redis3.0后redis开始支持redis-cluster模式。该模式会在我的下一篇博客中讲解。