Redis哨兵vs集群

我了解Redis前哨是一种在多个Redis实例之间配置HA（高可用性）的方法。如我所见，有一个Redis实例在任何给定时间主动服务于客户端请求。还有两个其他服务器处于待机状态（等待发生故障，因此其中一个可以再次运行）。

• 是浪费资源吗？
• 有没有更好的方法来充分利用可用资源？
• Redis集群是否可以替代Redis哨兵？

我已经查看了redis文档以进行标记和集群，有经验的人可以请解释一下。

更新

好。在我的实际部署方案中，我有两台专用于Redis的服务器。我的Jboss服务器正在运行另一台服务器。在Jboss中运行的应用程序被配置为连接到Redis主服务器（M）。

故障转移方案

理想情况下，我认为当主缓存服务器发生故障（Redis进程出现故障或计算机出现故障）时，Jboss中的应用程序需要连接到从属缓存服务器。我将如何配置Redis服务器来实现这一目标？

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

Configuration: quorum = 1

首先，让我们谈谈哨兵。

Sentinel管理故障转移，它不会为HA配置Redis。这是一个重要的区别。其次，您发布的图实际上是一个错误的设置-您不想在与其管理的Redis节点相同的节点上运行Sentinel。当您失去该主机时，您将同时失去这两个主机。

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

运行两个从站的另一个原因是拆分读取。同样，如果您需要它，那将不是浪费。

关于“是否有更好的方法来充分利用可用资源？” 我们无法回答，因为它太依赖于您的特定方案和代码。也就是说，如果要存储的数据量“很小”并且命令速率不是很高，那么请记住您不需要将主机专用于Redis。

现在针对“ Redis是否在集群中替代Redis哨兵？”。这实际上完全取决于您的用例。Redis Cluster不是高可用性解决方案-它是一个多编写器/大于内存的解决方案。如果您的目标只是HA，那么它可能不适合您。Redis Cluster具有局限性，尤其是在多键操作方面，因此不一定是简单的“ just use cluster”操作。

如果您认为让三台主机运行Redis（和三台运行哨兵）是浪费的，那么您可能会使Cluster变得更多，因为它确实需要更多资源。

您所提出的问题可能太笼统，无法根据书面意见生存。如果您有特定的案例/问题正在解决，请进行更新，以便我们提供特定的帮助和信息。

具体更新：

为了在您的场景中进行正确的故障转移管理，我将使用3个哨兵，其中一个在您的JBoss服务器上运行。如果您有3个JBoss节点，则每个节点一个。我将在单独的节点上有一个Redis Pod（主节点+从节点），然后让哨兵来管理故障转移。

从那里开始，连接JBoss / Jedis即可使用Sentinel进行信息和连接管理。由于我没有使用那些快速搜索功能，因此Jedis支持它，因此您只需要正确配置它即可。我发现的一些示例是在《使用Sentinel查找Jedis的示例》和https://github.com/xetorthio/jedis/issues/725中，它们讨论JedisSentinelPool了使用池的途径。

当Sentinel执行故障转移时，客户端将断开连接，Jedis将（应该？）通过询问Sentinels当前主服务器是谁来处理重新连接。

在任何地方，建议都是从奇数个实例开始，而不要使用两个或两个的倍数。这已得到纠正，但让我们纠正其他一些问题。

首先，说Sentinel提供故障转移而没有HA是错误的。进行故障转移时，您将拥有HA，并且具有复制应用程序状态的其他好处。区别在于您可以在没有复制的系统中拥有HA（这是HA，但它不是容错的）。

其次，在与目标Redis实例相同的机器上运行哨兵不是“错误的设置”：如果丢失哨兵，Redis实例或整个机器，结果是相同的。这可能就是为什么这种配置的每个示例都显示两者都在同一台计算机上运行的原因。

这不是您问题的直接答案，但是，它对像我这样的Redis新手来说是有用的信息。此外，当搜索“ Redis群集与哨兵”时，该问题也显示为Google中的第一个链接。

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

取自Redis Sentinel设计草案1.3

当您不熟悉Redis并实施故障转移解决方案时，这并不难。关于哨兵和聚类的官方文档无法相互比较，因此，在不阅读大量文档的情况下很难选择正确的方法。

这是我在整个文档中全力以赴之后的理解。

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

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

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

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

它还说：

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

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

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

一旦设置好哨兵节点以执行故障转移，就需要确保指向正确的实例。请参见HAProxy配置示例。HAProxy执行运行状况检查，如果发生故障，它将指向新的主服务器。

群集将使您可以水平扩展，并可以帮助处理高负载。预先设置和配置确实需要一些工作。

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

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

以上答案的其他信息

Redis集群

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

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

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

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

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

• Redis集群支持主从结构，在创建集群时可以与主A，B，C一起创建从A1，B1，C2，因此当主B发生故障时，从B1被提升为主

使用Redis Cluster时，不需要其他故障转移处理，并且绝对不应将Sentinel实例指向任何Cluster节点。

因此，实际上，Redis Cluster能带来什么？

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

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

Redis前哨

• Redis支持多个从节点从主节点复制数据。
• 这为主节点中的数据提供了备份。
• Redis Sentinel是一个用于管理主服务器和从服务器的系统。它作为单独的程序运行。在理想系统中，最少需要有3个哨兵。它们之间相互通信，并确保主节点处于活动状态，如果不存在，它们将提升一个从节点中的一个作为主节点，因此稍后死节点旋转时，它将成为主节点。充当新主人的奴隶
• 法定人数是可配置的。基本上，当主服务器宕机时，需要达成共识的哨兵数量。N / 2 +1应该同意。N是Pod中的节点数（请注意，此设置称为Pod，而不是集群）

因此，实际上，Redis Sentinel带来什么？

这将确保主服务器始终可用（如果主服务器出现故障，则从服务器将被提升为主服务器）

参考：

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

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