Redis第9讲——Redis 3.0之前各大厂商的集群方案

上篇文章介绍了Redis 3.0版本开始支持的Cluster集群，但在Redis 3.0版本之前，Redis主要是以单实例模式运行，无法很好地应对大规模和高负载的需求。虽然Redis的开发者Antirez早在博客上就提出Redis 3.0版本中加入集群功能，但是要等到2015年才发布正式版。在3.0版本还没发布之前为了解决这个存储瓶颈问题，纷纷推出自己的Redis集群方案。这些方案的核心是把数据分片（sharding）存储在多个Redis实例中，每一片就是一个Redis实例。

一、什么是集群化方案

• 要达到集群化的效果，就需要配置多个主节点，并且每个主节点可能还会包含多个从节点。只有通过这样的部署结构，集群才能更好地处理更大的流量请求和存储更多的数据。并且还需借助数据持久化、数据复制和故障自动转移等功能来保证高可用性。
• 更优秀的集群化方案还需支持在线水平扩展能力，当节点数量不足时，可以动态地添加新节点以提升整个集群的性能，当然，这个过程对业务来说是无感知的。
• 业界主流的Redis集群化方案主要有客户端分片、Codis、Twemproxy和Redis Cluster，前三种都是在Redis 3.0版本没发布之前各大厂商使用的集群方案，下面我们分别来介绍一下。

二、 客户端分片

2.1 什么是客户端分片

客户端分片是把分片的逻辑放在Redis客户端实现，（比如：jedis已支持Redis Sharding功能，即ShardedJedis），通过Redis客户端预先定义好的路由规则(一般采用固定的哈希算法)，把不同的key写入到不同的节点上，然后再根据这个规则进行数据读取。

如果某个节点不可用，客户端会根据事先定义的容错机制，选择另一个节点进行数据访问。

2.2 优缺点

优点：

• 客户端sharding技术使用hash一致性算法分片的好处是所有的逻辑都是可控的，不依赖于第三方分布式中间件。
• 服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。
• 开发人员清楚怎么实现分片、路由的规则，不用担心踩坑。

缺点：

• 这是一种静态的分片方案，需要增加或者减少Redis实例的数量，需要手工调整分片的程序。
• 在不同的客户端程序中，维护相同的路由分片逻辑成本巨大。比如：java项目、PHP项目里共用一套Redis集群，路由分片逻辑分别需要写两套一样的逻辑，以后维护也是两套。

客户端分片最大的问题就是，Redis实例在添加或删除时，每个客户端都需要更新调整，为了解决这个问题，代理分片就出现了。

三、 Twemproxy代理分片

3.1 什么是Twemproxy

Redis代理分片用得最多的就是由Twitter开源的Twemproxy，其原理是通过中间件的形式，Redis客户端把请求发送到Twemproxy，Twemproxy再根据路由规则发送到正确的Redis实例，最后Twemproxy把结果汇集返回给客户端，大致实现如下：

• 在客户端和Redis实例之间引入一个代理层，负责接收客户端请求并将请求路由到响应的Redis节点。
• 代理负责管理所有的Redis节点信息，并能够动态地调整节点的配置。
• 当客户端需要进行读取或写入操作时，代理根据事先定义的分片规则将请求路由到相应的Redis节点。这可以是基于一致性哈希算法或其他路由策略。
• 当有新的Redis节点加入或离开集群时，代理会进行重新配置，并确保数据分布和路由的正确性。

这就解决了客户端分片——Redis实例在添加或删除时，每个客户端都需要进行逻辑调整的问题。

3.2 优缺点

优点：

• 客户端无需关心具体的分片逻辑，通过代理层实现数据的分片和路由，降低了客户端的复杂性。
• 代理可以根据需要动态调整集群的规模，实现节点的动态扩容和缩容。

缺点：

• 没有友好的监控管理后台界面，不利于运维监控。
• 由于请求需要经过代理层，可能引入一定的性能开销。尤其在代理处于瓶颈状态时，系统性能可能受到限制。
• Twemproxy最大的痛点在于，无法平滑地扩容/缩容。对于运维人员来说，当因为业务需要增加Redis实例时工作量非常大。

四、 Codis代理分片

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

4.1 什么是Codis代理分片

Codis在Twemproxy的基础上进行了改进，并提供了更加完善的管理功能和监控工具。Codis的客户端分片模式基于一致性哈希算法，可以将数据按照一定的规则分散到多个Redis节点上，并提供了简单易用的接口和管理界面。

Codis架构图：

组件介绍：

• Codis Proxy：主要负责对请求的读写进行转发
• Codis Dashboard：统一的控制中心，整合了数据转发规则、故障自动恢复、数据在线迁移、节点扩容缩容、自动化运维API等功能，Dashboard最多部署一个。
• Codis Admin：集群管理的命令行工具。
• Codis FE：集群管理界面，多个Codis集群可以共用一个Codis FE，通过配置文件管理后端的codis-dashboard。
• Storage：为集群提供外部存储，目前支持ZooKeeper、Etcd、Fs三种。
• Codis Server：基于3.2.8分支开发，增加额外的数据结构，用来支持slot有关的操作及数据迁移指令。

4.2 特点

Codis的客户端分片模式具有以下特点：

• 代理层：当请求到达时，Proxy会根据预定义的分片规则计算出该请求应该路由到哪一个Redis节点，并将请求转发到目标节点。
• 节点管理：Codis Dashboard是Codis的管理控制台，提供Web界面用于管理和监控Redis集群。它允许管理员动态地添加或移除节点，以及在节点间迁移槽，实现了集群的动态调整和容错管理。
• 容错处理：旦主节点发生故障，系统可以自动或手动切换到从节点，以保证服务的连续性。此外，Codis Proxy在检测到节点故障时可以临时将请求路由到其他健康的节点，直到故障节点恢复或被替换。
• 数据分片：Codis中采用预分片的形式，启动的时候就创建了1024个slot，1个slot相当于1个箱子，每个箱子有固定的编号，范围是1~1024。slot这个箱子用作存放Key，至于Key存放到哪个箱子，可以通过算法“crc32(key)%1024”获得一个数字，这个数字的范围一定是1~1024之间，Key就放到这个数字对应的slot。

4.3 平滑扩/缩容

Codis最大的优势在于支持平滑增加（减少）Redis实例，能安全、透明地迁移数据，这也是Codis 有别于Twemproxy等静态分布式 Redis 解决方案的地方。Codis增加了Redis实例后，就牵涉到slot的迁移问题。

假如现在有两个redis实例A、B，A负责1~500槽位，B负责501~1024槽位，但现在需要增加一个Redis实例C，那么槽位如何分配呢？一般有两种方式：

• 第一种：通过CodisConfig手动重新分配，指定每个Redis负责的槽范围，例如Redis实例A负责1~500，B负责501~700，C负责701~1024。

• 第二种：通过Codisconfig的rebalance功能，会自动根据每个Redis Server Group的内存对slot进行迁移，以实现数据的均衡。

4.4 优缺点

优点：

• Codis支持Redis的主从复制机制，具备故障转移和自动恢复的能力，增强了系统的可靠性和容错性。
• Codis Dashboard提供了直观的Web界面来管理和监控Redis集群，管理员可以方便地查看集群状态、节点信息，并进行操作和调整。
• 支持平滑增加（减少）Redis实例。

缺点：

• Codis Proxy作为中间层存在，可能会引入一定程度的性能损耗，尤其是在高并发场景下，需要考虑Proxy的性能影响。
• 在分布式环境中，数据一致性和同步是一个复杂的问题，尤其是在节点故障或网络分区的情况下，需要谨慎处理以确保数据的完整性和一致性。

五、Redis Cluster（插播一条）

采用中间加一层Proxy的中心化模式时，这就对Proxy的要求很高，因为它一旦出现故障，那么操作这个Proxy的所有客户端都无法处理，而且增加一层Proxy，必然会有一定的性能损耗，要想解决这些问题，貌似就只能采用去中心化的架构模式。

Redis官方推出的Redis Cluster另辟蹊径，它没有采用中心化模式的Proxy方案，而是把请求转发逻辑一部分放在客户端，一部分放在了服务端，它们之间互相配合完成请求的处理。

随着Redis的版本迭代，Redis官方的Cluster也越来越稳定，更多人开始采用官方的集群化方案。

ps：由于上篇文章已经介绍过了，这里就不再赘述了。

六、各个集群化方案对比

ps：是否中心化是指客户端访问多个Redis节点时，直接访问的就属于无中心化的方案，通过中间层Proxy访问的就属于中心化的方案。

ps：Redis Smart Client是一个用于与Redis数据库进行交互的客户端库。它提供了一组简单易用的API，比如连接池管理、负载均衡、自动故障转移、数据分片、智能路由、连接健康检查等功能。

End：希望对大家有所帮助，如果有纰漏或者更好的想法，请您一定不要吝啬你的赐教🙋。