您好我是Marklogic和Apache的新手。我已经提供了使用apache作为我们的3台机器的Marklogic集群的负载均衡器的任务。 Marklogic集群当前正在Linux服务器上运行。
我们怎样才能做到这一点？任何有关这方面的信息都会有所帮助。
答案 0 :(得分：7)
您可以使用mod_proxy_balancer。如何配置它取决于您想要使用的MarkLogic客户端。如果您想使用Java Client API，请按照第二个示例here允许apache生成粘性Cookie。如果您想使用XCC，请将其配置为使用ML-Server生成的或后端生成的"SessionID" cookie。
这里的区别在于XCC使用会话，而Java Client API构建在无API的REST API上，因此没有会话。但是，即使在使用多请求事务时在Java Client API中，也会在该事务的持续时间内强制执行状态，因此负载均衡器需要一种方法将该事务期间的请求路由到MarkLogic集群中的正确节点。每次使用事务的请求时，Java Client API都会重新发送粘性cookie，因此负载均衡器可以保持与该事务相关的请求的粘性。
与往常一样，对您的配置进行一些测试，以确保您做对了。正确配置apache插件是一项高级技能。由于您不熟悉apache，因此确保正确使用它的最佳希望是使用WireShark之类的HTTP监视工具进行检查，以查看从应用程序到MarkLogic Server的HTTP流量，以确保事物进入群集中的正确节点如预期的那样。
答案 1 :(得分：1)
请注意，即使使用客户端API（Java，Node.js），在语言API层也不总是显而易见或明确可能导致创建会话。肯定会明确地创建多语句事务，但其他操作也可以这样做。如果您使用相同的UI（浏览器）和API（REST或XCC）连接，那么浏览器应用程序很可能会创建会话状态。
最安全但灵活性最低的配置是＆＃34; TCP会话亲和力＆＃34;。如果它们得到支持，它们将消除与负载平衡相关的大多数问题。 Cookie Session Affinity依赖于保证load balencer使用正确的cookie。并非所有代码都相同。我遇到过负载均衡器并不总是使用提供的cookie的情况。将配置更改为＆＃34; Load Balancer提供的Cookie Affinity＆＃34;修好了。
如果所有通信在TCP层，HTTP层和应用层都处于无状态，则不需要这些。后者不能由服务器推断。 另一个问题是，如果您的应用程序或中间层与其他应用程序或连接到同一负载均衡器和端口的同一应用程序共存。这可能很难确保没有交叉的电线＆＃39; 。当ML获得请求时，它将其身份与客户端IP和端口相关联。即使没有负载资源，大多数现代HTTP和TCP客户端库都实现了套接字缓存。如果图书馆或应用程序正在共享＆＃34; cookie jar＆＃34;这是一个很好的表现，但却是一个隐藏的微妙随机严重错误来源。 （不是uncomnon）。不同应用程序上下文使用的TCP和Cookie Jar缓存最终可能会将状态信息从同一进程中的一个不相关的应用程序发送到另一个应用程序。大多数情况下，这是在中间层应用服务器中，可能只是在没有域知识的情况下传递来自第一层的请求，假设依赖于低级TCP库来做正确的事情＆＃34; ......他们正在做正确的事 - 对于图书馆程序员心中的用例 - 不要假设你的案例是图书馆作者所假设的。这些症状往往非常罕见，但是交易失败和数据损坏可能会带来灾难性问题 和安全问题（在应用程序层），因为服务器无法区分来自同一中间层的2个连接之间的区别。
有时，更好的策略是在第一层和中间层之间进行负载平衡，并直接从中间层连接到MarkLogic。 特别是如果在负载均衡器上完成缓存。它更常见于缓存在中间层和客户端之间，中间层和服务器之间有用。这也更类似于RDBMS所使用的经典3层架构，其中负载平衡位于客户端和业务逻辑层之间，而不是业务逻辑和数据库之间。