redis(10)-集群

redis集群
Redis Cluster是Redis的分布式解决方案， 在3.0版本正式推出， 有效地解决了Redis分布式方面的需求。 当遇到单机内存、 并发、 流量等瓶颈时， 可以采用Cluster架构方案达到负载均衡的目的。
Redis Cluster， 它非常优雅地解决了Redis集群方面的问题， 因此理解应用好Redis Cluster将极大地解放我们使用分布式Redis的工作量， 同时它也是学习分布式存储的绝佳案例。
数据分布
分布式数据库首先要解决把整个数据集按照分区规则映射到多个节点的问题， 即把数据集划分到多个节点上， 每个节点负责整体数据的一个子集。

1.节点取余分区
使用特定的数据， 如Redis的键或用户ID， 再根据节点数量N使用公式：hash（key） %N计算出哈希值， 用来决定数据映射到哪一个节点上。 这种方案存在一个问题： 当节点数量变化时， 如扩容或收缩节点， 数据节点映射关系需要重新计算， 会导致数据的重新迁移。

2.一致性哈希分区
一致性哈希分区（Distributed Hash Table） 实现思路是为系统中每个节点分配一个token， 范围一般在0~232， 这些token构成一个哈希环。 数据读写执行节点查找操作时， 先根据key计算hash值， 然后顺时针找到第一个大于等于该哈希值的token节点。
这种方式相比节点取余最大的好处在于加入和删除节点只影响哈希环中相邻的节点， 对其他节点无影响。 但一致性哈希分区存在几个问题：

·当使用少量节点时， 节点变化将大范围影响哈希环中数据映射， 因此这种方式不适合少量数据节点的分布式方案。
·普通的一致性哈希分区在增减节点时需要增加一倍或减去一半节点才能保证数据和负载的均衡。

3.虚拟槽分区
虚拟槽分区巧妙地使用了哈希空间， 使用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合中， 整数定义为槽（slot） 。 这个范围一般远远大于节点数， 比如Redis Cluster槽范围是0~16383。 槽是集群内数据管理和迁移的基本单位。 采用大范围槽的主要目的是为了方便数据拆分和集群扩展。

如图0~16383的槽平均分配给5个节点

Redis虚拟槽分区的特点：
·解耦数据和节点之间的关系， 简化了节点扩容和收缩难度。
·节点自身维护槽的映射关系， 不需要客户端或者代理服务维护槽分区元数据。
·支持节点、 槽、 键之间的映射查询， 用于数据路由、 在线伸缩等场景。

集群功能限制
由于节点并不能存到同一个节点，所以大量的批量操作不能再集群上面使用，pipline，mget，事务等。
1） key批量操作支持有限。 如mset、 mget， 目前只支持具有相同slot值的key执行批量操作。 对于映射为不同slot值的key由于执行mget、 mget等操作可能存在于多个节点上因此不被支持。
2） key事务操作支持有限。 同理只支持多key在同一节点上的事务操作， 当多个key分布在不同的节点上时无法使用事务功能。
3） key作为数据分区的最小粒度， 因此不能将一个大的键值对象如hash、 list等映射到不同的节点。
4） 不支持多数据库空间。 单机下的Redis可以支持16个数据库， 集群模式下只能使用一个数据库空间， 即db0。
5） 复制结构只支持一层， 从节点只能复制主节点， 不支持嵌套树状复制结构。

搭建集群
搭建集群工作需要以下三个步骤：
1） 准备节点。
2） 节点握手。
3） 分配槽。

1 准备节点
Redis集群一般由多个节点组成， 节点数量至少为6个才能保证组成完整高可用的集群。 每个节点需要开启配置cluster-enabled yes， 让Redis运行在集群模式下。 建议为集群内所有节点统一目录， 一般划分三个目录： conf、data、 log， 分别存放配置、 数据和日志相关文件。 把6个节点配置统一放在conf目录下， 集群相关配置如下：

#节点端口
port 6379
#开启集群模式
cluster-enabled yes
#节点超时时间， 单位毫秒
cluster-node-timeout 15000
#集群内部配置文件
cluster-config-file “nodes-6379.conf”

其他配置和单机模式一致即可， 配置文件命名规则redis-{port}.conf， 准备好配置后启动所有节点。

检查节点日志是否正确
cat log/redis-6379.log
*No cluster configuration found, I’m cfb28ef1deee4e0fa78da86abe5d24566744411e
#Server started, Redis version 3.0.7
*The server is now ready to accept connections on port 6379

第一次启动时如果没有集群配置文件， 它会自动创建一份， 文件名称采用cluster-config-file参数项控制， 建议采用node-{port}.conf格式定义， 通过使用端口号区分不同节点， 防止同一机器下多个节点彼此覆盖， 造成集群信息异常。 如果启动时存在集群配置文件， 节点会使用配置文件内容初始化集群信息。

集群模式的Redis除了原有的配置文件之外又加了一份集群配置文件。当集群内节点信息发生变化， 如添加节点、 节点下线、 故障转移等。 节点会自动保存集群状态到配置文件中。 需要注意的是， Redis自动维护集群配置文件， 不要手动修改， 防止节点重启时产生集群信息错乱。

如节点6379首次启动后生成集群配置如下：
#cat data/nodes-6379.conf
cfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 0 connected
vars currentEpoch 0 lastVoteEpoch 0

文件内容记录了集群初始状态， 这里最重要的是节点ID， 它是一个40位16进制字符串， 用于唯一标识集群内一个节点， 之后很多集群操作都要借助于节点ID来完成。 需要注意是， 节点ID不同于运行ID。 节点ID在集群初始化时只创建一次， 节点重启时会加载集群配置文件进行重用， 而Redis的运行I