深刻浅出—Redis集群的相关详解

前言：

这篇文章主要介绍了Redis集群的相关，文中经过示例代码介绍的很是详细，对你们的学习或者工做具备必定的参考学习价值。

注意！要求使用的都是redis3.0以上的版本，由于3.0以上增长了redis集群的功能。

1.redis介绍

1.1什么是redis

Redis是用C语言开发的一个开源的高性能键值对(key-value)的非关系型数据库。经过多种键值数据类型来适应不一样场景下的存储需求，目前支持的键值数据类型有：
字符串，散列，列表，集合，有序集合

2.2应用场景

缓存（数据查询、短链接、新闻内容、商品内容等等）。（最多使用）
分布式集群架构中的session分离。
聊天室的在线好友列表。
任务队列。（秒杀、抢购、12306等等）
应用排行榜。
网站访问统计。
数据过时处理（能够精确到毫秒）

2.Redis集群的介绍

2.1Redis集群的架构

 

 

Redis 集群中内置了 16384 个哈希槽，redis-cluster把全部的物理节点映射到[0-16383]slot上,cluster 负责维护。当须要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，而后把结果对 16384 求余数，这样每一个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大体均等的将哈希槽映射到不一样的节点

2.2 Redis集群的特色

当Redis集群启动后，就自动在多个节点间作好分片，同时提供了分片之间的可用性：即当一部分redis节点故障或者网络中断后，集群还有从节点能够替代主节点继续工做，但若是大面积的节点故障，那集群就不可用了。

Redis集群提供了：
自动将16384个数据槽点切分到多个Redis节点中
当一部分节点故障或不可达，集群依然能继续工做

2.3 Redis集群的TCP端口

集群的每一个节点都须要创建两个TCP链接，监听这两个端口：
客户端端口（通常是6379）：须要对全部客户端和集群节点开放，用于接收客户端指令，且集群节点须要经过该端口向客户端转移数据。

集群总线端口（通常是6379+10000）：只须要对集群中的全部节点开放，用于节点之间经过二进制协议通讯。各节点经过集群总线检测故障节点，更新配置等，而客户端是不能使用该端口的。

2.4 Redis集群数据的分片

Redis集群使用的是哈希槽，有16384个哈希槽，决定一个key分配到哪一个槽的算法：计算该key的CRC16,结果再模16384.
集群中的每一个节点负责一部分哈希槽，好比集群中有３个节点，则：

• 节点Ａ存储的哈希槽范围是：0 – 5500
• 节点Ｂ存储的哈希槽范围是：5501 – 11000
• 节点Ｃ存储的哈希槽范围是：11001 – 16384

这样的分布方式方便节点的添加和删除。好比，须要新增一个节点Ｄ，只须要把Ａ、Ｂ、Ｃ中的部分哈希槽数据移到Ｄ节点。一样，若是但愿在集群中删除Ａ节点，只须要把Ａ节点的哈希槽的数据移到Ｂ和Ｃ节点，当Ａ节点的数据所有被移走后，Ａ节点就能够彻底从集群中删除。

由于把哈希槽从一个节点移到另外一个节点是不须要停机的，因此，增长或删除节点，或更改节点上的哈希槽，也是不须要停机的。

若是多个key都属于一个哈希槽，集群支持经过一个命令（或事务, 或lua脚本）同时操做这些key。经过“哈希标签”的概念，用户可让多个key分配到同一个哈希槽。若是key含有大括号”{}”,则只有大括号中的字符串会参与哈希，好比”this{foo}”和”another{foo}”这２个key会分配到同一个哈希槽，因此能够在一个命令中同时操做他们。

2.5 Redis集群的主从模式

每一个哈希槽都有一个主节点和多个从节点。
举例：若是有六个节点，则分A,B,C三个为主节点，A1,B1,C1三个为对应的从节点，当A发生故障后，集群会提高A1为主节点，A1会继承A节点的数据，其实A1就至关于A的一个副本，让集群继续工做。

2.5.1 redis-cluster投票:容错

 

 

(1)投票过程是集群中全部主节点参与,若是半数以上主节点与故障主节点通讯超过(cluster-node-timeout),认为当前该主节点挂掉.
(2):何时整个集群不可用(cluster_state:fail)?
a:若是集群任意主节点挂掉,且没有从节点.集群进入fail状态,也能够理解成集群的slot映射[0-16383]不完成时进入fail状态.
b:若是集群超过半数以上主节点挂掉，不管是否有从节点，集群都进入fail状态.
ps:当集群不可用时,全部对集群的操做作都不可用，收到((error) CLUSTERDOWN The cluster is down)错误。

2.6 Redis集群的一致性保证

Redis集群不能保证强一致性。一些已经向客户端确认写成功的操做，会在某些不肯定的状况下丢失。
产生写操做丢失的第一个缘由，是由于主从节点之间使用了异步的方式来同步数据。
一个写操做是这样一个流程：

• 1)客户端向主节点B发起写的操做
• 2)主节点B回应客户端写操做成功
• 3)主节点B向它的从节点B1,B2,B3同步该写操做

从上面的流程能够看出来，主节点B并无等从节点B1,B2,B3写完以后再回复客户端此次操做的结果。因此，若是主节点B在通知客户端写操做成功以后，但同步给从节点以前，主节点Ｂ故障了，其中一个没有收到该写操做的从节点会晋升成主节点，该写操做就这样永远丢失了。

节点超时（node timeout）：对集群来讲很是重要，当达到了这个节点超时的时间以后，主节点被认为已经宕机，能够用它的一个从节点来代替。一样，在节点超时时，若是主节点依然不能联系到其余主节点，它将进入错误状态，再也不接受写操做。

2.7 Redis集群的参数配置

在redis.conf中的一些参数说明：

cluster-enabled <yes/no>:
若是配置”yes”则开启集群功能，此redis实例做为集群的一个节点，不然，它是一个普通的单一的redis实例。

cluster-config-file :
注意：虽然此配置的名字叫“集群配置文件”，可是此配置文件不能人工编辑，它是集群节点自动维护的文件，主要用于记录集群中有哪些节点、他们的状态以及一些持久化参数等，方便在重启时恢复这些状态。一般是在收到请求以后这个文件就会被更新。

cluster-node-timeout :
这是集群中的节点可以失联的最大时间，超过这个时间，该节点就会被认为故障。若是主节点超过这个时间仍是不可达，则用它的从节点将启动故障迁移，升级成主节点。注意，任何一个节点在这个时间以内若是仍是没有连上大部分的主节点，则此节点将中止接收任何请求。

cluster-slave-validity-factor :
若是设置成０，则不管从节点与主节点失联多久，从节点都会尝试升级成主节点。若是设置成正数，则cluster-node-timeout乘以cluster-slave-validity-factor获得的时间，是从节点与主节点失联后，此从节点数据有效的最长时间，超过这个时间，从节点不会启动故障迁移。假设cluster-node-timeout=5，cluster-slave-validity-factor=10，则若是从节点跟主节点失联超过50秒，此从节点不能成为主节点。注意，若是此参数配置为非0，将可能出现因为某主节点失联却没有从节点能顶上的状况，从而致使集群不能正常工做，在这种状况下，只有等到原来的主节点从新回归到集群，集群才恢复运做。

cluster-migration-barrier
:主节点须要的最小从节点数，只有达到这个数，主节点失败时，它从节点才会进行迁移。更详细介绍能够看本教程后面关于副本迁移到部分。

cluster-require-full-coverage
<yes/no>:在部分key所在的节点不可用时，若是此参数设置为”yes”(默认值),
则整个集群中止接受操做；若是此参数设置为”no”，则集群依然为可达节点上的key提供读操做。

以上所述是小编给你们介绍的Redis集群的相关详解整合，但愿对你们有所帮助，