Redis哨兵和主/从服务器在同一台服务器上吗？

Question

Redis哨兵和主/从服务器在同一台服务器上吗？

9

我一直在阅读有关如何使用Redis Sentinel的文章，我知道可以有两个或更多的Sentinel，并且在从客户端调用时在它们之间进行负载平衡。但是，将这两个Sentinel放在与我的主服务器和从服务器相同的服务器上是否是好的做法？换句话说，将一个Sentinel放在与主服务器相同的物理服务器上，将另一个Sentinel放在与从服务器相同的物理服务器上？

对我来说，如果主服务器死亡，从服务器中的Sentinel将简单地将从服务器晋升为主服务器。如果从服务器死亡，则无论如何都没关系，因为主服务器仍然存在。

我是否遗漏了什么？有哪些缺点？

为了减少延迟，我更喜欢让Sentinel与主/从服务器位于同一物理服务器上。

- Henley

1

我该如何单独运行Sentinel？@henley - AATHITH RAJENDRAN

4个回答

7

这完全取决于您想要实现的灾难恢复级别，假设您拥有以下组件（无论它们托管在哪里）：

2个Sentinel

1个Master 1个Slave 1个主服务器 1个以上从服务器

一个主机方案

主机故障：您将失去一切，对于大多数用例而言是糟糕的复制方案。

两个主机方案

主机1：

（当前当选的）主服务器

1个Sentinel

主机2：

从服务器

1个Sentinel

在这种情况下，您可以将主机一个接一个地故障，这为您提供了一定程度的安全性。只需尝试了解不同服务器是否指物理上不同的主机。如果这些只是在同一主机上的虚拟机，则无法获得相同级别的DR（灾难恢复）。

关于您的问题：

请注意，哨兵会跟踪当前的主服务器和从服务器，但Redis客户端不会通过哨兵连接到主服务器，而是通过哨兵获取当前主服务器的位置。例如，在读写方面，您不需要考虑任何显著的延迟增加。

配置提供者。哨兵作为客户端服务发现的权威来源：客户端连接到哨兵以请求给定服务的当前Redis主服务器的地址。如果发生故障转移，哨兵将报告新地址。

（参见：http://redis.io/topics/sentinel）

在我看来，仅在主服务器和从服务器向哨兵发送心跳时才会有延迟优势。只要您不将服务器分散在整个世界范围内，那就应该没问题。

这完全取决于用例，但如果其他所有因素相等（成本、与客户端的距离等），似乎最好尽可能保持分离。

- bitoiu

每次读取/写入操作之前，Redis客户端需要先从Sentinel获取地址才能执行读取/写入操作，对吗？ - Henley

不是每次读/写都会发生，那样会很糟糕。当主服务器宕机并选出新的主服务器时，客户端会收到通知。请阅读原始文档中引用的段落：“如果发生故障转移，Sentinels 将报告新地址。” - bitoiu

我怎样才能单独运行Sentinel？@bitoiu - AATHITH RAJENDRAN

2

您可以在主/从机上拥有哨兵，但是哨兵的数量必须为奇数（3/5/7）。至少需要三个哨兵，并且至少需要一个专用机器来运行哨兵。

如果您只有两个节点，则在出现分裂脑（网络中断）情况下，从服务器将被提升为主服务器。现在，两个主服务器都将接受客户端数据。然而，当一切恢复正常时，其中一个主服务器将被降级为从服务器。该主服务器将失去所有数据，因为它现在是从服务器，并将从当前主服务器复制数据。

请查看此处以了解Redis架构设计和分裂脑的详细说明： https://web.archive.org/web/20170527053749/http://www.yzuzun.com/2015/04/some-architectural-design-concepts-for-redis/

- greenlantern

链接已损坏。 - Nitin Gaur

我该如何单独运行Sentinel？@greenlantern - AATHITH RAJENDRAN

0

这绝对不是一个推荐的方法。

Redis Sentinel文档很好地解释了权衡。希望这可以帮到你。 https://redis.io/topics/sentinel#example-sentinel-deployments

- davissp14

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- The Real Bill · Accepted Answer

首先，Sentinel不是Redis的负载均衡器或代理。

其次，并非所有故障都会导致主机死机。有时服务器会短暂挂起，有时网络电缆会被拔掉等。因此，在同一主机上运行Redis实例和Sentinel并不是一个好的实践。如果您正在使用Sentinel来管理故障转移，则除Redis主节点和从节点之外的其他节点上至少需要运行三个哨兵。

Sentinel使用仲裁机制对故障转移和从属进行投票。如果少于两个Sentinel，则存在分裂大脑的风险，即两个或多个Redis服务器认为它们是主服务器。

假设您运行两个服务器并在每台服务器上运行sentinel。如果您失去了一个服务器，则丢失了可靠的故障转移功能。

客户端仅连接到Sentinel以获取当前主连接信息。每当客户端失去连接性时，它们会重复此过程。Sentinel不是Redis的代理——Redis的命令直接发送到Redis中。

少于三个哨兵运行Sentinel的唯一可靠原因是用于服务发现，这意味着不将其用于故障转移管理。

考虑两个主机的情况：

Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2  (Quorum 1)

如果在这种情况下，主机B暂时失去与主机A的网络连接，那么主机B将会晋升为主服务器。现在你有：

Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2  (Quorum 1)

连接到Sentinel 2的任何客户端都会被告知Host B是主节点，而连接到Sentinel 1的客户端将被告知Host A是主节点（如果您将Sentinels置于负载均衡器后，则表示一半的客户端）。

因此，为了获得最小可接受的可靠故障转移管理，您需要运行：

Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2

您的客户端连接到哨兵并获取Redis实例（按名称）的当前主服务器，然后连接到它。如果主服务器挂了，则客户端应该断开连接，然后再次连接到哨兵并获取新信息。

每个客户端库处理这种情况的能力取决于该库的特性。

理想情况下，主机C、D和E要么位于从Redis连接的同一主机上（即客户端主机），要么代表对它们进行良好抽样的主机。这里的主要推动力是确保您从需要连接到Redis的位置进行检查。如果无法实现这一点，请将它们放置在与客户端相同的数据中心/机架/区域。

如果您希望客户端与负载均衡器通信，请尽可能在这些LB节点上放置哨兵，并根据需要添加其他非LB主机以获取大于2个奇数哨兵。唯一的例外是如果您的客户端主机是动态的，例如它们根据流量进行扩展或缩小。在这种情况下，您必须在非客户端和非Redis服务器主机上运行哨兵。

请注意，如果您这样做，则需要编写一个守护程序，用于监视哨兵PUBSUB通道以更新LB的主切换事件，并配置它仅与当前主服务器通信（永远不要尝试与两者通信）。这需要更多的工作，但确实使客户端透明地使用哨兵-客户端只需知道与LB IP / Port通信即可。