Redis哨兵与群集

Question

我知道redis sentinel是一种在多个redis实例中配置HA(高可用性)的方法.正如我所看到的,在任何给定时间都有一个redis实例主动为客户端请求提供服务.有两个额外的服务器处于待机状态(等待故障发生,因此其中一个可以再次运行).

• 浪费资源吗？
• 有没有更好的方法来充分利用可用资源？
• Redis是否会成为Redis哨兵的替代品？

我已经查找了redis文档的sentinel和clustering,请有经验的人解释一下.

UPDATE

好.在我的实际部署方案中,我有两台专用于redis的服务器.我有另一台服务器,我的Jboss服务器正在运行.在Jboss中运行的应用程序配置为连接到redis主服务器(M).

故障转移方案

理想情况下,我认为当主缓存服务器出现故障(Redis进程出现故障或计算机出现故障)时,Jboss中的应用程序需要连接到Slave缓存服务器.我如何配置redis服务器来实现这一目标？

+--------+          +--------+
| Master  |---------| Slave  |
|         |         |        |
+--------+          +--------+

Configuration: quorum = 1

Answer 1

首先,让我们谈谈哨兵.

Sentinel管理故障转移,它不为HA配置Redis.这是一个重要的区别.其次,您发布的图表实际上是一个错误的设置 - 您不希望在与其管理的Redis节点相同的节点上运行Sentinel.当你失去那个主人时,你会失去两者.

至于"浪费资源吗？" 这取决于你的用例.在该设置中不需要三个Redis节点,只需要两个.三增加了冗余,但不是必需的.如果您需要增加冗余,那么这不是浪费资源.如果您不需要冗余,那么您只需运行一个Redis实例并将其称为好 - 因为运行更多将被"浪费".

运行两个奴隶的另一个原因是拆分读取.再说一次,如果你需要它,那就不会浪费.

至于"有更好的方法可以充分利用现有的资源吗？" 我们无法回答这个问题,因为它过于依赖于您的特定场景和代码.也就是说,如果要存储的数据量"很小"且命令率不是很高,那么请记住,您不需要将主机专用于Redis.

现在为"Redis集群替代Redis哨兵？".这完全取决于您的用例.Redis Cluster不是HA解决方案 - 它是一个多作者/大于ram的解决方案.如果你的目标只是HA,那么它可能不适合你.Redis Cluster有一些限制,特别是在多键操作方面,因此它不一定是简单的"只使用集群"操作.

如果您认为有三台运行Redis的主机(以及三台运行的Sentinel)是浪费的,那么您可能会让Cluster更加紧张,因为它需要更多资源.

你提出的问题可能过于广泛而且基于意见而无法按照书面形式生存.如果您遇到特定的案例/问题,请更新,以便我们提供具体的帮助和信息.

具体更新:

为了在您的场景中进行适当的故障转移管理,我将使用3个标记,一个在JBoss服务器上运行.如果你有3个JBoss节点,那么每个节点都有一个.我在单独的节点上有一个Redis pod(主机+从机),让sentinel管理故障转移.

从那里开始,JBoss/Jedis需要使用Sentinel进行信息和连接管理.由于我没有使用那些快速搜索,Jedis支持它,你只需要正确配置它.我找到的一些例子是在寻找一个带有Sentinel的Jedis和https://github.com/xetorthio/jedis/issues/725 的例子,它们谈到JedisSentinelPool了使用池的路线.

当Sentinel执行故障转移时,客户端将断开连接,Jedis将(应该？)通过向Sentinels询问当前主服务器来处理重新连接.

Answer 2

无处不在的建议是从奇数个实例开始,而不是使用两个或两个的倍数.这已得到纠正,但让我们纠正其他一些观点.

首先,说Sentinel提供没有HA的故障转移是错误的.当您进行故障转移时,您可以使用HA来复制应用程序状态.区别在于您可以在没有复制的系统中使用HA(它是HA,但它不是容错的).

其次,在与其目标redis实例相同的机器上运行标记不是"错误设置":如果丢失了您的标记,redis实例或整个机器,结果是相同的.这可能就是为什么这些配置的每个示例都显示在同一台机器上运行的原因.

Answer 3

这不是你问题的直接答案,但是想想,这对我这样的Redis新手来说是有用的信息.此问题也是谷歌搜索"Redis群集与哨兵"时的第一个链接.

Redis Sentinel是Redis高可用性解决方案的名称......它与Redis Cluster无关,旨在供不需要Redis群集的人使用,但只是一种在主服务器上执行自动故障转移的方法实例无法正常运行.

取自Redis Sentinel设计草案1.3

当您不熟悉Redis并实施故障转移解决方案时,这并不是一件容易的事.关于哨兵和聚类的官方文件并没有相互比较,因此如果不阅读大量的文件,就很难选择正确的方法.

Answer 4

以上答案的附加信息

Redis 集群

• Redis 集群的一个主要目的是通过分片来平均/均匀地分配您的数据负载

• Redis Cluster 不使用一致性哈希，而是使用不同形式的分片，其中每个键在概念上都是所谓的哈希槽的一部分

• Redis 集群中有 16384 个哈希槽，Redis 集群中的每个节点都负责哈希槽的一个子集，因此，例如，您可能有一个具有 3 个节点的集群，其中：

  节点 A 包含从 0 到 5500 的哈希槽，节点 B 包含从 5501 到 11000 的哈希槽，节点 C 包含从 11001 到 16383 的哈希槽

这使我们可以轻松地在集群中添加和删除节点。例如，如果我们要添加一个新节点 D，我们需要将一些哈希槽从节点 A、B、C 移动到 D

• Redis集群支持主从结构，创建集群时可以创建从A1、B1、C2和主A、B、C一起创建，这样当主B宕机时，从B1提升为主

使用 Redis 集群时，您不需要额外的故障转移处理，并且绝对不应将 Sentinel 实例指向任何集群节点。

那么在实践中，您从 Redis Cluster 中得到了什么？

1.能够在多个节点之间自动拆分数据集。

2.当部分节点出现故障或无法与集群的其余部分通信时继续操作的能力。

Redis哨兵

• Redis 支持多个从节点从一个主节点复制数据。
• 这为主节点中的数据提供了备份。
• Redis Sentinel 是一个旨在管理 master 和 slave 的系统。它作为单独的程序运行。理想系统中所需的最小哨兵数量是 3。它们之间进行通信并确保 Master 活着，如果没有活着，他们将提升其中一个奴隶为 master，所以稍后当死节点旋转时它会充当新主人的奴隶
• 法定人数是可配置的。基本上它是在主节点宕机时需要同意的哨兵数量。N/2 +1应该同意。N 是 Pod 中的节点数（注意这个设置叫做 Pod 而不是集群）

那么实际上，您从 Redis Sentinel 中得到了什么？

它将确保 Master 始终可用（如果 master 宕机，slave 将被提升为 master）

参考 ：

https://fnordig.de/2015/06/01/redis-sentinel-and-redis-cluster/

https://redis.io/topics/cluster-tutorial

Answer 5

这是我理解文档后的理解。

Sentinel是一种热备用解决方案，在该解决方案中，从站保持复制状态，随时可以进行升级。但是，它将不支持任何多节点写入。可以配置从站进行读取操作。Sentinel不会提供HA是不正确的，它具有典型的主动-被动群集的所有功能（尽管在此处不适合使用术语）。

Redis集群或多或少是一个基于碎片的分布式解决方案。每个数据块都分布在主节点和从节点之间。最小复制因子2确保您在主服务器和从服务器上有两个可用的活动碎片。如果您知道Mongo或Elasticsearch中的分片，将很容易赶上。

Answer 6

Redis可以在分区群集（具有许多主服务器和这些主服务器的从服务器）或单个实例模式（具有副本从服务器的单个主服务器）中运行。这里
的链接说：

在单实例模式下使用Redis时，其中一个Redis服务器管理整个未分区的数据库，Redis Sentinel用于管理其可用性

它还说：

Redis群集中的数据在多个主实例之间进行分区，该Redis群集本身可以管理可用性，不需要任何额外的组件。

因此，可以在上述两种情况下确保HA。希望这能消除疑虑。Redis集群和前哨不可替代。它们仅用于确保在分区或未分区的主服务器的不同情况下具有高可用性。

Answer 7

当 Redis Sentinel 看到主节点关闭时，它们会执行故障转移提升副本。您通常需要奇数个哨兵节点。以一主一副本为例，应使用 3 个哨兵，以便对决策达成共识。理想情况下，第三个哨兵位于第三个服务器上，因此决策不会有偏差（取决于失败）。Sentinel 负责更改节点上的主/副本配置设置，以便升级和同步以正确的顺序发生，并且您不会通过引入现在包含旧数据的旧故障主来覆盖数据。

一旦您将哨兵节点设置为执行故障转移，您需要确保指向正确的实例。请参阅HAProxy 配置示例。HAProxy 执行健康检查，并在发生故障时指向新的 master。

集群将允许您水平扩展并有助于处理高负载。预先设置和配置确实需要一些工作。

Redis 有一个开源分支“KeyDB”，它消除了对带有主动副本选项的哨兵节点的需求。这允许副本节点接受读取和写入。当发生故障转移时，HAProxy 会停止对故障节点的读/写操作，并仅使用已同步的剩余活动节点。时间戳使故障节点能够自动重新加入并重新同步，而不会在它们重新联机时丢失数据。设置很简单，对于更高的流量，您不需要特殊的前期设置来将读取定向到副本节点并将读/写定向到主节点。请参阅此处的主动复制示例。KeyDB 也是多线程的，对于某些应用程序，它可能是集群的替代方案，但实际上取决于您的需求。

还有一个手动和使用create-cluster 工具设置集群的示例。如果您使用的是 Redis，这些步骤是相同的​​（在指令中将 'keydb' 替换为 'redis'）