redis集群是一个无中心的分布式redis存储架构，可以在多个节点之间进行数据共享，解决了redis高可用、可扩展等问题，redis集群提供了以下两个好处：
1）将数据自动切分(split)到多个节点
2）当集群中的某一个节点故障时，redis还可以继续处理客户端的请求
一个 Redis 集群包含 16384 个哈希槽（hash slot），数据库中的每个数据都属于这16384个哈希槽中的一个 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽 集群中的每一个节点负责处理一部分哈希槽
集群中的主从复制
集群中的每个节点都有1个至N个复制品，其中一个为主节点，其余的为从节点，如果主节点下线了，集群就会把这个主节点的一个从节点设置为新的主节点，继续工作 这样集群就不会因为一个主节点的下线而无法正常工作
Redis Cluster集群功能推出已经有一段时间了 在单机版的Redis中，每个Master之间是没有任何通信的，所以一般在Jedis客户端或者Codis这样的代理中做Pre-sharding 按照CAP理论来说，单机版的Redis属于保证CP(Consistency & Partition-Tolerancy)而牺牲A(Availability)，也就说Redis能够保证所有用户看到相同的数据（一致性，因为Redis不自动冗余数据）和网络通信出问题时，暂时隔离开的子系统能继续运行（分区容忍性，因为Master之间没有直接关系，不需要通信），但是不保证某些结点故障时，所有请求都能被响应（可用性，某个Master结点挂了的话，那么它上面分片的数据就无法访问了）
有了Cluster功能后，Redis从一个单纯的NoSQL内存数据库变成了分布式NoSQL数据库，CAP模型也从CP变成了AP 也就是说，通过自动分片和冗余数据，Redis具有了真正的分布式能力，某个结点挂了的话，因为数据在其他结点上有备份，所以其他结点顶上来就可以继续提供服务，保证了Availability 然而，也正因为这一点，Redis无法保证曾经的强一致性了 这也是CAP理论要求的，三者只能取其二
Redis Cluster 是Redis的集群实现，内置数据自动分片机制，集群内部将所有的key映射到16384个Slot中，集群中的每个Redis Instance负责其中的一部分的Slot的读写 集群客户端连接集群中任一Redis Instance即可发送命令，当Redis Instance收到自己不负责的Slot的请求时，会将负责请求Key所在Slot的Redis Instance地址返回给客户端，客户端收到后自动将原请求重新发往这个地址，对外部透明 一个Key到底属于哪个Slot由crc16(key) % 16384 决定 在Redis Cluster里对于负载均衡和HA相关都已经支持的相当完善了
负载均衡（Load Balance）：集群的Redis Instance之间可以迁移数据，以Slot为单位，但不是自动的，需要外部命令触发
集群成员管理：集群的节点(Redis Instance)和节点之间两两定期交换集群内节点信息并且更新，从发送节点的角度看，这些信息包括：集群内有哪些节点，IP和PORT是什么，节点名字是什么，节点的状态(比如OK，PFAIL，FAIL，后面详述)是什么，包括节点角色(master 或者 slave)等
关于可用性，集群由N组主从Redis Instance组成
主可以没有从，但是没有从 意味着主宕机后主负责的Slot读写服务不可用
一个主可以有多个从，主宕机时，某个从会被提升为主，具体哪个从被提升为主，协议类似于Raft，参见这里 如何检测主宕机？Redis Cluster采用quorum+心跳的机制 从节点的角度看，节点会定期给其他所有的节点发送Ping，cluster-node-timeout(可配置，秒级)时间内没有收到对方的回复，则单方面认为对端节点宕机，将该节点标为PFAIL状态 通过节点之间交换信息收集到quorum个节点都认为这个节点为PFAIL，则将该节点标记为FAIL，并且将其发送给其他所有节点，其他所有节点收到后立即认为该节点宕机 从这里可以看出，主宕机后，至少cluster-node-timeout时间内该主所负责的Slot的读写服务不可用
redis cluster集群是为了降低单节点或单纯主从redis的压力，主主节点之间是不存在同步关系的，各主从之间的数据存在同步关系 有多少主节点，就会把16384个哈希槽（hash slot）平均分配到这些主节点上，当往redis里写入数据时，会根据哈希算法算出这个数的哈希槽，决定它放到哪一个主节点上，然后这个主节点的从节点去自动同步 在客户端随便连接一个主节点即可，主节点之间会进行内部跳转！当取对应数据时，各节点之间会自动跳转到所取数据所在的主节点上！
1）redis cluster节点分配
假设现有有三个主节点分别是：A、 B、C ，它们可以是一台机器上的三个端口，也可以是三台不同的服务器 那么，采用哈希槽 (hash slot)的方式
来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：
节点A 覆盖0－5460;
节点B 覆盖5461－10922;
节点C 覆盖10923－16383.
获取数据：
如果存入一个值，按照redis cluster哈希槽的算法： CRC16('key')%16384 = 6782 那么就会把这个key 的存储分配到 B 上了 同样，当我连接
(A,B,C)任何一个节点想获取'key'这个key时，也会这样的算法，然后内部跳转到B节点上获取数据
新增一个主节点：
新增一个节点D，redis cluster的这种做法是从各个节点的前面各拿取一部分slot到D上，我会在接下来的实践中实验 大致就会变成这样：
节点A 覆盖1365-5460
节点B 覆盖6827-10922
节点C 覆盖12288-16383
节点D 覆盖0-1364,5461-6826,10923-12287
同样删除一个节点也是类似，移动完成后就可以删除这个节点了
2）Redis Cluster主从模式
redis cluster 为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据
备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉
上面那个例子里, 集群有A、B、C三个主节点, 如果这3个节点都没有加入从节点，如果B挂掉了，我们就无法访问整个集群了 A和C的slot也无法访问
所以在集群建立的时候，一定要为每个主节点都添加了从节点, 比如像这样, 集群包含主节点A、B、C, 以及从节点A1、B1、C1, 那么即使B挂掉系统也
可以继续正确工作 B1节点替代了B节点，所以Redis集群将会选择B1节点作为新的主节点，集群将会继续正确地提供服务 当B重新开启后，它就会变成B1的从节点
不过需要注意，如果节点B和B1同时挂了，Redis集群就无法继续正确地提供服务了
由于最小的redis集群需要3个主节点（即Redis Cluster集群至少需要3个master节点，也就是说至少需要6个节点才能构建Redis cluster集群），一台机器可运行多个redis实例（一般使用两台机器，每台启动3个redis实例，即三个主节点，三个从节点） 很多案例使用单台服务器开6个端口，操作差不多，只是配置基本相对简单点，多台服务器更接近生产环境 【当集群最开始创建好后，要记住各节点的主从关系（或是创建的时候指定主从关系）；若是其中一台机器重启，重启后，需重新将其加入到redis cluster集群中；这就需要将这台机器上的各节点之前的从节点变为主节点（客户端执行slaveof no one），然后再根据新的主节点添加这台机器的各节点到集群中，添加后变为从节点】
环境 : CentOS7
redis01 : 192.168.94.11 端口 : 7000、7001、7002
redis02 : 192.168.94.22 端口 : 7003、7004、7005
redis03 : 192.168.94.33 端口 : 7006、7007、7008
关闭SElinux和防火墙
安装redis
[root@redis01 ~]# yum install -y gcc g++ make gcc-c++ kernel-devel automake autoconf libtool make wget tcl vim ruby rubygems unzip git [root@redis01 ~]# wget http://download.redis.io/releases/redis-4.0.1.tar.gz [root@redis01 ~]# tar xf redis-4.0.1.tar.gz -C /usr/local/src/ [root@redis01 ~]# cd /usr/local/src/redis-4.0.1/ [root@redis01 redis-4.0.1]# make && make test && make PREFIX=/usr/local/redis install [root@redis01 redis-4.0.1]# mkdir /usr/local/redis/conf [root@redis01 redis-4.0.1]# cp *.conf /usr/local/redis/conf/ [root@redis01 redis-4.0.1]# cp /usr/local/src/redis-4.0.1/src/redis-trib.rb /usr/local/redis/bin/ [root@redis01 redis-4.0.1]# ln -s /usr/local/redis/bin/* /usr/local/bin/ # 进行操作系统基础调优设置 [root@redis01 redis-4.0.1]# echo "* - nofile 10240" >> /etc/security/limits.conf [root@redis01 redis-4.0.1]# echo "net.core.somaxconn = 10240" >> /etc/sysctl.conf [root@redis01 redis-4.0.1]# echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf [root@redis01 redis-4.0.1]# sysctl -p net.core.somaxconn = 10240 vm.overcommit_memory = 1 [root@redis01 redis-4.0.1]# echo never > /sys/kernel/mm/transparent_hugepage/enabled [root@redis01 redis-4.0.1]# echo never > /sys/kernel/mm/transparent_hugepage/defrag [root@redis01 redis-4.0.1]# echo 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' >> /etc/rc.local [root@redis01 redis-4.0.1]# echo 'echo never > /sys/kernel/mm/transparent_hugepage/defrag' >> /etc/rc.local [root@redis01 redis-4.0.1]# su -l
创建节点
# 创建集群节点目录 [root@redis01 ~]# mkdir /data/redis/redis-cluster -p [root@redis01 redis-cluster]# cd /data/redis/redis-cluster/
[root@redis01 redis-cluster]# mkdir 7000 7001 7002
# 修改节点配置文件,为了测试方便, 只做初步的简单配置 [root@redis01 redis-cluster]# for i in 0 1 2; do echo -e "port 700$i\n\ bind `hostname -I`\n\ daemonize yes\n\ pidfile /var/run/redis_700$i.pid\n\ cluster-enabled yes\n\ cluster-config-file nodes_700$i.conf\n\ cluster-node-timeout 10100" > 700$i/redis.conf; done
cluster-enabled yes bind 0.0.0.0 port 7000 pidfile /data/redis-cluster/7000/redis.pid logfile "/data/redis-cluster/7000/redis.log" dir /data/redis-cluster/7000/ tcp-backlog 1024 timeout 0 tcp-keepalive 0 daemonize yes loglevel notice databases 16 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename "dump.rdb" slave-serve-stale-data yes slave-read-only yes repl-diskless-sync no repl-diskless-sync-delay 5 repl-disable-tcp-nodelay no slave-priority 100 lazyfree-lazy-eviction no lazyfree-lazy-expire no lazyfree-lazy-server-del no slave-lazy-flush no appendonly no appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes lua-time-limit 5000 slowlog-log-slower-than 10000 slowlog-max-len 128 latency-monitor-threshold 0 notify-keyspace-events "" hash-max-ziplist-entries 512 hash-max-ziplist-value 64 list-max-ziplist-entries 512 list-max-ziplist-value 64 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 activerehashing yes client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 hz 10 aof-rewrite-incremental-fsync yes