我一直在阅读有关如何使用 Redis Sentinel 的文章，并且我知道可能有 2 个或更多的哨兵，并在从客户端调用时在它们之间进行负载平衡。
将这 2 个哨兵与我的主服务器 + 从服务器放在同一台服务器上是一种好习惯吗？换句话说，有 1 个哨兵作为主服务器在同一物理服务器中，而另一个哨兵作为从服务器在同一物理服务器中？
在我看来，如果主服务器死了，从服务器中的哨兵只会将从服务器提升为主服务器。如果从服务器死了，没关系，因为主服务器还在。
我错过了什么吗？有什么缺点？
我宁愿让哨兵与主/从位于同一物理服务器中以减少延迟。
首先，Sentinel 不是 Redis 的负载均衡器或代理。
其次，并不是所有的失败都是宿主的死亡。有时服务器会短暂挂起，有时会拔掉网线等。因此，在与 Redis 实例相同的主机上运行 Sentinel 并不是一个好习惯。如果您使用 Sentinel 来管理故障转移，那么在 Redis 主节点和从节点之外的节点上运行的任何少于三个的哨兵都在自找麻烦。
Sentinel 使用仲裁机制对故障转移和从属设备进行投票。如果少于两个哨兵，您将面临裂脑的风险，其中两个或更多 Redis 服务器认为它们是主服务器。
想象一下您运行两台服务器并在每台服务器上运行哨兵的场景。如果您丢失一个，您将失去可靠的故障转移功能。
客户端仅连接到 Sentinel 以了解当前的主连接信息。每当客户端失去连接时，他们都会重复此过程。Sentinel 不是 Redis 的代理 - Redis 的命令直接转到 Redis。
运行少于三个哨兵的哨兵的唯一可靠原因是服务发现，这意味着不将其用于故障转移管理。
考虑两个主机场景：
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 的客户端都将被告知主机 B 是主机，而连接到 Sentinel 1 的客户端将被告知主机 A 主机（如果您的 Sentinel 位于负载均衡器后面，则意味着一半的客户端）。
因此，您需要运行以获得最低可接受的可靠故障转移管理是：
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
您的客户端连接到哨兵并获取 Redis 实例的当前主服务器（按名称），然后连接到它。如果主服务器死亡，客户端应该断开连接，因此客户端将/应该再次连接到 Sentinel 并获取新信息。
每个客户端库处理此问题的能力取决于该库。
理想情况下，主机 C、D 和 E 位于您连接到 Redis 的同一主机上（即客户端主机）。或代表一个好的抽样得到了他们。这里的主要目的是确保您从需要连接到 Redis 的位置进行检查。未能将它们放置在与客户端相同的 DC/机架/区域中。
如果您想让您的客户端与负载均衡器通信，请尽可能尝试在这些 LB 节点上设置您的 Sentinel，根据需要添加额外的非 LB 主机以获得奇数个 > 2 的 Sentinel。如果您的客户端主机是动态的，因为它们的数量是不一致的（例如，它们为流量增加，在缓慢的时期减少）。在这种情况下，您几乎必须在非客户端和非 redis 服务器主机上运行 Sentinel。
请注意，如果您这样做，您将需要编写一个守护程序来监视 Sentinel PUBSUB 通道，以便更新主开关事件以更新 LB - 您必须将其配置为仅与当前主设备对话（切勿尝试与两者对话）。这样做需要做更多的工作，但确实使用对客户端透明的 Sentinel——它只知道与 LB IP/端口通信。
这完全取决于您想要达到的灾难恢复级别，假设您拥有以下组件，与它们的托管位置无关：
1 主 1+ 从
一台主机方案
主机失败：你失去了一切，大多数用例的复制场景都很糟糕。
两台主机场景
主机1：
主持人2：
确实，在这种情况下，您可以让主机一次发生故障，从而为您提供一定程度的安全性。试着了解不同的服务器是否意味着物理上不同的主机。如果这些只是同一主机上的虚拟机，您将无法获得相同级别的 DR（灾难恢复）。
关于你的问题：
我宁愿让哨兵与主/从在同一台服务器上，以减少延迟。
请注意，Sentinel 会跟踪当前的主服务器和从服务器，但 Redis 客户端不会通过 Sentinel 连接到主服务器，它们只是通过 Sentinel 获取当前主服务器的位置，例如，在读写方面你不是调查任何可观的*延迟收益。
配置提供者。Sentinel 充当客户端服务发现的权威来源：客户端连接到 Sentinel 以请求负责给定服务的当前 Redis 主服务器的地址。如果发生故障转移，Sentinels 将报告新地址。
（见：http ://redis.io/topics/sentinel ）
在我看来，您在延迟方面的唯一收获是从主设备和从设备发送到哨兵的心跳。只要您不将服务器传播到全世界，那应该没问题。
这一切都取决于用例，但如果所有其他条件相同（成本、与客户的距离等），您似乎最好将事物尽可能分开。
您可以在与主/从机的同一台机器上拥有哨兵，但哨兵的数量必须是奇数（3/5/7）。至少要有三个哨兵，并且至少要有一个哨兵专用的机器。
如果你只有两个节点，那么在出现脑裂（网络中断）的情况下，slave 将被提升为 master。现在两个主节点都将接受来自客户端的数据。但是，当一切恢复正常时，其中一个主节点将被降级为从节点。该主服务器将丢失其所有数据，因为它现在是从服务器，并将复制当前主服务器的数据。
检查这个很好地解释了redis架构设计和脑裂： https ://web.archive.org/web/20170527053749/http://www.yzuzun.com/2015/04/some-architectural-design-concepts -for-redis/
这当然不是推荐的方法。
Redis Sentinel 文档很好地解释了权衡。希望这可以帮助。 https://redis.io/topics/sentinel#example-sentinel-deployments