redis集群搭建（Cluster模式）

一、Cluster模式的特点

redis集群采用P2P模式，是完全去中心化的，不存在中心节点或者代理节点；
redis集群是没有统一的入口的，客户端（client）连接集群的时候连接集群中的任意节点（node）即可，集群内部的节点是相互通信的（PING-PONG机制），每个节点都是一个redis实例；
为了实现集群的高可用，即判断节点是否健康（能否正常使用），redis-cluster有这么一个投票容错机制：如果集群中超过半数的节点投票认为某个节点挂了，那么这个节点就挂了（fail）。这是判断节点是否挂了的方法；
那么如何判断集群是否挂了呢? -> 如果集群中任意一个节点挂了，而且该节点没有从节点（备份节点），那么这个集群就挂了。这是判断集群是否挂了的方法；
那么为什么任意一个节点挂了（没有从节点）这个集群就挂了呢？ -> 因为集群内置了16384个slot（哈希槽），并且把所有的物理节点映射到了这16384[0-16383]个slot上，或者说把这些slot均等的分配给了各个节点。当需要在Redis集群存放一个数据（key-value）时，redis会先对这个key进行crc16算法，然后得到一个结果。再把这个结果对16384进行求余，这个余数会对应[0-16383]其中一个槽，进而决定key-value存储到哪个节点中。所以一旦某个节点挂了，该节点对应的slot就无法使用，那么就会导致集群无法正常工作。
综上所述，每个Redis集群理论上最多可以有16384个节点。

tip：

PING-PONG机制：一种数据交换机制。

传统的数据交换机制：上级模块向下级模块发送数据，下级模块不能马上处理完成并返回，则上级模块会进行等待下级模块处理完成后，才会进行发送新的数据处理，会对性能产生影响

乒乓机制：上级模块不用等待下级模块处理完成，而是继续执行，并将执行结果保存至ping路的缓存中，当下级模块执行完毕后，会将处理结果保存至pong路中，这样上下级模块都无需等待，从而提高性能。

二、redis搭建方式特点分析

主从模式

默认情况下，主节点进行IO操作，从节点进行数据备份。每个从节点也可以进行写操作，但是不会同步至其他节点下。

缺点：主节点宕机，从节点不会变为主节点

哨兵模式（sentinel模式）

在主从复制的基础上增加哨兵。哨兵的作用就是在主节点宕机的情况下，在从节点中选举出新的主节点

哨兵是一个独立的进程，会通过与redis的通信，来判断redis主节点是否宕机。

三、环境准备

redis集群最少需要3个节点，因为容错机制需要过半的节点某个节点挂了，该节点才是挂了。所以两个节点无法形成集群。

redis-3.0.0

redis-3.2.1.gem

四、搭建步骤

1.上传tar包，并解压

tar -zxvf redis-3.0.0.tar.gz

修改解压后的文件夹名为redis

mv redis-3.0.0 redis

2.进入redis目录，进行编译

make MALLOC=libc

3.创建redis-cluster目录

mkdir redis-cluster

4.在redis-cluster中创建6379，6380，6381三个文件夹，用于存放配置信息

5.复制redis目录中的redis.conf分别之4中创建的三个文件夹，并进行修改

bind 127.0.0.1 //绑定服务器IP地址 port 6379 //绑定端口号，必须修改，以此来区分Redis实例 daemonize yes //后台运行 pidfile /var/run/redis-6379.pid //修改pid进程文件名，以端口号命名 logfile /app/redis-cluster/6379/redis.log //修改日志文件名称，以端口号为目录来区分 dir /app/redis-cluster/6379/ //修改数据文件存放地址，以端口号为目录名来区分 cluster-enabled yes //启用集群 cluster-config-file node-6379.conf //配置每个节点的配置文件，同样以端口号为名称 cluster-node-timeout 15000 //配置集群节点的超时时间，可改可不改 appendonly yes //启动AOF增量持久化策略 appendfsync always //发生改变就记录日志

6.依次启动三个redis节点

在redis的src目录下执行

如图所示，三个节点的redis都以启动成功

7.执行创建redis集群命令

./redis-trib.rb create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 由于本次搭建，为三个主节点，不存在从节点。若存在从节点，则应添加参数 --replicas 1（一个从节点）

这一步可能会报错，如下

没有安装ruby

yum install ruby yum install rubygems

由于ruby的gem源默认的时国外的地址，可能会连接不上，因此需要修改gem源
删除ruby默认的源
gem sources -r https://rubygems.org/
添加国内的源（淘宝源已经停止维护）
gem sources -a https://gems.ruby-china.com

gem install redis

也可以通过离线的方式安装，上传gem文件至服务器
gem install 文件名

8.查看各节点信息

登录其中一个redis节点

cluster nodes

五、知识点拓展

redis的持久化策略（两种持久化方式，4中持久化策略）：

RDB（数据快照模式），定期存储，保存的是数据本身，存储文件是紧凑的
AOF（追加模式），每次修改数据时，同步到硬盘(写操作日志)，保存的是数据的变更记录
如果只希望数据保存在内存中的话，俩种策略都可以关闭
也可以同时开启俩种策略，当Redis重启时，AOF文件会用于重建原始数据

RDB:

优点

存储的文件是紧凑的
适合用于备份，方便恢复不同版本的数据
适合于容灾恢复，备份文件可以在其他服务器恢复
最大化了Redis的性能，备份的时候启动的是子线程，父进程不需要执行IO操作
数据保存比AOF要快
缺点

如果Redis因为没有正确关闭而停止工作是，到上个保存点之间的数据将会丢失
由于需要经常fork子线程来进行备份操作，如果数据量很大的话，fork比较耗时，如果cpu性能不够，服务器可能是卡顿。属于数据量大的时候，一个服务器不要部署多个Redis服务。

AOF：

优点

使用AOF模式更加的灵活，因为可以有不同的fsync策略

AOF是一个日志追加文件，所有不需要定位，就算断电也没有损坏问题，哪怕文件末尾是一个写到一半的命令，redus-check-aof工具也可以很轻易的修复
当AOF文件很大时，Redis会自动在后台进行重写。重写是决对安全的，因为Redis是继续往旧的文件里面追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦创建完成，Redis就会切换到新文件，开始往新文件进行追加操作
AOF包含一个又一个的操作命令，易于理解和解析

缺点

对于同样的数据集，AOF文件通常要大于RDB文件
AOF可能比RDB要慢，这取决于fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭sfync，即使在很高的负载下也和RDB一样快。不过，即使在很大的写负载情况下，RDB还是能提供很好的最大延迟保证
AOF通过递增的方式更新数据，而RDB快照是从头开始创建，RDB会更健壮和稳定（所以适用于备份）