.net - 如何使用 ConnectionMultiplexer 在 Redis 集群中处理故障转移？

Question

我有一个 6 节点的 Redis 集群，如您所料，有 3 个从节点和 3 个主节点。
从 Redis 服务器的角度来看，一切看起来都很笨拙，我可以在服务器上调用 cluster failover 或 debug segfault，然后适当的从服务器成为主服务器。

从 .net 方面来看，我一直在关注 StackExchange Redis文档，所以我有一个静态的 IConnectionMultiplexer，我从中得到一个 IDatabase，我可以从那里存储和检索值。

我使用的连接字符串如下:srv1:7001,srv2:7001,srv3:7001,srv1:7002,srv2:7002,srv3:7002

到目前为止，还不错。

但是，我正在尝试弄清楚在使用连接多路复用器时如何处理集群中的主节点故障。目前，我能想到的最好办法是捕获异常，丢弃当前的连接多路复用器并创建一个全新的连接多路复用器，感觉有点恶心。

考虑到我在连接时告诉多路复用器所有潜在的端点，我希望它能密切关注这样的事情并自动开始与新主控器对话。一些the documentation也暗示这句话:

Likewise, when the configuration is changed (especially the master/slave configuration), it will be important for connected instances to make themselves aware of the new situation (via INFO, CONFIG, etc - where available). StackExchange.Redis does this by automatically...

如果我关闭 srv1:7001 并且什么都不做，那么连接永远不会恢复，每次调用设置新值都会抛出 RedisConnectionException。

我尝试附加到事件 ConfigurationChanged、ConfigurationChangedBroadcast、ConnectionFailed 并订阅各种 channel ，希望在主人下去了。如果我导致集群中的主节点发生变化，这些似乎都不会触发。

所以我想知道在这方面我是否遗漏了什么？

干杯，
克雷格。

Answer 1

经过一番尝试后，我注意到多路复用器最终确实重新配置了自身。最初我在 Debug模式下停止检查某些东西时注意到了这一点，当我继续时，它意外地再次开始工作。

如果我在连接字符串中设置 configCheckSeconds=1，而不是默认值 60，则重新配置会更加迅速，所以我假设这是罪魁祸首。

我不确定如此显着地更改此设置会产生多少开销。我想在一般情况下，集群节点发生故障的可能性很小，因此没有必要经常重新配置。我刚刚创建了一个极端的测试场景。