您好我们正在测试CB enterpise 2.5和Java客户端1.4.3（最新）。
我们有一个3节点集群，当它全部启动时它会很棒。当我们在进程中杀死（但不要进行故障转移）时，我们注意到性能上的巨大差异。它能够非常快速地为其他两个节点上的文档提供服务，但是操作会急剧下降，因为每次我们尝试从失败的节点获取文档时它都会等待超时。 java客户端应该是健壮的，绝对是服务器。这两件事都应该知道节点已关闭，为什么它等待完全超时直到它失败？难道它不会意识到节点已关闭并立即出错或从副本中获取吗？
我们做错了吗？我们有opTimeout到2500ms，shouldOptimize = true，甚至将协议切换为二进制。我们还尝试手动将FailureMode设置为Redistribute。
我们做错了什么，或者这是沙发基地的规格？因为当前数据库在以前每秒执行5k次操作时等待2.5秒的超时时间会不堪重负。
答案 0 :(得分：3)
在节点变为不可用并且它进行故障转移（用户可配置的值）之间，对“死”节点的任何请求将等待超时时间，然后向用户报告超时。
因此，所有对“死”节点的请求都将失败直到发生故障转移 - 因此您的操作将根据您的情况定义为低，因为33％的数据当前不可用
如果您正在使用同步API调用，那么您还会遇到这样的问题：对于“死”节点的请求可能会备份对健康节点的请求，因此您可以在应用程序中等待2.5秒继续其他工作。这是异步API更高性能的一个很好的理由。在这种情况下，为了减轻对其他健康节点的请求的影响，您可以将超时值减少为“更快失败”，并尽快转移到下一个请求。
答案 1 :(得分：0)
还有另一种解决方案，可通过Couchbase的REST API获得。 实际上整个管理控制台都基于REST API，因此您的应用程序中可以使用每个功能。 自动转发的最低值为30秒，但您可以随时启动故障转移。
故障转移几乎是即时的。当然，之后建议重新平衡。