我知道redis哨兵是在多个redis示例中配置HA(高可用性)的一种方式。正如我所看到的，在任何给定的时间，都有一个Redis示例主动地服务于客户端请求。还有两台服务器处于备用状态(等待故障发生，因此其中一台可以再次运行)。
**是在浪费资源吗？
- 有没有更好的办法来充分利用现有资源？
- Redis集群是Redis哨兵的替代方案吗？
我已经查了sentinel和clustering的redis文档，有经验的人能解释一下吗？
更新
好的。在我的实际部署场景中，我有两台专门用于redis的服务器。我的JBoss服务器正在运行另一台服务器。在JBoss中运行的应用程序被配置为连接到redis主服务器(M)。
故障转移场景
理想情况下，我认为当主缓存服务器出现故障(Redis进程或机器故障)时，JBoss中的应用程序需要连接到Slave缓存服务器。我将如何配置Redis服务器来实现这一点？
+--------+ +--------+
| Master |---------| Slave |
| | | |
+--------+ +--------+
Configuration: quorum = 1
7条答案
按热度按时间gblwokeq1#
首先，让我们谈谈哨兵。
Sentinel管理故障转移，它不为HA配置Redis。这是一个重要的区别。其次，您发布的图表实际上是一个糟糕的设置--您不希望在与Sentinel管理的Redis节点相同的节点上运行Sentinel。当你失去了那个主人，你就失去了两者。
至于“是不是在浪费资源？”这取决于您的用例。在该设置中，您不需要三个Redis节点，只需要两个。三会增加您的冗余度，但不是必需的。如果您需要额外的冗余，那么这并不是浪费资源。如果您不需要冗余，那么您只需运行一个Redis示例就可以了--因为运行更多示例将是“浪费”的。
运行两个从属服务器的另一个原因是拆分读取。再说一次，如果你需要它，那么它就不会是一种浪费。
至于“有没有更好的办法来充分利用现有资源？”我们无法回答这个问题，因为它太依赖于您的特定场景和代码。也就是说，如果要存储的数据量“很小”，并且命令率不是非常高，那么请记住，您不需要为Redis指定主机。
现在是“Redis集群是不是Redis哨兵的替代品？”这完全取决于您的用例。Redis群集不是HA解决方案-它是一个多编写器/大于RAM的解决方案。如果你的目标仅仅是HA，那么它很可能不适合你。Redis集群具有局限性，特别是在多键操作方面，因此它不一定是直接的“只使用集群”操作。
如果您认为让三个主机运行Redis(和三个运行哨兵)是浪费的，那么您可能会认为集群更加浪费，因为它确实需要更多的资源。
你问的问题可能太过宽泛和基于观点，不能照本宣科。如果您有正在解决的特定案例/问题，请更新，以便我们提供具体的帮助和信息。
详细信息更新：
为了在您的场景中进行正确的故障转移管理，我建议使用3个哨兵，其中一个在您的JBoss服务器上运行。如果您有3个JBoss节点，那么每个节点上都有一个。我在单独的节点上有一个Redis pod(主+从)，并让Sentinel管理故障转移。
从那时起，只需将JBoss/Jedis连接起来，就可以使用Sentinel进行信息和连接管理。因为我不会使用那些快速搜索发现Jedis支持它，你只需要正确配置它。我找到的一些例子是Looking for an example of Jedis with Sentinel和https://github.com/xetorthio/jedis/issues/725，它们谈论
JedisSentinelPool是使用池的路由。当哨兵执行故障转移时，客户端会断开连接，而绝地会(应该吗？)通过询问哨兵们当前的主人是谁来处理重新连接。
oyjwcjzk2#
这并不是对你问题的直接回答，但想想，这对像我这样的Redis新手来说是很有帮助的信息。当搜索“Redis集群与哨兵”时，这个问题也会出现在谷歌的第一个链接中。
Redis Sentinel是Redis高可用性解决方案的名称...它与Redis集群无关，仅供不需要Redis集群的人使用，只是在主示例运行不正常时进行自动故障转移的一种方式。
取自Redis Sentinel design draft 1.3
如果您是Redis和实施故障转移解决方案的新手，这一点并不明显。关于sentinel和clustering的官方文献是不能相互比较的，所以不阅读大量的文献就很难选择正确的方式。
oxosxuxt3#
无论在哪里，建议从奇数个示例开始，而不是使用两个或两个的倍数。这一点得到了纠正，但让我们纠正一些其他观点。
首先，说哨兵在没有HA的情况下提供故障转移是错误的。当您进行故障切换时，您就拥有了HA，同时还具有复制应用程序状态的额外好处。区别在于，您可以在没有复制的系统中拥有HA(它是HA，但不能容错)。
其次，在与其目标Redis示例相同的机器上运行一个哨兵并不是一个“糟糕的设置”：如果您丢失了哨兵、Redis示例或整台机器，结果都是一样的。这可能就是为什么这类配置的每个示例都显示两者都在同一台机器上运行的原因。
iecba09b4#
上述答案的其他信息
Redis集群
节点A包含从0到5500的哈希槽，节点B包含从5501到11000的哈希槽，节点C包含从11001到16383的哈希槽
这使我们可以轻松地在群集中添加和删除节点。例如，如果我们想要添加一个新节点D，我们需要将一些散列槽从节点A、B、C移到D
当使用Redis集群时，您不需要额外的故障转移处理，并且您绝对不应该将Sentinel示例指向任何集群节点。
那么，从实际情况来看，您使用Redis集群得到了什么？
1.在多个节点之间自动拆分数据集的能力。
2.当节点的子集出现故障或无法与群集的其余部分通信时继续操作的能力。
雷迪斯哨兵
实际上，你从雷迪斯·哨兵那里得到了什么？
它将确保Master始终可用(如果Master宕机，则Slave将提升为Master)
参考资料：
https://fnordig.de/2015/06/01/redis-sentinel-and-redis-cluster/
https://redis.io/topics/cluster-tutorial
avwztpqn5#
这是我在整个文档中撞到头后的理解。
Sentinel是一种热备份解决方案，其中保持对从属的复制，并随时准备升级。但是，它不支持任何多节点写入。可以为读取操作配置从属设备。Sentinel不会提供HA并不是真的，它拥有典型的主动-被动集群的所有功能(尽管这不是这里使用的正确术语)。
Redis集群或多或少是一种分布式解决方案，工作在分片之上。每个数据块都分布在主节点和从节点之间。最小复制系数为2可确保您在主设备和从设备上有两个活动分片可用。如果你知道Mongo或Elasticearch中的分片，就很容易赶上。
lyr7nygr6#
Redis可以在分区集群(这些主机有多个主机和从主机)或单示例模式(单个主机和副本从主机)中运行。
此处的link表示：
在单示例模式下使用Redis时，单个Redis服务器管理整个未分区的数据库，Redis Sentinel用于管理其可用性
它还说：
Redis集群将数据分区到多个主示例中，它自己管理可用性，不需要额外的组件。
因此，在上述两个场景中都可以确保高可用性。希望这能消除人们的疑虑。红星星团和哨兵并不是相互替代的。它们只是用来确保在分区或非分区主服务器的不同情况下的高可用性。
pkln4tw67#
Redis Sentinel在看到主服务器关闭时执行故障转移以提升副本服务器。您通常需要奇数个前哨节点。对于一个主服务器和一个副本服务器的示例，应该使用3个哨兵，以便就决策达成共识。理想情况下，第三个前哨位于第三个服务器上，因此决策不会出现偏差(取决于故障)。Sentinel负责更改节点上的主/副本配置设置，以便以正确的顺序进行升级和同步，并且您不会通过引入现在包含较旧数据的旧的故障主服务器来覆盖数据。
设置前哨节点以执行故障转移后，您需要确保指向正确的示例。请参阅HAProxy configuration for this的示例。HAProxy执行运行状况检查，并在发生故障时指向新的主服务器。
集群将允许您水平扩展，并有助于处理高负载。预先设置和配置确实需要一些工作。
有一个开源的Redis分支“KeyDB”，它通过活动副本选项消除了对前哨节点的需求。这允许复制副本节点接受读取和写入。发生故障转移时，HAProxy会停止对故障节点的读/写操作，而只使用已同步的剩余活动节点。时间戳使故障节点能够自动重新加入并在重新联机时重新同步，而不会丢失数据。设置很简单，对于更高的通信量，您不需要特殊的前期设置来将读取定向到副本节点，并将读/写定向到主节点。See example of active replication here。KeyDB也是多线程的，对于某些应用程序来说，这可能是集群的替代方案，但这实际上取决于您的需求。
还有一个设置clustering manually和使用create-cluster tool的示例。如果您使用的是Redis，这些步骤是相同的(将说明中的‘keydb’替换为‘redis’)