环境
虚拟机：VMware 10
Linux版本：CentOS-6.5-x86_64
客户端：Xshell4
FTP：Xftp4
jdk8
redis-2.8.18
Redis集群分类：
主从复制 Replication：镜像：增删改（主<退化到单节点>）查询负载到从节点
高可用 Sentinel
分布式 twemproxy：切片
集群 Cluster
一、主从复制：从节点全量复制主节点镜像，使用单节点执行增删改操作，使用一堆从节点执行查询
(1)一个Redis服务可以有多个该服务的复制品，这个Redis服务称为Master，其他复制品称为Slaves；
只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步，同步数据方式是异步的，不确认同步任务是否成功。
(2)只有Master可以执行写命令，Slaves只能执行读命令，从服务器执行客户端发送的读命令，比如GET、LRANGE、SMEMMBERS、HGET、ZRANGE等等，客户端可以连接Slaves执行读请求，来降低Master的读压力
(3)主从切换是手动的，使用Sentinel哨兵，实现故障自动转移Failover操作
1、主从复制创建的两种方式：
(1)配置方式：
启动时，服务器读取配置文件，并自动成为指定服务器的从服务器
slaveof <masterip> <masterport>
(2)命令方式：
redis-server --slaveof <master-ip> <master-port>，配置当前服务称为某Redis服务的Slave
# redis-server --port 6380 --slaveof 127.0.0.1 6379
SLAVEOF host port命令，将当前服务器状态从Master修改为别的服务器的Slave
redis > SLAVEOF 192.168.1.1 6379，将服务器转换为Slave
redis > SLAVEOF NO ONE ，将服务器重新恢复到Master，不会丢弃已同步数据
搭建伪分布式主从复制架构示例：
同一个节点启动三个redis实例
主：[cluster@PCS103 ~]$ redis-server --port 6380 从1：[cluster@PCS103 ~]$ redis-server --port 6381 --slaveof 127.0.0.1 6380 从2：[cluster@PCS103 ~]$ redis-server --port 6382 --slaveof 127.0.0.1 6380
(1)主节点赋值，从节点取值：
[root@PCS103 bin]# redis-cli -h PCS103 -p 6380 --raw
PCS103:6380> set k1 djfklsdk
OK
[root@PCS103 bin]# redis-cli -h PCS103 -p 6381 --raw
PCS103:6381> get k1
"djfklsdk"
(2)从节点赋值报错：
PCS103:6381> set k2 1212
(error) READONLY You can't write against a read only slave.
(3)主掉线，将6381升为主，6382修改为6381的从
PCS103:6381> SLAVEOF NO ONE
OK
PCS103:6382> SLAVEOF 127.0.0.1 6381
OK
PCS103:6382> get k1
"djfklsdk"
(4)6380重新上线，改为6381的从
[cluster@PCS103 ~]$ redis-server --port 6380 --slaveof 127.0.0.1 6381
PCS103:6380> get k1
"djfklsdk"
二、哨兵-Sentinel（3.0之前版本的做法）
主从复制下的高可用方案：
(1)Sentinel会不断检查Master和Slaves是否正常，在Master下线后自动执行Failover操作，提升一台Slave为Master，并让其他Slaves重新成为新Master的Slaves;
(2)哨兵可以监控任意多个Master和该Master下的Slaves，
(3)多个哨兵可以只监控1个Master和该Master下的Slaves，监控同一个Master的Sentinel会自动连接，组成一个分布式的Sentinel网络，互相通信并交换彼此关于被监视服务器的信息
(4)主从复制+哨兵Sentinel只解决了读性能和高可用问题，但是没有解决写性能问题
1、配置文件sentinel.conf
(1)Sentinel默认端口号为26379
(2)指定被监控Master的相关信息,Sentinel会根据Master的配置自动发现Master的Slaves
Sentinel monitor <name> <ip> <port> <quorum>
master别名 masterIP master端口 选举得票最小数
监视mymaster的主服务器，将这个主服务器判断为下线失效至少需要quorum个Sentinel同意，如果多数Sentinel同意才会执行故障转移
2、启动 Sentinel
首先启动一个Redis服务实例
其次启动哨兵：redis-sentinel sentinel.conf
举例：
搭建伪分布式主从复制架构示例,同一个节点启动三个redis实例
主：[cluster@PCS103 ~]$ redis-server --port 6380 从1：[cluster@PCS103 ~]$ redis-server --port 6381 --slaveof 127.0.0.1 6380 从2：[cluster@PCS103 ~]$ redis-server --port 6382 --slaveof 127.0.0.1 6380
配置三个哨兵：
sentinel1.conf：
port 26380
Sentinel monitor wjy 127.0.0.1 6380 2
sentinel2.conf：
port 26381
Sentinel monitor wjy 127.0.0.1 6380 2
sentinel3.conf：
port 26382
Sentinel monitor wjy 127.0.0.1 6380 2
启动三个哨兵：
[cluster@PCS103 ~]$redis-sentinel sentinel1.conf [cluster@PCS103 ~]$redis-sentinel sentinel2.conf [cluster@PCS103 ~]$redis-sentinel sentinel3.conf
3、监控过程
当一个sentinel认为被监视的服务器已经下线时，它会向网络中的其他Sentinel进行确认，判断该服务器是否真的已经下线
如果下线的服务器为主服务器，那么sentinel网络将对下线主服务器进行自动故障转移，通过将下线主服务器的某个从服务器提升为新的主服务器，并让其从服务器转为复制新的主服务器，以此来让系统重新回到上线的状态
