Redis 集群搭建原理

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介: Redis 集群搭建原理

一、设计的主要特性和基本原理

1、集群目标

Redis 集群是 Redis 的分布式实现,在设计中按重要性顺序具有以下目标:

  • 高性能和线性可扩展性,多达 1000 个节点。没有代理,使用异步复制,并且不对值执行合并操作。
  • 可接受的写入安全程度:系统尝试(以最大努力)保留来自与大多数主节点连接的客户端的所有写入。通常有一些小窗口,其中确认的写入可能会丢失。当客户端位于少数分区中时,丢失已确认写入的 Windows 会更大。
  • 可用性:Redis 集群能够在大多数主节点可访问的分区中幸存下来,并且对于不再可访问的每个主节点,至少有一个可访问的副本。此外,使用副本迁移,不再由任何副本复制的主节点将从多个副本覆盖的主节点接收一个。

本文档中描述的内容在 Redis 3.0 或更高版本中实现

2、已实现的子集

Redis Cluster实现了非分布式版本Redis中所有可用的单键命令。执行复杂的多键操作(如集合并集和交集)的命令用于将操作中涉及的所有键散列到同一槽的情况。

Redis Cluster实现了一个称为哈希标签的概念,可以用来强制将某些密钥存储在同一个哈希槽中。然而,在手动重新装载期间,多键操作可能会在一段时间内不可用,而单键操作始终可用。

Redis群集不支持多个数据库,如独立版本的Redis。我们只支持数据库0;不允许SELECT命令。

二、Redis 集群协议中的客户端和服务器角色

在 Redis 集群中,节点负责保存数据, 并获取群集的状态,包括将密钥映射到正确的节点。 群集节点还能够自动发现其他节点,检测不工作 节点,并在需要时按顺序提升副本节点以主节点 以在发生故障时继续运行。

要执行其任务,所有群集节点都使用 TCP 总线和二进制协议,称为 Redis 集群总线。 每个节点都使用群集连接到群集中的每个其他节点 总线。节点使用八卦协议来传播有关集群的信息 为了发现新节点,发送ping数据包以确保所有 其他节点工作正常,并发送群集消息所需的 信号特定条件。集群总线也用于 在整个集群中传播发布/订阅消息并手动编排 用户请求时的故障转移(手动故障转移是故障转移 不是由 Redis 集群故障检测器启动,而是由 直接系统管理员)。

由于群集节点无法代理请求,因此可以使用重定向错误-MOVED和-ASK将客户端重定向到其他节点。理论上,客户机可以自由地向集群中的所有节点发送请求,如果需要,可以进行重定向,因此客户机不需要保持集群的状态。然而,能够缓存键和节点之间的映射的客户端可以以合理的方式提高性能。

1、写入安全

Redis 集群使用节点之间的异步复制,上次故障转移胜过隐式合并功能。这意味着最后一个选择的主数据集最终会替换所有其他副本。在分区期间,总是有一个时间窗口可能会丢失写入。但是,对于连接到大多数主节点的客户端和连接到少数主节点的客户端,这些窗口非常不同。

与在少数端执行的写入相比,Redis 集群会更努力地保留由连接到大多数主服务器的客户端执行的写入。 以下是导致已确认丢失的方案示例 故障期间在多数分区中收到的写入:

  1. 写入操作可能会到达主节点,但虽然主节点可能能够回复客户端,但写入操作可能不会通过主节点和副本节点之间使用的异步复制传播到副本节点。如果主服务器在写操作到达副本的情况下死亡,则当主节点在足够长的时间内无法访问以提升其副本之一时,写操作将永远丢失。在主节点完全突然发生故障的情况下,这通常很难观察到,因为主节点试图几乎同时回复客户端(确认写入)和副本(传播写入)。然而,这是一种现实世界的故障模式。
  2. 理论上可能的写入丢失的故障模式如下:
  • 由于分区,无法访问主节点。
  • 它被其中一个副本故障转移。
  • 一段时间后,它可能会再次访问。
  • 具有过期路由表的客户端可以在集群将其转换为(新主节点)副本之前写入旧主节点。

第二种故障模式不太可能发生,因为主节点无法与大多数其他主节点通信足够长的时间进行故障转移,将不再接受写入,并且当分区固定时,写入仍会被拒绝一小段时间,以允许其他节点通知配置更改。此故障模式还要求客户端的路由表尚未更新。

针对分区少数侧的写入具有更大的丢失窗口。例如,Redis Cluster 在只有少数主节点和至少一个或多个客户端的分区上丢失大量写入操作,因为如果主节点在多数端进行故障转移,则发送到主服务器的所有写入操作都可能会丢失。

具体来说,对于要进行故障转移的主机,大多数主机必须至少在NODE_TIMEOUT内无法访问它,因此如果在该时间之前分区已修复,则不会丢失任何写入。当分区持续时间超过NODE_TIMEOUT时,在少数方执行的所有写入操作都可能丢失。然而,当NODE_TIMEOUT时间过去后,Redis群集的少数方将开始拒绝写入,而不会与多数方接触,因此有一个最大窗口,在该窗口之后,少数方将不再可用。因此,在此时间之后,不会接受或丢失任何写入。

具体来说,对于要进行故障转移的主机,大多数主机必须至少在NODE_TIMEOUT内无法访问它,因此如果在该时间之前分区已修复,则不会丢失任何写入。当分区持续时间超过NODE_TIMEOUT时,在少数方执行的所有写入操作都可能丢失。然而,当NODE_TIMEOUT时间过去后,Redis群集的少数方将开始拒绝写入,而不会与多数方接触,因此有一个最大窗口,在该窗口之后,少数方将不再可用。因此,在此时间之后,不会接受或丢失任何写入。

2、可用性

Redis群集在分区的少数部分不可用。在分区的多数侧,假设至少有大多数主机和每个不可访问的主机的副本,则在NODE_TIMEOUT时间加上副本选择和故障切换其主机所需的几秒后,群集将再次可用(故障切换通常在1或2秒内执行)。

这意味着Redis群集的设计是为了在集群中的几个节点发生故障时能够生存下来,但对于需要在发生大规模网络拆分时可用性的应用程序来说,它不是一个合适的解决方案。

在由N个主节点组成的集群的示例中,其中每个节点都具有单个副本,并且当两个节点被分割开时,将以1-(1/(N*2-1))的概率保持可用(在第一个节点发生故障之后,我们总共剩下N*2-1个节点,唯一没有副本的主节点发生故障的概率为1/(N*2-1))。

例如,在一个具有5个节点和每个节点一个副本的集群中,有1/(5*2-1)=11.11%的概率,即在将两个节点从大多数节点分割后,该集群将不再可用。

由于Redis群集的一个称为副本迁移的功能,副本迁移到孤立的主机(主机不再具有副本)这一事实在许多现实场景中提高了群集的可用性。因此,在每次成功的失败事件中,集群都可以重新配置副本布局,以便更好地抵御下一次失败。

3、性能

在 Redis 中,集群节点不会将命令代理给负责给定密钥的正确节点,而是将客户端重定向到为密钥空间的给定部分提供服务的正确节点。

最终,客户端会获得群集的最新表示形式,以及哪个节点为哪个密钥子集提供服务,因此在正常操作期间,客户端会直接联系正确的节点以发送给定的命令。

由于使用了异步复制,节点不会等待其他节点的写入确认(如果未使用 WAIT 命令显式请求)。

此外,由于多键命令仅限于键,因此除非重新分片,否则数据永远不会在节点之间移动。

正常操作的处理方式与单个 Redis 实例的处理方式完全相同。这意味着,在具有 N 个主节点的 Redis 集群中,随着设计线性扩展,您可以期望获得与单个 Redis 实例乘以 N 相同的性能。同时,查询通常在单个往返中执行,因为客户端通常保留与节点的持久连接,因此延迟数字也与单个独立 Redis 节点的情况相同。

非常高的性能和可扩展性,同时保留弱但 合理形式的数据安全性和可用性是 Redis 集群

4、为什么避免合并操作

Redis 集群设计避免了多个节点中同一键值对的冲突版本,因为在 Redis 数据模型的情况下,这并不总是可取的。Redis 中的值通常非常大;通常会看到包含数百万个元素的列表或排序集。此外,数据类型在语义上也很复杂。传输和合并这些类型的值可能是一个主要瓶颈和/或可能需要应用程序端逻辑的不平凡参与、用于存储元数据的额外内存等。

这里没有严格的技术限制。CRDT 或同步复制 状态机可以对类似于 Redis 的复杂数据类型进行建模。然而, 此类系统的实际运行时行为与 Redis 集群不同。 Redis 集群旨在涵盖 非集群 Redis 版本。

三、Redis 集群主要组件概述

1、密钥分发模型

在 Redis 集群中,节点负责保存数据, 并获取群集的状态,包括将密钥映射到正确的节点。 群集节点还能够自动发现其他节点,检测不工作 节点,并在需要时按顺序提升副本节点以主节点 以在发生故障时继续运行。

要执行其任务,所有群集节点都使用 TCP 总线和二进制协议,称为 Redis 集群总线。 每个节点都使用群集连接到群集中的每个其他节点 总线。节点使用八卦协议来传播有关集群的信息 为了发现新节点,发送ping数据包以确保所有 其他节点工作正常,并发送群集消息所需的 信号特定条件。集群总线也用于 在整个集群中传播发布/订阅消息并手动编排 用户请求时的故障转移(手动故障转移是故障转移 不是由 Redis 集群故障检测器启动,而是由 直接系统管理员)。

用于将密钥映射到哈希槽的基本算法如下(请阅读下一段,了解该规则的哈希标记例外情况):

HASH_SLOT = CRC16(key) mod 16384

CRC16的规定如下:

  • 名称:XMODEM(也称为ZMODEM或CRC-16 / ACORN)
  • 宽度:16位
  • 多边形:1021(实际上是 x^16 + x^12 + x^5 + 1)
  • 初始化:0000
  • 反射输入字节:假
  • 反射输出 CRC:假
  • 输出 CRC 的异或常数:0000
  • “123456789”的输出:31C3

使用了 14 个 CRC16 输出位中的 16 个(这就是为什么有 上式中的模 16384 运算)。

在我们的测试中,CRC16在分配不同种类的 键均匀地跨 16384 插槽。

注意:本文档的附录A中提供了所用CRC16算法的参考实现。

2、群集节点属性

集群中的每个节点都有一个唯一的名称。节点名是一个160位随机数的十六进制表示,在节点首次启动时获得(通常使用/dev/urandom)。节点将将其ID保存在节点配置文件中,并将永远使用相同的ID,或者至少在系统管理员未删除节点配置文件,或者通过CLUSTER reset命令请求硬重置的情况下使用相同ID。

节点 ID 用于标识整个群集中的每个节点。 给定节点无需任何需要即可更改其 IP 地址 以同时更改节点 ID。群集还能够检测到更改 在 IP/端口中,并使用在集群上运行的 gossip 协议重新配置 总线。

节点 ID 不是与每个节点关联的唯一信息,而是 唯一始终全局一致的。每个节点还具有 以下一组关联的信息。一些信息是关于 此特定节点的群集配置详细信息,并最终 在整个集群中保持一致。其他一些信息,例如上次 一个节点被 ping 到,而是每个节点的本地节点。

每个节点都维护关于它在集群中知道的其他节点的以下信息:节点ID、节点的IP和端口、一组标志、如果节点被标记为副本,则节点的主节点是什么、上次ping节点的时间和上次接收到pong的时间、节点的当前配置时期(本规范稍后解释)、,链接状态以及最后服务的哈希槽集。

CLUSTER NODES 命令可以发送到群集中的任何节点,并根据查询节点具有的群集本地视图提供群集的状态和每个节点的信息。

以下是发送到主服务器的群集节点命令的示例输出 节点在包含三个节点的小集群中。

$ redis-cli cluster nodes
d1861060fe6a534d42d8a19aeb36600e18785e04 127.0.0.1:6379 myself - 0 1318428930 1 connected 0-1364
3886e65cc906bfd9b1f7e7bde468726a052d1dae 127.0.0.1:6380 master - 1318428930 1318428931 2 connected 1365-2729
d289c575dcbc4bdd2931585fd4339089e461a27d 127.0.0.1:6381 master - 1318428931 1318428931 3 connected 2730-4095

在上面的列表中,不同的字段按顺序排列:节点ID,地址:端口,标志,上次发送的ping,收到的最后一个pong,配置纪元,链路状态,插槽。有关上述字段的详细信息将在我们讨论 Redis 集群的特定部分时立即介绍。

3、群集总线

每个 Redis 集群节点都有一个额外的 TCP 端口用于接收 来自其他 Redis 集群节点的传入连接。此端口将通过向数据端口添加 10000 来派生,也可以使用群集端口配置指定。

示例 1:

如果 Redis 节点正在侦听端口 6379 上的客户端连接, 并且您没有在 redis.conf 中添加集群端口参数, 将打开群集总线端口 16379。

示例 2:

如果 Redis 节点正在侦听端口 6379 上的客户端连接, 并在 redis.conf 中设置集群端口 20000, 将打开群集总线端口 20000。

节点到节点的通信只使用集群总线和集群总线协议:一种由不同类型和大小的帧组成的二进制协议。群集总线二进制协议没有公开记录,因为外部软件设备不打算使用该协议与Redis群集节点进行通信。但是,您可以通过阅读Redis Cluster源代码中的Cluster.h和Cluster.c文件来获得有关Cluster总线协议的更多详细信息。

4、群集拓扑

Redis 集群是一个完整的网格,其中每个节点都使用 TCP 连接与其他节点连接。

在由 N 个节点组成的群集中,每个节点都有 N-1 个传出 TCP 连接和 N-1 个传入连接。

这些 TCP 连接始终保持活动状态,而不是按需创建。 当节点期望 pong 回复以响应集群总线中的 ping 时,在等待足够长的时间以将节点标记为无法访问之前,它将尝试 通过从头开始重新连接来刷新与节点的连接。

虽然 Redis 集群节点形成一个完整的网格,但节点使用 gossip 协议和 配置更新机制,以避免交换太多 正常情况下节点之间的消息,所以消息的数量 交换不是指数级的。

5、节点握手

节点始终接受集群总线端口上的连接,甚至回复 收到时 ping,即使 ping 节点不受信任。 但是,如果 发送节点不被视为群集的一部分。

一个节点将仅以两种方式接受另一个节点作为群集的一部分:

  • 如果节点向自己显示一条MEET消息(CLUSTER MEET命令)。meet消息与PING消息完全相同,但会强制接收方接受节点作为集群的一部分。只有当系统管理员通过以下命令请求时,节点才会向其他节点发送MEET消息:CLUSTER MEET ip port
  • 如果一个已经受信任的节点会八卦另一个节点,那么该节点也会将另一个结点注册为集群的一部分。因此,如果A知道B,B知道C,最终B会向A发送关于C的八卦消息。当这种情况发生时,A会将C注册为网络的一部分,并尝试与C连接。

这意味着只要我们加入任何连接的图中的节点,它们最终将自动形成一个完全连接的图。这意味着群集能够自动发现其他节点,但前提是存在系统管理员强制的受信任关系。

此机制使集群更加健壮,但可防止不同的 Redis 集群在更改 IP 地址或其他网络相关事件后意外混合。

四、重定向和重新分片

1、移动重定向

Redis客户端可以免费向集群中的每个节点发送查询,包括副本节点。节点将分析查询,如果它是可接受的(即,查询中只提到一个密钥,或者提到的多个密钥都属于同一个哈希槽),它将查找哪个节点负责密钥所属的哈希槽。

如果哈希槽由节点提供服务,则简单地处理查询,否则节点将检查其内部哈希槽到节点的映射,并用MOVED错误回复客户端,如以下示例所示:

GET x
-MOVED 3999 127.0.0.1:6381

错误包括密钥的哈希槽(3999)和可以为查询服务的实例的endpoint:port。客户端需要向指定节点的端点地址和端口重新发出查询。端点可以是IP地址、主机名,也可以是空的(例如-MOVED 3999:6380)。空端点表示服务器节点具有未知端点,客户端应将下一个请求发送到与当前请求相同的端点,但具有提供的端口。

请注意,即使客户机在重新发出查询之前等待了很长时间,同时集群配置发生了变化,如果哈希槽3999现在由另一个节点提供服务,则目标节点将再次回复MOVED错误。如果联系的节点没有更新的信息,也会发生同样的情况。

因此,从集群节点由ID标识的角度来看,我们试图简化与客户机的接口,只需暴露哈希槽和由端点:端口对标识的Redis节点之间的映射。

客户端不需要,但应该尝试记住哈希槽3999由127.0.0.1:6381提供。这样,一旦需要发出新命令,它就可以计算目标密钥的哈希槽,并有更大的机会选择正确的节点。

另一种方法是在收到MOVED重定向时,使用cluster SHARDS或不推荐使用的cluster SLOTS命令刷新整个客户端集群布局。当遇到重定向时,很可能重新配置了多个插槽,而不是一个插槽,因此尽快更新客户端配置通常是最佳策略。

注意,当集群稳定时(配置中没有持续变化),最终所有客户端都将获得哈希槽->节点

五、创建和使用 Redis 集群

1、创建 Redis 集群的要求

要创建集群,首先需要在集群模式下运行几个空的Redis实例。

至少在redis.conf文件中设置以下指令:

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

要启用集群模式,请将集群启用指令设置为yes。每个实例还包含存储此节点配置的文件的路径,默认为nodes.conf;它只是由Redis群集实例在启动时生成,并在每次需要时更新。

注意,按预期工作的最小集群必须至少包含三个主节点。对于部署,我们强烈建议使用具有三个主节点和三个副本的六节点集群。

您可以在本地测试,方法是创建以下目录,这些目录以将在任何给定目录中运行的实例的端口号命名。

例如:

mkdir cluster-test
cd cluster-test
mkdir 7000 7001 7002 7003 7004 7005

在7000到7005的每个目录中创建redis.conf文件。作为配置文件的模板,只需使用上面的小示例,但请确保根据目录名将端口号7000替换为正确的端口号。

您可以按如下方式启动每个实例,每个实例都在单独的终端选项卡中运行:

cd 7000
redis-server ./redis.conf

您将从日志中看到每个节点都为自己分配了一个新 ID:

[82462] 26 Nov 11:56:55.329 * No cluster configuration found, I'm 97a3a64667477371c4479320d683e4c8db5858b1

此 ID 将永远由此特定实例使用,以便为实例使用 在群集的上下文中具有唯一的名称。每个节点 使用此 ID 记住所有其他节点,而不是按 IP 或端口。 IP 地址和端口可能会更改,但唯一节点标识符永远不会更改 在节点的整个生命周期内进行更改。我们简称此标识符为节点 ID

2、创建 Redis 集群

现在我们已经运行了许多实例,您需要通过向节点写入一些有意义的配置来创建集群。

您可以手动配置和执行单个实例,也可以使用创建集群脚本。 让我们回顾一下如何手动执行此操作。

要创建群集,请运行:

redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 \
127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
--cluster-replicas 1

这里使用的命令是create,因为我们想要创建一个新集群。选项--cluster replica 1意味着我们希望为创建的每个主机创建一个副本。

其他参数是要用于创建新集群的实例的地址列表。

redis-cli将提出一种配置。键入yes接受建议的配置。集群将被配置和加入,这意味着实例将被引导到彼此之间的对话中。最后,如果一切顺利,您将看到这样的消息:

[OK] All 16384 slots covered

这意味着至少有一个主实例服务于16384个可用时隙中的每一个。

如果您不想通过如上所述手动配置和执行单个实例来创建Redis集群,那么有一个简单得多的系统(但您不会学到相同数量的操作细节)。

在Redis发行版中找到utils/create集群目录。内部有一个名为createcluster的脚本(与包含该脚本的目录同名),这是一个简单的bash脚本。要启动具有3个主节点和3个副本的6节点群集,只需键入以下命令:

create-cluster start
create-cluster create

当redis-cli实用程序希望您接受集群布局时,在步骤2中回答yes。

您现在可以与集群交互,默认情况下,第一个节点将从端口30001开始。完成后,使用以下命令停止群集:

create-cluster stop

3、添加新节点

添加新节点基本上是添加一个空节点的过程,然后 将一些数据移入其中,以防它是新的主数据,或者告诉它 设置为已知节点的副本(如果它是副本)。

我们将同时展示两者,从添加新的主实例开始。

在这两种情况下,要执行的第一步都是添加一个空节点

这就像在端口 7006 中启动一个新节点一样简单(我们已经使用 对于我们现有的 7000 个节点,从 7005 到 6)具有相同的配置 用于其他节点,除了端口号,所以你应该做什么 为了符合我们用于先前节点的设置,请执行以下操作:

  • 在终端应用程序中创建新选项卡。
  • 输入群集测试目录。
  • 创建名为7006的目录。
  • 在内部创建redis.conf文件,与其他节点使用的文件类似,但使用7006作为端口号。
  • 最后用..启动服务器/redis服务器/redis.conf文件

此时,服务器应该正在运行。

现在我们可以像往常一样使用 redis-cli 来将节点添加到 现有群集。

redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000

如您所见,我使用了 add-node 命令指定 新节点作为第一个参数,以及 聚类作为第二个参数。

实际上,这里的redis-cli对我们帮助很小,它只是 向节点发送了 CLUSTER MEET 消息,这也是可能的 以手动完成。但是,redis-cli 也会检查 集群之前运行,所以最好先执行集群操作 始终通过 Redis-CLI 即使您知道内部结构的工作原理。

现在我们可以连接到新节点,看看它是否真的加入了集群:

redis 127.0.0.1:7006> cluster nodes
3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385543178575 0 connected 5960-10921
3fc783611028b1707fd65345e763befb36454d73 127.0.0.1:7004 slave 3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 0 1385543179583 0 connected
f093c80dde814da99c5cf72a7dd01590792b783b :0 myself,master - 0 0 0 connected
2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385543178072 3 connected
a211e242fc6b22a9427fed61285e85892fa04e08 127.0.0.1:7003 slave 97a3a64667477371c4479320d683e4c8db5858b1 0 1385543178575 0 connected
97a3a64667477371c4479320d683e4c8db5858b1 127.0.0.1:7000 master - 0 1385543179080 0 connected 0-5959 10922-11422
3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7005 master - 0 1385543177568 3 connected 11423-16383

4、添加新节点作为副本

可以通过两种方式添加新复制副本。显而易见的是 再次使用 Redis-cli,但使用 --cluster-slave 选项,如下所示:

redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000 --cluster-slave

5、删除节点

要删除副本节点,只需使用redis-cli的del node命令:

redis-cli --cluster del-node 127.0.0.1:7000 `<node-id>`

第一个参数只是集群中的一个随机节点,第二个参数 是要删除的节点的 ID。

您也可以以相同的方式删除主节点,但是为了 删除主节点,它必须为空。如果主节点不为空,则需要 将数据从它重新分片到之前的所有其他主节点。


相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
8天前
|
缓存 NoSQL Apache
【Redis】布隆过滤器原理与应用
【Redis】布隆过滤器原理与应用
20 1
|
8天前
|
存储 缓存 NoSQL
蚂蚁金服P7私藏的Redis原理与实践内部笔记
Redis 是完全开源免费的,是一个高性能的key-value类型的内存数据库。整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过 10万次读写操作,是已知性能最快的Key-Value DB。
63 1
|
8天前
|
存储 缓存 Java
【Spring原理高级进阶】有Redis为啥不用?深入剖析 Spring Cache:缓存的工作原理、缓存注解的使用方法与最佳实践
【Spring原理高级进阶】有Redis为啥不用?深入剖析 Spring Cache:缓存的工作原理、缓存注解的使用方法与最佳实践
|
5天前
|
存储 缓存 NoSQL
由菜鸟到大神,谈谈redis的概念、实战、原理、高级使用方法
【5月更文挑战第18天】Redis是一个开源的内存中的数据结构存储系统,它可以用作数据库、缓存和消息中间件。它支持多种类型的数据结构,如字符串、哈希、列表、集合、有序集合等。
22 10
|
8天前
|
负载均衡 NoSQL 关系型数据库
深入浅出Redis(六):Redis的主从架构与主从复制原理
深入浅出Redis(六):Redis的主从架构与主从复制原理
|
8天前
|
监控 NoSQL 算法
深入剖析Redis哨兵模式的原理和应用
Redis的哨兵模式是实现高可用性和自动故障转移的机制,当主服务器故障时,哨兵能自动检测并进行故障转移,确保服务连续和稳定性。哨兵模式通过监控主从服务器状态、自动故障转移、防止数据不一致,提高容错能力和负载均衡,降低运维成本,实现高可用性。哨兵通过检测主观下线和客观下线状态,以及选举Leader Sentinel来协调故障转移。Raft算法在其中用于领导者选举和状态一致性。哨兵模式通过综合考虑多种因素选举新主服务器并执行故障转移,保障集群稳定运行。
100 0
深入剖析Redis哨兵模式的原理和应用
|
8天前
|
NoSQL Redis
Redis入门到通关之Redis主从数据同步原理
Redis入门到通关之Redis主从数据同步原理
31 0
|
8天前
|
存储 NoSQL Redis
Redis入门到通关之Redission原理
Redis入门到通关之Redission原理
25 0
|
8天前
|
缓存 NoSQL 算法
【redis】布隆过滤器(Bloom Filter)原理解析与应用
【redis】布隆过滤器(Bloom Filter)原理解析与应用
26 1
|
8天前
|
运维 监控 NoSQL