面试问Redis集群，被虐的不行了 _Redis集群

【51CTO.com原创稿件】上一篇我们讲解了 redis 哨兵的工作原理，哨兵主要针对单节点故障无法自动恢复的解决方案，集群主要针对单节点容量、并发问题、线性可扩展性的解决方案。

文章插图
图片来自 Pexels
本篇我将讲解 Redis 集群的工作原理，文末有你们想要的设置 SSH 背景哦!
本文主要围绕如下几个方面介绍集群：

集群简介
集群作用
配置集群
手动、自动故障转移
故障转移原理

本文实现环境：

centos 7.3
Redis 4.0
Redis 工作目录 /usr/local/redis
所有操作均在虚拟机模拟进行

集群简介
集群是为了解决主从复制中单机内存上限和并发问题，假如你现在的云服务内存为 256GB，当达到这个内存时 Redis 就没办法再提供服务。
同时数据量能达到这个地步写数据量也会很大，容易造成缓冲区溢出，造成从节点无限的进行全量复制导致主从无法正常工作。

文章插图

那么我们就需要把单机的主从改为多对多的方式，并且所有的主节点都会连接在一起互相通信。
这样的方式既可以分担单机内存，也可以分发请求，提高系统的可用性。
如下图：当有大量请求写入时，不再会单一的向一个主节点发送指令，而会把指令进行分流到各个主节点，达到分担内存、避免大量请求的作用。

文章插图

那么指令是如何进行分流存储的呢?我们就需要到集群存储结构中一探究竟。
集群作用
集群的作用有如下几个：

分散单机的存储能力，同时也可以很方便的实现扩展。
分流单机的访问请求。
提高系统的可用性。

如何理解提高系统的可用性这句话，我们看下图，当 master1 宕机后对系统的影响不会那么大，仍然可以提供正常的服务。

文章插图

这个时候就会有人问了，当 master1 宕机后，集群这个时候怎么工作呀?这个问题会在下文的故障转移来给你解答，并且在原理篇会对这个问题进行详解。
集群存储结构
存储结构
单机的存储是当用户发起请求后直接把 key 存储到自己的内存即可。

文章插图

集群的存储结构就没有那么简单了，首先当用户发起一个 key 指令后需要做的事情如下：

通过 CRC16(key) 会计算出来一个值。
用这个值取模 16384，会得到一个值，我们就先认为是 28 。
这个值 28 就是 key 保存的空间位置。

那么现在问题来了，这个 key 到底应该存储在哪个 Redis 存储空间里边呢?

文章插图

其实 Redis 在集群启动后就已经把存储空间划分了 16384 份，每台主机保存一部分。
这里需要注意的是我给每个 Redis 存储空间里边的编号就相当于一个小的存储空间(专业术语“哈希槽”) 。
你可以理解为一栋楼里边的编号，一栋楼就是 Redis 的整个存储空间，每个房子的编号就相当于一个存储空间，这个存储空间会有一定的区域来保存对应的 key，并非上图取模后的位置。
箭头指向的 28 是指的 28 会存储在这个区域里，这个房子有可能会存储 29、30、31 等。

文章插图

此时问题来了，如果新增、减少一台机器后怎么办呢?看图说话，能用图说明尽量不去用文字。
在新增一台机器后，会从其他三个存储空间中拿出一定的槽分配给新的机器。这里可以自己设置想给新的机器放多少个槽。
同样减少一台机器后会把去掉的槽在重新分配给其它现有的机器跟新增节点一样，可以指定节点接收槽。
所谓的增节点或去节点就是改变槽所存储的位置不同。