Redis集群(Clustering in Redis)工作机制详解

发布于:2024-07-03 ⋅ 阅读:(8) ⋅ 点赞:(0)

Redis集群工作机制详解

在这里插入图片描述

Redis 集群是用于提高 Redis 可扩展性和高可用性的解决方案。

维基百科:Scalability is the property of a system to handle a growing amount of work by adding resources to the system.

可扩展性是系统的一种允许通过增加系统资源来处理不断增长的工作量的属性。

在这里插入图片描述

The two most common scaling strategies are vertical scaling and horizontal scaling.
最常见的两种扩展策略是垂直扩展和水平扩展。
在这里插入图片描述

  • Vertical scaling,or also called scaling up,means adding more resources like CPUS or memory to your server.
    垂直扩展,也称为向上扩展,意味着向服务器添加更多的资源,如cpu或内存。

在这里插入图片描述

  • Horizontal scaling,or scaling out,implies adding more servers to your pool of resources.
    水平扩展,或者说向外扩展,意味着向资源池中添加更多服务器。
    It’s the difference between just getting a bigger server and deploying a whole fleet of servers.
    这就是购买一台更大的服务器和部署一群服务器之间的区别。

在这里插入图片描述

Redis-horizontal scaling

Since Redis is mostly single-threaded,a single Redis server instance cannot make use of the multiple cores of your server CPU for command processing.

由于Redis主要是单线程的,单个Redis服务器实例无法利用服务器CPU的多核进行命令处理。

But if we split the data between two Redis instances,our system can process requests in parallel,effectively doubling the throuoghput.

但是如果我们在两台Redis服务器实例之间分割数据,系统就可以并行处理请求,从而有效的使吞吐量加倍。

In fact,performance will scale close to linearly by adding more Redis instances to the system.

事实上,通过向系统添加更多的redis服务器,性能将接近线性扩展。

This patten of splitting data between multiple servers for the purpose of scaling is called sharding.

这种为了扩展而在多个服务器之间分割数据的模式成为——分片(Sharding)。


1. 数据分片(Sharding)

  • Redis 集群将数据分成多个分片,每个分片分布在不同的 Redis 实例上。
  • 每个分片负责一部分数据,通过哈希函数计算出哈希值再模上分片数量以映射到特定的分片上,从而实现数据的水平分布。

在这里插入图片描述

  • 但是如果我们想要进一步增加分片数量 (通常称为重新分片Resharding),该怎么办呢?

在这里插入图片描述

  • 随着片数的增加,经过哈希计算再取模的值也会改变,再去查询"foo”便会指向错误的分片。

在这里插入图片描述

Redis使用了一种巧妙的方法来解决这一问题。

在这里插入图片描述

  • 哈希槽(Hash Slots

  • Redis 集群使用 16384 个(16k)哈希槽来管理数据分片。

在这里插入图片描述

  • 每个分片负责管理一部分哈希槽,确保所有的哈希槽被分配给不同的分片,从而实现数据的均匀分布。
    在这里插入图片描述

  • 所以在Redis集群中,我们实际上用哈希值去模哈希槽,而不是分片数量。

  • Each key is assigned to a hash slot .When we do need to reshard,we simply move hash slots from one shard to another,distributing the data as required across a different Redis instances.

  • 每个键都被分配到一个哈希槽,当我们需要重新分片时,我们只需将哈希槽从一个分片移动到另一个分片,就可以根据需要在不同的Redis实例之间分发数据。

  • 数据定位:客户端在与 Redis 集群交互时,通过哈希函数计算 key 所属的哈希槽,然后根据哈希槽的分配信息找到对应的分片实例,完成数据读写操作。


2.高可用(high availability)

High availability refers to the Cluster’s ability to remain operational,even in the face of certain failures.

高可用性是指集群即使在遇到某些故障时仍能正常运行的能力。

For example,the Cluster can detect when a primary shard fails and promote a replica to a primary,without any manual intervention from the outside.

例如,集群可以检测到主分片失败并将副本提升到主分片,而无需外部的任何人工干预。

But how does it work? How does it know that a primary shard has failed,and how does it promote its replica to the new primary?

Say we have one replica for every primary shard.假设每个主分片都有一个副本。
在这里插入图片描述
在这里插入图片描述

  • All six shards are connected to each other over TCP and constantly ping each other and exchange messages.6个分片都通过TCP相互连接,并不断ping对方并交换消息。

在这里插入图片描述

  • When enough shards report that a given primary shard is not responding to them,they can agree to trigger a fail-over,and promote the shard‘s replica to become the new primary.

  • 当有足够多的分片报告某个给定的主分片对它们没有响应时,它们可以同意触发故障转移,并提升该分片的副本成为新的主分片。

在这里插入图片描述

  • How many shards need to agree that a fellow shard is offline before a fail-over is triggered?
    在触发故障转移之前,需要多少个分片同意另一个分片离线呢?

  • That’s configurable,and you can set it up when you create a Cluster.可以在创建集群时设置。

  • But there are some very imporant guidelines that you need to follow.但是需要遵循一些非常重要的方针。

  • To prevent something called a split brain situation in a Redis Cluster,always keep an odd number of primary shards and two replicas per primary shard.

  • 为了防止Redis集群中出现所谓的脑裂(split brain)情况,请始终保持奇数个主分片和每个主分片两个副本。

  • 这里我们通过一个例子解释一下缘由:假如集群中有六个分片(偶数个)。

在这里插入图片描述

  • 有一个网络分区将集群一分为二,那么将会得到两组,每组三个分片

在这里插入图片描述

  • 左侧组中的分片将无法与右侧组中的分片进行对话。

在这里插入图片描述

  • 因此集群会认为它们已离线,并将触发任何主分片的故障转移,从而导致左侧包含所有主分片

在这里插入图片描述

  • 在右侧组,也会看到左侧的分片处于离线状态,并将触发左侧所有主分片的故障转移

在这里插入图片描述

  • 从而导致,所有主分片都位于右侧。双方都认为自己为主分片。
    在这里插入图片描述

  • 将继续收到修改数据的客户端请求,例如客户端A将左侧的“foo”改成“bar”,但是客户端B设置了“foo”为“baz

在这里插入图片描述

  • 当网络分区被删除,并且分片尝试重新加入时,便会发生冲突,因为有两个分片持有不同的数据,不知道哪个数据是有效的。

在这里插入图片描述

  • 这称之为脑裂现象

在这里插入图片描述

  • 一个比较流行的解决方案就是,始终在集群中保留奇数个分片。这样当网络分裂时,左组和右组将进行计数,看看它们是否属于较大或者较小的组。如果他们占少数,他们不会触发故障转移,也不会接受任何客户端的写入请求。
    在这里插入图片描述

Redis主从复制和哨兵模式讲解在专栏哦~