Redis 集群化的 3 种方案对比

2401_84009488

于 2024-04-18 01:33:38 发布

阅读量914

点赞数 9

分类专栏：程序员文章标签： redis java mybatis

本文链接：https://blog.csdn.net/2401_84009488/article/details/137896040

版权

程序员专栏收录该内容

195 篇文章 0 订阅

订阅专栏

而主从复制则是部署多个副本节点，多个副本节点实时复制主节点的数据，当主节点宕机时，我们有完整的副本节点可以使用。另一方面，如果我们业务的读请求量很大，主节点无法承受所有的读请求，多个副本节点可以分担读请求，实现读写分离，这样可以提高Redis的访问性能。

但有个问题是，当主节点宕机时，我们虽然有完整的副本节点，但需要手动操作把从节点提升为主节点继续提供服务，如果每次主节点故障，都需要人工操作，这个过程既耗时耗力，也无法保证及时性，高可用的程度将大打折扣。如何优化呢？

有了数据持久化、主从复制、故障自动恢复这些功能，我们在使用Redis时是不是就可以高枕无忧了？

答案是否定的，如果我们的业务大部分都是读请求，可以使用读写分离提升性能。但如果写请求量也很大呢？现在是大数据时代，像阿里、腾讯这些大体量的公司，每时每刻都拥有非常大的写入量，此时如果只有一个主节点是无法承受的，那如何处理呢？

这就需要集群化！简单来说实现方式就是，多个主从节点构成一个集群，每个节点存储一部分数据，这样写请求也可以分散到多个主节点上，解决写压力大的问题。同时，集群化可以在节点容量不足和性能不够时，动态增加新的节点，对进群进行扩容，提升性能。

从这篇文章开始，我们就开始介绍Redis的集群化方案。当然，集群化也意味着Redis部署架构更复杂，管理和维护起来成本也更高。而且在使用过程中，也会遇到很多问题，这也衍生出了不同的集群化解决方案，它们的侧重点各不相同。

这篇文章我们先来整体介绍一下Redis集群化比较流行的几个解决方案，先对它们有整体的认识，后面我会专门针对我比较熟悉的集群方案进行详细的分析。

集群化方案

=====

要想实现集群化，就必须部署多个主节点，每个主节点还有可能有多个从节点，以这样的部署结构组成的集群，才能更好地承担更大的流量请求和存储更多的数据。

可以承担更大的流量是集群最基础的功能，一般集群化方案还包括了上面提到了数据持久化、数据复制、故障自动恢复功能，利用这些技术，来保证集群的高性能和高可用。

另外，优秀的集群化方案还实现了在线水平扩容功能，当节点数量不够时，可以动态增加新的节点来提升整个集群的性能，而且这个过程是在线完成的，业务无感知。

业界主流的Redis集群化方案主要包括以下几个：

客户端分片
Codis
Twemproxy
Redis Cluster

它们还可以用是否中心化来划分，其中客户端分片、Redis Cluster属于无中心化的集群方案，Codis、Tweproxy属于中心化的集群方案。

是否中心化是指客户端访问多个Redis节点时，是直接访问还是通过一个中间层Proxy来进行操作，直接访问的就属于无中心化的方案，通过中间层Proxy访问的就属于中心化的方案，它们有各自的优劣，下面分别来介绍。

客户端分片

=====

客户端分片主要是说，我们只需要部署多个Redis节点，具体如何使用这些节点，主要工作在客户端。

客户端通过固定的Hash算法，针对不同的key计算对应的Hash值，然后对不同的Redis节点进行读写。

客户端分片集群模式

客户端分片需要业务开发人员事先评估业务的请求量和数据量，然后让DBA部署足够的节点交给开发人员使用即可。

这个方案的优点是部署非常方便，业务需要多少个节点DBA直接部署交付即可，剩下的事情就需要业务开发人员根据节点数量来编写key的请求路由逻辑，制定一个规则，一般采用固定的Hash算法，把不同的key写入到不同的节点上，然后再根据这个规则进行数据读取。

可见，它的缺点是业务开发人员使用Redis的成本较高，需要编写路由规则的代码来使用多个节点，而且如果事先对业务的数据量评估不准确，后期的扩容和迁移成本非常高，因为节点数量发生变更后，Hash算法对应的节点也就不再是之前的节点了。

所以后来又衍生出了一致性哈希算法，就是为了解决当节点数量变更时，尽量减少数据的迁移和性能问题。

这种客户端分片的方案一般用于业务数据量比较稳定，后期不会有大幅度增长的业务场景下使用，只需要前期评估好业务数据量即可。

Codis

=====

随着业务和技术的发展，人们越发觉得，当我需要使用Redis时，我们不想关心集群后面有多少个节点，我们希望我们使用的Redis是一个大集群，当我们的业务量增加时，这个大集群可以增加新的节点来解决容量不够用和性能问题。

这种方式就是服务端分片方案，客户端不需要关心集群后面有多少个Redis节点，只需要像使用一个Redis的方式去操作这个集群，这种方案将大大降低开发人员的使用成本，开发人员可以只需要关注业务逻辑即可，不需要关心Redis的资源问题。

多个节点组成的集群，如何让开发人员像操作一个Redis时那样来使用呢？这就涉及到多个节点是如何组织起来提供服务的，一般我们会在客户端和服务端中间增加一个代理层，客户端只需要操作这个代理层，代理层实现了具体的请求转发规则，然后转发请求到后面的多个节点上，因此这种方式也叫做中心化方式的集群方案，Codis就是以这种方式实现的集群化方案。