从 CacheManager.NET 的角度来看，我有一个关于 Redis 连接参数的基本问题。如果我们有一个主服务器和两个从服务器的 Redis 集群，并且有法定人数的哨兵进程，我们应该提供指向哨兵进程或实际 Redis 服务器进程的 IP:PORT 组合。
正如https://seanmcgary.com/posts/how-to-build-a-fault- tolerance-redis-cluster-with-sentinel 中所建议的，建议在建立连接之前向哨兵进程询问实际的主进程。这可能与 Jedis 一致，Jedis 提供 JedisSentinelPool 来进行初始查找。
本质上，我们想要的是读取（通过 CacheManager.NET）和写入的负载平衡应该转到集群的当前主节点。
CacheManager依赖StackExchange.Redis来实现 Redis。因此，无论这个客户端库支持什么，CacheManager 也支持。
不幸的是，没有实施哨兵支持，多年来在 github 上存在一些问题
话虽如此，我使用多主/从 + Sentinel 设置进行了一些测试。将所有非哨兵节点作为端点添加到多路复用器配置中，它有点工作，因为 Redis 客户端知道如何处理多个主/从实例。
在切换到另一个主机的过程中，客户端可能会抛出无法写入只读从机等的异常。CacheManager 可能会重试这些调用，并且在很短的时间后，当领导者选举完成时，调用应该会通过。
但这不是 100% 稳定的，我不会将其投入生产，因为仍然缺少“官方”支持......
作为使用哨兵运行的替代方案，您可以在集群模式下运行 Redis，它应该可以正常工作，或者在处理所有主/从内容的代理后面运行。
Twemproxy是一种替代方案。
我仍然需要向 CacheManager 添加对 Twemproxy 的支持，因为许多功能根本不可用，例如 Lua 脚本或获取服务器列表或刷新命令......这将在 1.0.2 中出现
希望有帮助。