linux搭建redis集群

redis用什么做集群？
　　用一个叫redis-trib.rb的ruby脚本。redis-trib.rb是redis官方推出的管理redis集群的工具，集成在redis的源码src目录下。是基于redis提供的集群命令封装成简单、便捷、实用的操作工具。redis-trib.rb是redis作者用ruby完成的。所以redis集群需要先安装ruby环境。
1、手动通过源码编译安装ruby
（1）下载：执行wget https://cache.ruby-lang.org/pub/ruby/2.2/ruby-2.2.2.tar.gz
（2）解压：tar xf ruby-2.2.2.tar.gz
(3）配置并制定安装位置：./configure
(4) 编译与安装：make && make install
默认情况下，Ruby 安装到 /usr/local 目录。如果想使用其他目录，可以把 --prefix=DIR 选项传给 ./configure 脚本。即：./configure --PREFIX=/usr/local/xxx
(5）查看ruby版本：ruby -v 如果显示有数据说明成功了
2、安装gem redis
yum install rubygems
gem install redis

可以参考官方文档：https://www.ruby-lang.org/zh_cn/downloads/
3、集群搭建
（1）搭建一个redis服务器
（2）复制6个redis-XXX.conf 来完成一个3主3从的 redis集群
修改每一个配置文件的以下数据：
修改端口号：port XXX
后台启动：daemonize yes
开启集群：cluster-enabled yes
指定集群节点为当前配置文件的conf文件：cluster-config-file nodes-6379.conf
超时时间：cluster-node-timeout 5000
（3）分别启动6个redis
./redis-server 路径/redis-XXX.conf
./redis-server 路径/redis-XXX.conf
。。。。
（4）查看redis启动情况
（5）建立集群
./redis-trib.rb create --replicas 1 127.0.0.1:6349 127.0.0.1:6359 127.0.0.1:6369 127.0.0.1:6379 127.0.0.1:6389 127.0.0.1:6399

（5）访问某个集群
redis-cli -h IP地址 -p 端口号 –c
说明：-h+host –p+端口号 –c 是要连接集群

关于 Redis 集群

4、redis 集群在启动的时候就自动在多个节点间分好片。同时提供了分片之间的可用性：当一部分 redis 节点故障或网络中断，集群也能继续工作。但是，当大面积的节点故障或网络中断（比如大部分的主节点都不可用了），集群就不能使用（节点之间存在着投票的制度，这就是Redis集群为什么至少需要三个节点的缘故）。
所以，从实用性的角度，Redis 集群提供以下功能：
1）、自动把数据切分到多个 redis 节点中 ；
2）、当少部分节点挂了或不通，集群依然能继续工作；

5、redis 的主从模式
为了保证在部分节点故障或网络不通时集群依然能正常工作，集群使用了主从模型，每个哈希槽有一（主节点）到N个副本（N-1个从节点）。在我们刚才的 Redis 集群搭建教程，使用了三个节点，如果节点 01 故障集群就不能正常工作了，因为节点 02 中的哈希槽数据没法操作。但是，如果我们给每一个节点都增加一个从节点，就变成了：（01、02、03）这三个节点是主节点，04、05、06 分别为 01、02、03 的从节点，当其中某个节点挂掉时，集群依然能够正常运作。例如：04 节点是 01 节点的从节点，如果 01 节点故障，集群会将 04 从节点升级为主节点，从而让集群继续正常工作。但是，如果 01 和 04 同时挂掉，那么这个 Redis 集群就不能继续正常运作了。
Redis 集群的一致性保证 ：
Redis 集群不能保证一致性。比如一个已经向客户端确认写成功的操作，可能会在某些不确定因素的条件下导致操作数据丢失。
造成写操作数据丢失的原因：是因为主从节点之间通过异步的方式来同步数据。
向 Redis 集群一个写的动作流程：
1）客户端向主节点 01 发起写的操作 2)主节点 01 响应客户端写操作成功 3)主节点 01 向它的从节点 04 同步该写的动作。从上面写的流程来看，主节点 01 并没有等从节点 04 写完之后再回复客户端的写操作结果。而是先响应客户端后再将写的动作同步到从节点 04，所以，如果主节点 01 在通知客户端写操作成功之后，但同步给从节点 04 之前，主节点 01 挂了，未将写操作结果同步到从节点，那么当 04 从节点提为主节点时，该写操作就会永远丢失。 就像传统的数据库，在不涉及到分布式的情况下，它每隔一秒向磁盘写一次。为了提高一致性，在写磁盘完成之后再响应客户端，但这样就极大的降低了系统性能。这种写磁盘的方式就等于 Redis 集群中主节点向从节点同步写操作的过程。 所以在性能和一致性之间，需要择其一，鱼和熊掌不能兼得！

6、关于 Redis 集群数据分片
Redis 集群不是使用一致性哈希，而是使用哈希槽。整个 redis 集群有 16384 个哈希槽，决定一个 key 应该分配到那个槽的算法是：计算该 key 的 CRC16 结果再模 16384。
集群中的每个节点负责一部分哈希槽，例如上例中集群有 3 个节点，则：
1）、节点 01 存储的哈希槽范围是：0 ~ 5460
2）、节点 02 存储的哈希槽范围是：5461 ~10922
3）、节点 03 存储的哈希槽范围是：10923~16383
这样的分布方式方便节点的添加和删除。比如，需要新增一个节点 07，只需要把 01、02、03 中的部分哈希槽数据移到 07 节点。同样，如果希望在集群中删除01节点，只需要把 01 节点的哈希槽的数据移到 02 和 03 节点，当 01 节点的数据全部被移走后，01 节点就可以完全从集群中删除。
因为把哈希槽从一个节点移到另一个节点是不需要停机的，所以，增加或删除节点，或更改节点上的哈希槽，都是不需要停机的。
如果多个key都属于一个哈希槽，集群支持通过一个命令、事务或lua脚本同时操作这些key。通过“哈希标签”的概念，用户可以让多个key分配到同一个哈希槽。
哈希标签Redis中国官网（Redis china）的集群文档中有详细的描述，在这里只做个简单介绍：如果key含有大括号”{}”,则只有大括号中的字符串会参与哈希，比如”manager{util}”和”company{util}”这两个key会分配到同一个哈希槽，所以可以在一个命令、事务或lua脚本中同时操作他们。

这段描述表示了redis的集群是如何工作的，通过将节点进行划分不同的hash槽来实现数据的存储，每次当进行set值的时候，redis集群会对键进行crc16的算法校验，然后再取模，这样可以保证键可以落在16384范围中的某一个点上。然后再取不同的范围，定位到具体的节点上，这种结构的伸缩兴比较好，会避免删除或者增加节点的时候导致集群不可用。