[redis]cluster模式详解

问题.当数据量增加时,是需要横向扩展还是纵向扩展

纵向就是增加内存,磁盘. 简单暴力.但是存在一些问题

1.如果用rdb持久化,那么内存也会需要很多,fork时阻塞时间也会变长

2.内存扩展受限.扩展1T内存,不太现实

 

因此redis3.0 推出了集群模式

1.将数据分配在16384个槽里.数据通过 hash+取模,计算出key应该存放在哪个槽里.

2.集群中每个实例都分配一部分槽,这个既可以平均分配,也可以手动指定,但是,每个槽必须都得分配完,不然无法工作.

 

1.那么问题来了,槽和实例的信息存在哪里?每个节点都有吗?客户端也有吗?

确实都有

客户端存储映射信息.在获取数据时,根据key计算出slot,根据映射信息得到实例.

当redis集群扩缩容时,必然会迁移slot数据,此时使用重定向来解决访问异常问题.

 

2.那扩缩容后,映射信息都是怎么同步的呢?

redis在启动的时候,会启动两个端口,2379 ,12379. 一个用来接收client请求,一个用来集群间的通信.   通信协议就是gossip协议.

其实元数据的存储可以有两种方式,集中式和分布式.

集中式:

例如storm元数据存储在zk中,并通过leader来进行操作,优点是便于管理,缺点是单点压力大.

gossip:

谣言算法,就是1传2,2传4.跟大妈一样.

具体可以参考

https://time.geekbang.org/column/article/208182

 

 

老师最后提了一个问题

Redis Cluster不采用把key直接映射到实例的方式，而采用哈希槽的方式

k神的回答--->

原因：

1、整个集群存储key的数量是无法预估的，key的数量非常多时，直接记录每个key对应的实例映射关系，这个映射表会非常庞大，这个映射表无论是存储在服务端还是客户端都占用了非常大的内存空间。

2、Redis Cluster采用无中心化的模式（无proxy，客户端与服务端直连），客户端在某个节点访问一个key，如果这个key不在这个节点上，这个节点需要有纠正客户端路由到正确节点的能力（MOVED响应），这就需要节点之间互相交换路由表，每个节点拥有整个集群完整的路由关系。如果存储的都是key与实例的对应关系，节点之间交换信息也会变得非常庞大，消耗过多的网络资源，而且就算交换完成，相当于每个节点都需要额外存储其他节点的路由表，内存占用过大造成资源浪费。  现在每个节点只要缓存 实例和槽的映射就行, 不用缓存 实例和key的映射.明显不是一个重量级的数据

3、当集群在扩容、缩容、数据均衡时，节点之间会发生数据迁移，迁移时需要修改每个key的映射关系，维护成本高。

4、而在中间增加一层哈希槽，可以把数据和节点解耦，key通过Hash计算，只需要关心映射到了哪个哈希槽，然后再通过哈希槽和节点的映射表找到节点，相当于消耗了很少的CPU资源，不但让数据分布更均匀，还可以让这个映射表变得很小，利于客户端和服务端保存，节点之间交换信息时也变得轻量。

客户端还要存储呢,如果映射表太大,就gg了

5、当集群在扩容、缩容、数据均衡时，节点之间的操作例如数据迁移，都以哈希槽为基本单位进行操作，简化了节点扩容、缩容的难度，便于集群的维护和管理。

另外，我想补充一下Redis集群相关的知识，以及我的理解：

Redis使用集群方案就是为了解决单个节点数据量大、写入量大产生的性能瓶颈的问题。多个节点组成一个集群，可以提高集群的性能和可靠性，但随之而来的就是集群的管理问题，最核心问题有2个：请求路由、数据迁移（扩容/缩容/数据平衡）。

1、请求路由：一般都是采用哈希槽的映射关系表找到指定节点，然后在这个节点上操作的方案。

Redis Cluster在每个节点记录完整的映射关系(便于纠正客户端的错误路由请求)，同时也发给客户端让客户端缓存一份，便于客户端直接找到指定节点，客户端与服务端配合完成数据的路由，这需要业务在使用Redis Cluster时，必须升级为集群版的SDK才支持客户端和服务端的协议交互。

其他Redis集群化方案例如Twemproxy、Codis都是中心化模式（增加Proxy层），客户端通过Proxy对整个集群进行操作，Proxy后面可以挂N多个Redis实例，Proxy层维护了路由的转发逻辑。操作Proxy就像是操作一个普通Redis一样，客户端也不需要更换SDK，而Redis Cluster是把这些路由逻辑做在了SDK中。当然，增加一层Proxy也会带来一定的性能损耗。

2、数据迁移：当集群节点不足以支撑业务需求时，就需要扩容节点，扩容就意味着节点之间的数据需要做迁移，而迁移过程中是否会影响到业务，这也是判定一个集群方案是否成熟的标准。

Twemproxy不支持在线扩容，它只解决了请求路由的问题，扩容时需要停机做数据重新分配。而Redis Cluster和Codis都做到了在线扩容（不影响业务或对业务的影响非常小），重点就是在数据迁移过程中，客户端对于正在迁移的key进行操作时，集群如何处理？还要保证响应正确的结果？

Redis Cluster和Codis都需要服务端和客户端/Proxy层互相配合，迁移过程中，服务端针对正在迁移的key，需要让客户端或Proxy去新节点访问（重定向），这个过程就是为了保证业务在访问这些key时依旧不受影响，而且可以得到正确的结果。由于重定向的存在，所以这个期间的访问延迟会变大。等迁移完成之后，Redis Cluster每个节点会更新路由映射表，同时也会让客户端感知到，更新客户端缓存。Codis会在Proxy层更新路由表，客户端在整个过程中无感知。

除了访问正确的节点之外，数据迁移过程中还需要解决异常情况（迁移超时、迁移失败）、性能问题（如何让数据迁移更快、bigkey如何处理），这个过程中的细节也很多。

Redis Cluster的数据迁移是同步的，迁移一个key会同时阻塞源节点和目标节点，迁移过程中会有性能问题。而Codis提供了异步迁移数据的方案，迁移速度更快，对性能影响最小，当然，实现方案也比较复杂。

 

 

 

 

参考:https://time.geekbang.org/column/article/276545