本文主要围绕如下几个方面介绍集群
- 集群简介
- 集群作用
- 配置集群
- 手动、自动故障转移
- 故障转移原理
本文实现环境
- centos 7.3
- redis 4.0
- redis工作目录 /usr/local/redis
- 所有操作均在虚拟机模拟进行
Redis集群
本文主要围绕如下几个方面介绍集群
本文实现环境
一、集群简介
二、集群作用
三、集群存储结构
1. 存储结构
2. 通讯设计
四、配置集群
1. 修改配置文件
2. 构建6个节点的配置文件并全启动
3. 安装ruby
4. 启动集群
5. 集群设置与获取数据
五、故障转移
1. 集群从节点下线
2. 集群主节点下线
3. 新增主节点
4. 手动故障迁移
六、故障转移原理篇
1. 故障发现到确认
2. 故障恢复（从节点从此翻身奴隶把歌唱）
你们想要的ssh的背景！！！
一、集群简介
集群是为了解决主从复制中单机内存上限和并发问题，假如你现在的云服务内存为256GB，当达到这个内存时redis就没办法再提供服务，同时数据量能达到这个地步写数据量也会很大，容易造成缓冲区溢出，造成从节点无限的进行全量复制导致主从无法正常工作。
那么我们就需要把单机的主从改为多对多的方式并且所有的主节点都会连接在一起互相通信。这样的方式既可以分担单机内存，也可以分发请求，提高系统的可用性。
如图：当有大量请求写入时，不再会单一的向一个主节点发送指令，而会把指令进行分流到各个主节点，达到分担内存、避免大量请求的作用。
那么指令是如何进行分流存储的呢！我们就需要到集群存储结构中一探究竟。
二、集群作用
- 分散单机的存储能力，同时也可以很方便的实现扩展。
- 分流单机的访问请求
- 提高系统的可用性
如何理解提高系统的可用性这句话，我们看下图，当master1宕机后对系统的影响不会那么大，仍然可以提供正常的服务。
这个时候就会有人问了，当master1宕机后集群这个时候怎么工作呀！这个问题会在下文的故障转移来给你解答。并且在原理篇会对这个问题进行详解
三、集群存储结构
1. 存储结构
单机的存储是当用户发起请求后直接把key存储到自己的内存即可。
集群的存储结构就没有那么简单了，首先当用户发起一个key指令后需要做的事情。
- 通过CRC16(key)会计算出来一个值
- 用这个值取模16384，会得到一个值，我们就先认为是28
- 这个值28就是key保存的空间位置
那么现在问题来了，这个key到底应该存储在那个redis存储空间里边呢！
其实redis在集群启动后就已经把存储空间划分了16384份，每台主机保存一部分。
这里需要注意的是我给每个redis存储空间里边的编号就相当于一个小的存储空间（专业术语“哈希槽”），你可以理解为一栋楼里边的编号，一栋楼就是redis的整个存储空间，每个房子的编号就相当于一个存储空间，这个存储空间会有一定的区域来保存对应的key，并非上图取模后的位置。
箭头指向的28是指的28会存储在这个区域里，这个房子有可能会存储29、30、31等。
此时问题来了，如果新增、减少一台机器后怎么办呢！看图说话，能用图说明尽量不去用文字。
在新增一台机器后，会从其他三个存储空间中拿出一定的槽分配给新的机器。这里可以自己设置想给新的机器放多少个槽。
同样减少一台机器后会把去掉的槽在重新分配给其它现有的机器跟新增节点一样，可以指定节点接收槽。
所谓的增节点或去节点就是改变槽所存储的位置不同。
了解了集群的存储结构后，我们就需要在对另一个问题进行说明了，集群是如何设计内部通讯呢！来了一个值，获取一个key，去哪拿数据，跟着这个问题我们看下文。
2. 通讯设计
集群中的每个节点会在一定的时期给其它节点发送ping消息，其它节点返回pong作为响应。经过一段时间后所有节点都会知道集群全部节点的槽信息。
如下图有三个节点，那么就会把16384个哈希槽分成三份。
分别为0-5500、5501-11000、11001-16384
当用户发起了一个key的请求，集群是如何处理请求的呢！
下图的黑框代表这集群所有节点的槽信息，里边还有很多其它信息。
如图所示，用户发起请求key，redis接收后计算key的槽位置，在根据槽位置找出对应的节点
如果访问的槽就在节点本身，那么就会直接返回key对应数据。
否则会回复moved重定向错误， 并且给客户端返回正确的节点。
然后重发key指令
四、配置集群
1. 修改配置文件
只需要注意咔咔圈中的配置信息即可
- cluster-enabled yes：开启集群模式
- cluster-config-file nodes-6379.conf：集群配置文件
- clustre-node-timeout 10000：节点超时时间，这里为了方便测试设置为10s
2. 构建6个节点的配置文件并全启动
咔咔给大家提供一个命令可以很方便的替换文件sed 's/6379/6380/g' 6379-redis.conf > 6380-redis.conf
按照这样的方式创建出来6个不同端口的配置文件
随便打开一个配置文件查看，检测是否替换成功
为了查看日志信息方便，全部使用前台启动。并且查看服务是否都正常启动，执行命令ps -ef | grep redis
可以看到启动后多了个cluster标识，代表着都是集群的一个节点。
所有节点启动完成，集群启动的指令需要基于ruby（咔咔使用redis版本为4.0）。接下来一起安装
3. 安装ruby
执行命令wget https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.1.tar.gz
解压：tar -xvzf ruby-2.7.1.tar.gz 根据自己下载的版本来解压
安装：./configure | make | make install这三个指令一气呵成。
查看ruby和gem版本：ruby -v
4. 启动集群
集群的执行命令在/usr/local/redis/src/redis-trib.rb
注意如果需要直接使用redis-trib.rb命令，需要ln到bin目录下，否则就必须使用./redis-trib.rb的方式。
如果按照步骤走，这里会出现一个错误
执行gem install redis很不幸的是在这里也会出现错误。
随后需要安装yum install zlib-devel和yum install openssl-devel
安装完成后，在/ruby-2.7.1/ext/openssl 和 /ruby-2.7.1/ext/zlib 分别执行ruby extconf.rb并且执行make | make install
然后在执行gem install redis就OK
这时在回头来执行./redis-trib.rb create --replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384
信息解读
创建集群，并且给6个节点分配哈希槽，后三个节点配置为前三个节点的从节点
显示每个节点的哈希槽信息和节点ID，最后一步需要输入yes
来到data目录下查看配置文件的变化。配置文件主要信息是每个主节点分的槽
查看主机点的运行日志
这里给的主要信息cluster status changed:ok 集群状态正常
5. 集群设置与获取数据
当直接设置数据会报错，并且把name这个key进行转化后的槽位置为5798 并且给出了ip地址和端口号。
需要使用命令redis-cli -c
在进行设置值的时候提示说重定向到5798的这个槽
接下来进行获取数据，会自动的切换节点。
