Redis集群介绍

@Redis集群介绍、故障快速恢复、常见问题解决

Redis集群介绍

多个Redis节点间共享数据。

一、方案

1、Twitter开发的twemproxy

1、简介

twemproxy架构简单，就是用proxy对后端redis server进行代理，但是由于代理层的消耗性能很低，而且通常涉及多个key的操作都是不支持的，而且本身不支持动态扩容和透明的数据迁移，而且也失去维护，Twitter内部已经不使用了。

2、豌豆荚开发的codis

1、简介

codis使用的也是proxy思路，但是做的比较好，是这两种之间的一个中间级，而且支持redis命令是最多的，有图形化GUI管理和监控工具，运维友好，这个过段时间会详细另外写出来原理、工作机制和搭建实现。

3、redis官方的redis-cluster

1、简介

Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。

1）、优点

Redis 集群通过分区来提供一定程度的可用性，在实际环境中当某个节点宕机或者不可达的情况下继续处理命令。 Redis 集群的优势:

1、自动分割数据到不同的节点上。
2、整个集群的部分节点失败或者不可达的情况下能够继续处理命令。

2）、缺点：

Redis集群并不支持处理多个keys的命令，因为这需要在不同的节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会导致不可预料的错误。

2、数据分片

Redis 集群没有使用一致性hash， 而是引入了哈希槽的概念。

Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽。集群的每个节点负责一部分hash槽。举个例子，比如当前集群有3个节点，那么:

节点 A 包含 0 到 5500号哈希槽。
节点 B 包含5501 到 11000 号哈希槽。
节点 C 包含11001 到 16384号哈希槽。

这种结构很容易添加或者删除节点。

如果我想新添加个节点D， 我需要从节点 A， B， C中得部分槽到D上。

如果我想移除节点A，需要将A中的槽移到B和C节点上，然后将没有任何槽的A节点从集群中移除即可。

由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。

3、主从复制

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型，每个节点都会有N-1个复制品。

在我们例子中具有A，B，C三个节点的集群，在没有复制模型的情况下，如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用。

然而如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点A1，B1，C1，那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了

主从复制分为两个阶段：

1、同步操作（状态同步）：将从服务器的数据库状态更新至主服务器当前所处的数据库状态
2、命令传播（数据同步）：在主服务器的数据库状态被修改，导致主从服务器的数据库状态出现不一致时，主服务器会将自己执行的写命令送给从服务器执行

不过当B和B1 都失败后，集群是不可用的。

4、Redis 一致性保证

Redis 并不能保证数据的强一致性。 这意味这在实际中集群在特定的条件下可能会丢失写操作。

1）、原因一：集群是用了异步复制

写操作过程:

客户端向主节点B写入一条命令。
主节点B向客户端回复命令状态。
主节点将写操作复制给他得从节点 B1， B2 和 B3。

主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。 注意：Redis 集群可能会在将来提供同步写的方法。

2）、原因二：集群出现了网络分区

Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区， 并且一个客户端与至少包括一个主节点在内的少数实例被孤立。

举个例子 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点， 其中 A 、B 、C 为主节点， A1 、B1 、C1 为A，B，C的从节点， 还有一个客户端 Z1 假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ，小部分的一方则包含节点 B 和客户端 Z1 。

Z1仍然能够向主节点B中写入， 如果网络分区发生时间较短，那么集群将会继续正常运作，如果分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了。

注意， 在网络分裂出现期间， 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout）， 是 Redis 集群的一个重要的配置选项。

主从节点之间有心跳检测，防止长时间网络分区。

min-slaves-max-lag 10
min-slaves-to-write 3

表示如果从服务器少于3个，或者3个从服务器的延迟都大于10秒时，主服务器拒绝写命令

4、参考资料

1）、Redis 集群教程：

http://www.redis.cn/topics/cluster-tutorial.html

2）、Redis 集群规范

http://www.redis.cn/topics/cluster-spec.html

二、故障分析方法

1、日志

1）、查看 redis 日志

2）、慢日志查询命令

SLOWLOG GET

相关参数：

slowlog-log-slower-than 10000 （微秒）
slowlog-max-len 128

只有查询执行时间大于 slowlog-log-slower-than 的才会被定义成慢查询，被 slowlog 记录。
slowlog-max-len表示慢查询最大的条数，当slowlog超过设定的最大值后，会将最早的slowlog删除，是个FIFO队列

三、快速恢复方法

1、备份恢复

1、数据物理备份恢复

1）、rdb

模拟测试：
1、原集群7000缓存数据保存到磁盘。

save 或 bgsave

2、启动新集群8000所有节点和集群，然后停止所有节点（包含从节点）。
3、将原集群rdb文件复制到新集群的数据文件目录。
4、启动新集群所有节点。
5、测试

2）、aof

2、主从复制

模拟测试：
1、停止一个redis主节点7000。
2、集群自动将该主节点的从节点7003设为主节点。
3、重启7000节点，自动设为7003的从节点。即主从互换。

四、注意

1）、集群的主从复制不能保证数据一致性。

原因：

1、异步复制
2、集群出现了网络分区

2）、动态扩展节点时，移动哈希槽失败

原因：

应该是ruby驱动和redis版本不匹配，rubygems-2.7.8支持redis版本为4.0.3及以上，而本地redis版本为3.2.100。

3）、自动化部署，一键启动

4）、自动、手动故障转移

通过主从复制功能

5）、redis-trib 命令在《redis-trib.rb》文件所在目录执行

6）、云数据库Redis集群版

https://promotion.aliyun.com/ntms/act/rediscluster.html?ali_trackid=2:mm_11561930_13480908_53448484:1543828615_258_1357872052