标签：fail   性能   conf   日志   failover   一致性   为什么   标示   add   

1. Redis的cluster集群

在官方文档Cluster Spec中，作者详细介绍了Redis集群为什么要设计成现在的样子。最核心的目标有三个：

• 性能：这是Redis赖以生存的看家本领，增加集群功能后当然不能对性能产生太大影响，所以Redis采取了P2P而非Proxy方式、异步复制、客户端重定向等设计，而牺牲了部分的一致性、使用性。
• 可用性：在Cluster推出之前，可用性要靠Sentinel保证。有了集群之后也自动具有了Sentinel的监控和自动Failover能力。
• 水平扩展：集群的最重要能力当然是扩展，文档中称可以线性扩展到1000结点。

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理论要求的，三者只能取其二。

2. 配置选项以及启动

设置３个节点，将enable-cluster 设置为yes, 修改cluster-config-file nodes-6379.conf，将其设置为不同的文件即可，无需此nodes文件存在。 
修改redis.conf配置文件的内容：

cluster-enabled yes 
cluster-config-file nodes-6379.conf

其中node-6739.conf并不要求真实存在，只要不同的redis实例不相同即可。 
然后分别启动各个redis的实例，然后查看进程: 

从图中可以发现，其中的进程后面都带有cluster的字样，标示其为cluster集群状态。 
这里启动了３个实例: 6379, 6380, 6381.

3. 设置集群节点

　这里一般需要基于redis-cli进入命令行参数，然后输入cluster meet的命令，进行cluster的注册： 
　

这里我们从6379这个实例登陆，分别注册6380, 6381两个节点。注册完成后，然后查看集群信息，可以发现其整个集群的信息为３个节点。

4. 创建shell脚本，初始化slots

创建初始化slot的脚本：

> 
#!/bin/bash 
for i in {1..16383}; do ./src/redis-cli cluster addslots $i; done

在脚本里面总共添加１６３８３个slot。　 
修改该脚本的执行权限，执行之，即可获取相应的结果信息。

5. 查看slots的内容

cluster slots : 查看slots信息 
cluster nodes: 查看节点信息

从上面可以整个集群的基本状况。

6. 基于普通模式操作集群／集群模式

基于命令行来查看信息的设置：

redis-cli -p 6739 
redis-cli -c -p 6739 

从这里可以看懂，在cluster模式下与普通模式下的不同，集群模式下客户端可以自动的切换到其他节点。 
正常情况下的客户端执行逻辑如下： 

7. 安装ruby以及gem的redis组件

各个操作系统的不同，安装方案各有差异，这里以ubuntu的方式来进行。 

8. 进行集群的reshard

src/redis-trib.rb reshard 127.0.0.1:6739

从源节点移动到目标节点 
? ./redis-trib.rb reshard 127.0.0.1:6379 
? How many slots do you want to move (from 1 to 16384)? 4000 //输入被迁移的solt的数量 
? What is the receiving node ID? //输入目的地节点的id,执行第一行命 
? Please enter all the source node IDs.//输入被迁移的槽 
? Do you want to proceed with the proposed reshard plan (yes/no)? Yes //迁移计划确认

如何来确认reshard来进行呢？查看命令的日志即可得知： 

9. 总结

redis提供了完整的一套如何进行集群处理的机制，并利用一致性hash来更好的处理redis的动态调整。

http://www.woaipu.com/shops/zuzhuan/61406
http://nanning.xjwy.cn/f/bencandy.php?fid=43&id=117777
http://nanning.xjwy.cn/f/bencandy.php?fid=43&id=117890
http://nanning.xjwy.cn/f/bencandy.php?fid=43&id=117994
http://nanning.xjwy.cn/f/bencandy.php?fid=43&id=118376

Redis的集群安装以及rehash重新迁移教程指南

标签：fail   性能   conf   日志   failover   一致性   为什么   标示   add   

原文地址：http://www.cnblogs.com/sy646et/p/7203435.html