Redis集群介绍及安装（redis-cluster）

一、Redis集群介绍及原理：

1、Redis集群介绍：

Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。

Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误.

Redis 集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下继续处理命令. Redis 集群的优势:

自动分割数据到不同的节点上。
整个集群的部分节点失败或者不可达的情况下能够继续处理命令。

2、redis-cluster 优点：

      支持数据分片功能，可以将数据分配到不同的实例上
        服务的高可用性、故障自动转移，最大程度避免单点故障
      在线水平扩展能力，可以在线添加节点，转移数据等
        无中心架构，各个节点度等
        降低原有的数据分片方案的复杂度，节省硬件资源
        系统瓶颈更少，客户端直连方式

3、Redis 集群的数据分片：

Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念.

Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:

节点 A 包含 0 到 5500号哈希槽.
节点 B 包含5501 到 11000 号哈希槽.
节点 C 包含11001 到 16384号哈希槽.

这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.

4、Redis 集群的主从复制模型：

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品.

在我们例子中具有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.

然而如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了

不过当B和B1 都失败后，集群是不可用的.

5、Redis 一致性保证：

Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作.

第一个原因是因为集群是用了异步复制. 写操作过程:

客户端向主节点B写入一条命令.
主节点B向客户端回复命令状态.
主节点将写操作复制给他得从节点 B1, B2 和 B3.

主节点对命令的复制工作发生在返回命令回复之后，因为如果每次处理命令请求都需要等待复制操作完成的话，那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。注意：Redis 集群可能会在将来提供同步写的方法。 Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区，并且一个客户端与至少包括一个主节点在内的少数实例被孤立。

举个例子假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点，其中 A 、B 、C 为主节点， A1 、B1 、C1 为A，B，C的从节点，还有一个客户端 Z1 假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ，小部分的一方则包含节点 B 和客户端 Z1 .

Z1仍然能够向主节点B中写入, 如果网络分区发生时间较短,那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了.

注意，在网络分裂出现期间，客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的，这一时间限制称为节点超时时间（node timeout），是 Redis 集群的一个重要的配置选项

6、redis集群实现方案：

关于redis的集群化方案目前有三种

（1）Twitter开发的twemproxy

（2）豌豆荚开发的codis

（3）redis官方的redis-cluster

简介：twemproxy架构简单就是用proxy对后端redis server进行代理但是由于代理层的消耗性能很低而且通常涉及多个key的操作都是不支持的而且本身不支持动态扩容和透明的数据迁移而且也失去维护 Twitter内部已经不使用了

redis-cluster是三个里性能最强大的因为他使用去中心化的思想使用hash slot方式将16348个hash slot 覆盖到所有节点上对于存储的每个key值使用CRC16(KEY)&16348=slot 得到他对应的hash slot 并在访问key时就去找他的hash slot在哪一个节点上然后由当前访问节点从实际被分配了这个hash slot的节点去取数据节点之间使用轻量协议通信减少带宽占用性能很高自动实现负载均衡与高可用自动实现failover 并且支持动态扩展官方已经玩到可以1000个节点实现的复杂度低总之个人比较喜欢这个架构因为他的去中心化思想免去了proxy的消耗是全新的思路

但是它也有一些不足例如官方没有提供图形化管理工具运维体验差全手工数据迁移并且自己对自己本身的redis命令支持也不完全等但是这些问题我觉得不能掩盖他关键的新思想所带来的的优势随着官方的推进这些问题应该都能在一定时间内得到解决那么这时候去中心化思想带来的高性能就会表现出他巨大的优势

codis使用的也是proxy思路但是做的比较好是这两种之间的一个中间级而且支持redis命令是最多的有图形化GUI管理和监控工具运维友好这个过段时间会详细另外写出来原理工作机制和搭建实现

7、redis-cluster集群原理：

redis-cluster架构图

所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value

Redis集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value 时，redis 先对key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点

redis-cluster投票:容错

投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉.
什么时候整个集群不可用(cluster_state:fail)?
- 如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态.
  - redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.
- 如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.

二、redis-cluster搭建：

1、官网下载最新的Redis包http://www.redis.cn/download.html

tar -zxvf redis-5.0.0.tar.gz　         #解压包
cd redis-5.0.0
make && make install                   #安装Redis

2、集群搭建准备工作

mkdir redis-cl                        #新建文件夹所有节点都安装到此文件夹下
cd redis-cl                           
mkdir 7000                            #准备第一个节点安装位置
cd redis-5.0.0/src
cp redis-trib.rb  redis-cl            #拷贝集群文件到集群文件夹下
cp redis.conf redis-cl/7000           #拷贝Redis配置文件到7000节点下

3、修改配置文件

port  7000                                                 #端口7000        
bind 本机ip                                                #默认ip为127.0.0.1 需要改为其他节点机器可访问的ip 否则创建集群时无法访问对应的端口，无法创建集群
daemonize    yes                                           #redis后台运行
pidfile  /var/run/redis_7000.pid                           #pidfile文件对应7000
cluster-enabled  yes                                       #开启集群  把注释#去掉
cluster-config-file  nodes_7000.conf                       #集群的配置  配置文件首次启动自动生成 7000
cluster-node-timeout  15000                                #请求超时  默认15秒，可自行设置
appendonly  yes                                            #aof日志开启  有需要就开启，它会每次写操作都记录一条日志

接着把7000文件夹复制到通文件夹5份分别命名为7001,7002,7003,7004,7005，然后把里边的redis.conf的所有7000改为对应节点

4、启动所有节点

redis-server 7000/redis.conf
redis-server 7001/redis.conf
redis-server 7002/redis.conf
redis-server 7003/redis.conf
redis-server 7004/redis.conf
redis-server 7005/redis.conf

5、查看节点启动情况

ps -ef | grep redis

netstat -tnlp | grep redis

6、创建集群

yum -y install ruby ruby-devel rubygems rpm-build   

gem install redis                                     #因为集群是ruby开发所以需要下载相关依赖


cd redis-cl                           #进入到集群文件夹，找到之前拷贝的集群文件redis-trib.rb

redis-trib.rb  create  --replicas  1  198.216.15.12:7000 198.216.15.12:7001  198.216.15.12:7002 198.216.15.12:7003  198.216.15.12:7004  198.216.15.12:7005 
#执行命令完成集群安装

这个时候我的报错了

根据错误知道是redis-trib.rb不再使用了，要替换成

redis-cli --cluster create 198.216.15.12:7000 198.216.15.12:7001 198.216.15.12:7002 198.216.15.12:7003 198.216.15.12:7004 198.216.15.12:7005 --cluster-replicas 1

所以我们需要把redis -cli文件拷贝到集群文件夹下，还是在src下，拷贝执行，出现以下信息成功

7、集群验证

redis-cli -c -h 198.216.15.12 -p 7000        #进去集群的12机器的7000端口

验证整个集群是没有问题的

cluster nodes         #进入节点后执行，查看节点信息

cluster info          #查看节点状态信息

信息如下

到此我们的单机版伪集群就搭建完成了，多个机器其实原理一样

增加删除节点等请参考官网：http://www.redis.cn/topics/cluster-tutorial.html