Redis集群方案

概述

Redis 3.0版本中加入集群的功能，但3.0版本一直在2015年才发布正式版。各大企业在3.0版本还没发布前为了解决Redis的存储瓶颈，纷纷推出了各自的Redis集群方案。

这些方案的核心思想是把数据分片（sharding）存储在多个Redis实例中，每一片就是一个Redis实例。下面介绍Redis的集群方案。

集群方案

客户端分片

客户端分片是把分片的逻辑放在Redis客户端实现，通过Redis客户端预先定义好的路由规则，把对Key的访问转发到不同的Redis实例中，最后把返回结果汇集。

这种方案的模式如下图所示：

客户端分片的优点：

所有的逻辑都是可控的，不依赖于第三方分布式中间件
开发人员清楚怎么实现分片、路由的规则，不用担心踩坑
客户端分片的缺点：
这是一种静态的分片方案，需要增加或者减少Redis实例的数量，需要手工调整分片的程序。
可运维性差，集群的数据出了任何问题都需要运维人员和开发人员一起合作，减缓了解决问题的速度，增加了跨部门沟通的成本。
在不同的客户端程序中，维护相同的分片逻辑成本巨大。

Twemproxy

Twemproxy是由Twitter开源的Redis代理，其基本原理是：Redis客户端把请求发送到Twemproxy，Twemproxy根据路由规则发送到正确的Redis实例，最后Twemproxy把结果汇集返回给客户端。

Twemproxy通过引入一个代理层，将多个Redis实例进行统一管理，使Redis客户端只需要在Twemproxy上进行操作，而不需要关心后面有多少个Redis实例，从而实现了Redis集群。

Twemproxy集群架构如下图所示：

twemproxy

Twemproxy的优点：

客户端像连接Redis实例一样连接Twemproxy，不需要改任何的代码逻辑
支持无效Redis实例的自动删除
Twemproxy与Redis实例保持连接，减少了客户端与Redis实例的连接数
Twemproxy的缺点：
由于Redis客户端的每个请求都经过Twemproxy代理才能到达Redis服务器，这个过程中会产生性能损失
没有友好的监控管理后台界面，不利于运维监控
最大的问题是Twemproxy无法平滑地增加Redis实例，对于运维人员来说，当因为业务需要增加Redis实例时工作量非常大
Twemproxy作为最被广泛使用、最久经考验、稳定性最高的Redis代理，在业界被广泛使用。

Codis

Twemproxy不能平滑增加Redis实例的问题带来了很大的不便，于是豌豆荚自主研发了Codis，一个支持平滑增加Redis实例的Redis代理软件，其基于Go和C语言开发，并于2014年11月在GitHub上开源。

Codis包含下面4个部分：

Codis Proxy：
Redis客户端连接到Redis实例的代理，实现了Redis的协议，Redis客户端连接到Codis Proxy进行各种操作。Codis Proxy是无状态的，可以用Keepalived等负载均衡软件部署多个Codis Proxy实现高可用。
Codis Redis：
Codis项目维护的Redis分支，添加了slot和原子的数据迁移命令。Codis上层的 Codis Proxy和Codisconfig只有与这个版本的Redis通信才能正常运行。
Codisconfig：
Codis管理工具。可以执行添加删除CodisRedis节点、添加删除Codis Proxy、数据迁移等操作。另外，Codisconfig自带了HTTP server，里面集成了一个管理界面，方便运维人员观察Codis集群的状态和进行相关的操作，极大提高了运维的方便性，弥补了Twemproxy的缺点。
ZooKeeper：
分布式的、开源的应用程序协调服务，是Hadoop和Hbase的重要组件，其为分布式应用提供一致性服务，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。Codis依赖于ZooKeeper存储数据路由表的信息和Codis Proxy节点的元信息。另外，Codisconfig发起的命令都会通过ZooKeeper同步到Codis Proxy的节点。

Codis的架构如下图所示：

codis

Redis Cluster

Redis Cluster在Redis 3.0开始支持，采用无中心的方式，为了维护集群状态统一，节点之间需要互相交换消息，Redis采用交换消息的方式被称为 Gossip ，基本思想是节点之间互相交换信息最终所有节点达到一致，更多关于 Gossip 可参考 https://en.wikipedia.org/wiki/Gossip_protocol

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

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

Redis 集群特点

自动分割数据到不同的节点上。
整个集群的部分节点失败或者不可达的情况下能够继续处理命令。
可线性扩展到上千个节点
可使数据自动路由到多个节点
实现了多个节点间的数据共享
可支持动态增加或删除节点
可保证某些节点无法提供服务时不影响整个集群的操作
不保证数据的强一致性
支持Redis所有处理单个数据库键的命令
不支持对多个数据库键的操作，比如MSET、SUNION
不能使用 SELECT 命令，集群只使用默认的0号数据库

Redis 集群数据共享

Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现：一个 Redis 集群包含 16384 个哈希槽（hash slot），数据库中的每个键都属于这 16384 个哈希槽的其中一个，集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽，其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和。

集群中的每个节点负责处理一部分哈希槽。举个例子，一个集群可以有三个节点，其中：

节点 A 负责处理 0 号至 5500 号哈希槽。
节点 B 负责处理 5501 号至 11000 号哈希槽。
节点 C 负责处理 11001 号至 16384 号哈希槽。

这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。比如说：

如果用户将新节点 D 添加到集群中，那么集群只需要将节点 A 、B 、 C 中的某些槽移动到节点 D 就可以了。
与此类似，如果用户要从集群中移除节点 A ，那么集群只需要将节点 A 中的所有哈希槽移动到节点 B 和节点 C ，然后再移除空白（不包含任何哈希槽）的节点 A 就可以了。
因为将一个哈希槽从一个节点移动到另一个节点不会造成节点阻塞，所以无论是添加新节点还是移除已存在节点，又或者改变某个节点包含的哈希槽数量，都不会造成集群下线。

Redis 集群中的主从复制

为了使得集群在一部分节点下线或者无法与集群的大多数（majority）节点进行通讯的情况下，仍然可以正常运作， Redis 集群对节点使用了主从复制功能：集群中的每个节点都有 1 个至 N 个复制品（replica），其中一个复制品为主节点（master），而其余的 N-1 个复制品为从节点（slave）。

在之前列举的节点 A 、B 、C 的例子中，如果节点 B 下线了，那么集群将无法正常运行，因为集群找不到节点来处理 5501 号至 11000号的哈希槽。

另一方面，假如在创建集群的时候（或者至少在节点 B 下线之前），我们为主节点 B 添加了从节点 B1 ，那么当主节点 B 下线的时候，集群就会将 B1 设置为新的主节点，并让它代替下线的主节点 B ，继续处理 5501 号至 11000 号的哈希槽，这样集群就不会因为主节点 B 的下线而无法正常运作了。

不过如果节点 B 和 B1 都下线的话， Redis 集群还是会停止运作。

Redis 集群的一致性保证（guarantee）

Redis 集群不保证数据的强一致性（strong consistency）：在特定条件下， Redis 集群可能会丢失已经被执行过的写命令。

使用异步复制（asynchronous replication）是 Redis 集群可能会丢失写命令的其中一个原因。考虑以下这个写命令的例子：

客户端向主节点 B 发送一条写命令。
主节点 B 执行写命令，并向客户端返回命令回复。
主节点 B 将刚刚执行的写命令复制给它的从节点 B1 、 B2 和 B3 。

如你所见，主节点对命令的复制工作发生在返回命令回复之后，因为如果每次处理命令请求都需要等待复制操作完成的话，那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。

如果真的有必要的话， Redis 集群可能会在将来提供同步地（synchronou）执行写命令的方法。

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

举个例子，假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点，其中 A 、B 、C 为主节点，而 A1 、B1 、C1 分别为三个主节点的从节点，另外还有一个客户端 Z1 。

假设集群中发生网络分裂，那么集群可能会分裂为两方，大多数（majority）的一方包含节点 A 、C 、A1 、B1 和 C1 ，而少数（minority）的一方则包含节点 B 和客户端 Z1 。

在网络分裂期间，主节点 B 仍然会接受 Z1 发送的写命令：

如果网络分裂出现的时间很短，那么集群会继续正常运行；
但是，如果网络分裂出现的时间足够长，使得大多数一方将从节点 B1 设置为新的主节点，并使用 B1 来代替原来的主节点 B ，那么 Z1 发送给主节点 B 的写命令将丢失。
注意，在网络分裂出现期间，客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的，这一时间限制称为节点超时时间（node timeout），是 Redis 集群的一个重要的配置选项：
对于大多数一方来说，如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群，那么集群会将这个主节点视为下线，并使用从节点来代替这个主节点继续工作。
对于少数一方，如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群，那么它将停止处理写命令，并向客户端报告错误。