redis学习笔记（5）：redis集群

目前到家业务规模，还没有使用redis集群。因为整理相关知识，补充此篇。没有亲自动手搭建集群进行测试，命令参考网上帖子。

4.1Twemproxy

Twemproxy是一个Twitter开源的一个Redis/Memcache代理服务器，使用方法和普通redis无任何区别，设置好它下属的多个redis实例后，使用时在本需要连接redis的地方改为连接twemproxy，它会以一个代理的身份接收请求 并使用一致性hash算法，将请求转接到具体redis，将结果再返回twemproxy。图不贴出来了。网上比较多，应该是早期的过渡方案。

缺点：

Twemproxy并不支持数据转移。就是说redis节点数量改变时候的 计算值的改变，数据无法自动移动到新的节点。

Twemproxy并不是目前执行速度最快的Redis Proxy产品。codis可以替代。

结构层级多，运维压力大，貌似不更新使用不多了。

4.2 官方3.0之后：redis-cluster

集群元数据信息分布在每个节点上，主备切换依赖于多个节点协商选主。redis 提供了redis-trib 工具做部署集群及运维等操作。

其结构特点：

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

     5、Redis集群预分好16384个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384的值，决定将一个key放到哪个桶中。

 4.2.1、redis cluster节点分配

    现在我们是三个主节点分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以是三台不同的服务器。那么，采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：

      节点A覆盖0－5460;      节点B覆盖5461－10922;      节点C覆盖10923－16383.    

     获取数据：

      如果存入一个值，按照redis cluster哈希槽的算法： CRC16('key')384 = 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

     同样删除一个节点也是类似，移动完成后就可以删除这个节点了。

4.2.2 Redis集群的主从复制：

为了使得集群在一部分节点下线或者无法与集群的大多数（majority）节点进行通讯的情况下， 仍然可以正常运作， Redis 集群对节点使用了主从复制功能： 集群中的每个节点都有 1 个至 N 个复制品（replica）， 其中一个复制品为主节点（master）， 而其余的 N-1 个复制品为从节点（slave）。

在之前列举的节点 A 、B 、C 的例子中， 如果节点 B 下线了， 那么集群将无法正常运行， 因为集群找不到节点来处理 5501 号至 11000号的哈希槽。

另一方面，假如在创建集群的时候（或者至少在节点 B 下线之前）， 我们为主节点 B 添加了从节点 B1 ， 那么当主节点 B 下线的时候， 集群就会将 B1 设置为新的主节点， 并让它代替下线的主节点 B ， 继续处理 5501 号至 11000 号的哈希槽， 这样集群就不会因为主节点 B 的下线而无法正常运作了。不过如果节点 B 和 B1 都下线的话， Redis 集群还是会停止运作。

4.3 主从模式搭建：

通常推荐3主3从的6个节点。

通过使用 Redis 集群命令行工具 redis-trib ， 编写节点配置文件的工作可以非常容易地完成： redis-trib 位于 Redis 源码的 src 文件夹中， 它是一个 Ruby 程序， 这个程序通过向实例发送特殊命令来完成创建新集群， 检查集群， 或者对集群进行重新分片（reshared）等工作。

安装ruby相关的程序：

1.yum install ruby
 2.yum install rubygems  
 3.gem install redis --version 3.0.0

1. ./redis-trib.rb create --replicas 1 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006  

以上命令中，create参数代表创建一个新的新的Redis Cluster，然后我们后给出了一个replicas参数，这个参数代表集群中的每一个Master节点对应多少个Slave节点，这里给出的数值是1，就代表每一个Master节点会对应一个Slave节点。需要注意， 这里并不需要明确指定哪些节点将成为Master节点，哪些节点将成为Slave节点，而redis-trib会参考replicas参数的值自行计算得出 。在命令的最后我们还给出了参与这个新的Redis Cluster的所有Redis节点的信息。

这里待补充搭建后测试命令吧。

4.3 自己维护sharding:

Redis Sharding集群是官方集群出现之前3.0常见的解决办法。实现原理是采用哈希函数对key进行散列，特定的key会映射到特定的节点。这样客户端就知道操作那个客户端操作。

特点如下：

1. 客户端实现
2. 各个Redis节点独立，之间无关系
3. 某个Redis节点挂了，整个集群不可用，所以需要对每个节点做主从备份
4. 主从备份方案一般通过读写分离设置，每个master至少两个slaver，只有这样master挂掉后，才能选举其中一个Slaver成为新的master，原来master节点加入集群后成为新master的slaver节点
5. redis主从切换对客户端jedis使用时透明的，即redis发生了主从切换并不影响jedis的使用

缺点：

1. 节点扩展和收缩不友好

参考：http://blog.csdn.net/yinwenjie/article/details/53905637

https://www.cnblogs.com/yingchen/p/6763524.html