我一直在读一些关于如何使用Redis Sentinel的文章,我知道有可能有两个或更多的Sentinel,当从客户端调用时,它们之间的负载平衡。
将这两个前哨放在与我的主服务器+从服务器相同的服务器上是一种好的做法吗?换句话说,在同一物理服务器中有1个前哨作为主服务器,另一个前哨作为从服务器在同一物理服务器中?
在我看来,如果主服务器死了,从服务器中的前哨将简单地将从服务器提升为主服务器。如果从服务器死了,那也没关系,因为主服务器还在运行。
我是不是遗漏了什么?它的缺点是什么?
我宁愿让前哨与主/从服务器在同一物理服务器中,以减少延迟。
发布于 2015-02-05 06:58:03
首先,Sentinel不是负载均衡器,也不是Redis的代理。
其次,并不是所有的故障都是主机的死亡。有时服务器会短暂挂起,有时网线会被拔掉,等等。因此,在与Redis实例相同的主机上运行Sentinel并不是一个好的做法。如果您使用Sentinel来管理故障转移,那么在Redis主节点和从节点以外的节点上运行的任何少于三个前哨的节点都是在自找麻烦。
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的网络连接,HostB会将其自身提升为主主机。现在,您拥有:
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实例的当前master (按名称),然后连接到它。如果主服务器死了,客户端应该断开连接,然后客户端将/应该再次连接到Sentinel并获取新信息。
每个客户端库如何处理这一点取决于该库。
理想情况下,主机C、D和E位于您连接到Redis的同一主机上(即客户端主机)。或者代表一个好的样本得到了它们。这里的主要推力是确保你检查你需要从哪里连接到Redis。否则,会将它们放置在与客户端相同的DC/机架/区域中。
如果您希望让客户端与负载均衡器通信,请尽可能在这些LB节点上添加Sentinels,根据需要添加额外的非LB主机,以获得大于2的奇数数量的sentinels。例外情况是,客户端主机的数量是动态的,因为它们的数量不一致(例如,它们针对流量进行扩展,在较慢的时间段进行缩减)。在这种情况下,您必须在非客户端和非redis-server主机上运行您的Sentinels。
请注意,如果这样做,那么您将需要编写一个守护进程来监视主机切换事件的Sentinel PUBSUB通道,以更新LB -which,您必须将其配置为仅与当前主机通信(永远不要同时与两个主机通信)。这需要做更多的工作,但确实利用了对客户端透明的Sentinel -它只知道与LB IP/Port交谈。
发布于 2015-02-04 22:52:57
这完全取决于您想要实现的灾难恢复级别,让我们假设您拥有以下独立于托管位置的组件:
1个主1+从站
单主机方案
主机故障:在大多数情况下,您将失去一切,糟糕的复制场景。
双主机方案
主机1:
主机2:
确实,在这种情况下,您可以让主机一次失败一个,这为您提供了一定级别的安全性。只需试着理解不同的服务器是否意味着物理上不同的主机。如果这些只是同一主机上的虚拟机,您将无法获得相同级别的灾难恢复(灾难恢复)。
关于你的问题的:
为了减少延迟,我宁可让前哨与主/从服务器在同一服务器上。
请注意,Sentinel会跟踪当前的主设备和从设备,但Redis客户端并不通过Sentinel连接到master,它们只是通过Sentinel获得当前主设备的位置,例如,在读取和写入方面,您不需要考虑任何显著的*延迟增益。
配置提供程序。Sentinel充当客户端服务发现的权威来源:客户端连接到Sentinels,以便请求负责给定服务的当前Redis主机的地址。如果发生故障转移,Sentinels将报告新地址。
(请参阅:http://redis.io/topics/sentinel)
在我看来,您在延迟方面的唯一收益是从主机和从机发送到哨兵的心跳。只要你不把你的服务器分散到全世界,这应该没问题。
这完全取决于用例,但如果所有其他条件都相同(成本、到客户的距离等),您似乎最好将事情尽可能地分开。
发布于 2017-04-22 12:06:00
在主/从同一台机器上可以有,但是sentinels 必须是奇数(3/5/7)。至少应该有三个哨兵,并且必须有一台专门的机器用于至少一个哨兵。
如果您只有两个节点,那么在出现大脑分裂(网络中断)的情况下,slave会被提升为master。两个主机现在都将接受来自clients.However的数据,当事情恢复正常时,其中一个主机将被降级为从机。该主机将丢失其所有数据,因为它现在是从主机,并且将从当前主机复制数据。
查看这里可以很好地解释redis架构设计和分裂大脑:http://www.yzuzun.com/2015/04/some-architectural-design-concepts-for-redis/
https://stackoverflow.com/questions/28323936
复制相似问题