【发布时间】：2014-07-03 22:18:10
【问题描述】：
我们正在开发一个应用程序，它会定期将不同客户端的 LDAP 服务器与我们的数据库同步。此应用程序需要通过 Web 门户访问。 Web 用户将在此应用程序上创建、修改或删除计划任务。因此，我们将此应用程序开发为 Web 服务。
现在，我们必须扩展此应用程序并确保高可用性。
该应用程序是在 Tomcat 上运行的基于 Axis2 的 Web 服务。我们已经想到了 httpd + mod_jk + tomcat 的组合来进行负载均衡。问题是，如果出现修改/删除请求，那么它应该落在最初创建任务的同一 tomcat 服务器上。但是，由于请求可能来自从不同 IP 地址访问 Web 门户的不同 Web 用户，因此我们不能有相同的会话 ID（粘性会话）。
有什么解决办法吗？不同的架构？随便。
我们也想过使用 Quartz scheduler api。该站点表示它支持负载平衡和集群。有没有人有使用 Quartz 处理这种情况的经验？
【问题讨论】：
-
听起来你的数据库——或者存储任务信息的地方——也是分布式的；即，不是所有 Web 服务器都访问的公共数据库。这就是为什么您需要后续请求转到原始网络服务器的原因吗？
-
不，所有任务共享公共数据库。
-
那么，数据库是您可以协调事物的唯一点。您希望后续请求转到同一 Web 服务器的原因是什么？
-
如果在服务器 A 上为客户端 A 创建了任务，那么后续修改/删除该任务的请求必须发送到同一个 Web 服务器。
-
是的，我明白了。我的问题是：为什么？毕竟，如果所有状态都存储在一个数据库中，并且该数据库对所有 Web 服务器都是通用的，为什么它们中的任何一个都不能处理后续请求。如果一个人掉了，为什么其他人不能像什么都没发生一样捡起来？我想有一些状态存储在网络服务器中。无论如何，如果这就是你想要的，我不知道你会如何路由它。
标签： java tomcat scalability