Java 分布式会议对发展的影响

我一直在研究建立分布式会话环境的意义，并希望确保我没有遗漏任何要点

关于开发将在分布式会话环境中运行的应用程序，我发现的主要开发问题是会话中可能保留的数据丢失。显然，所有内容都必须序列化或转换为无状态（或两者的组合），这对于任何已经编码为大量会话使用的应用程序来说都是一项重大任务

是否有其他我应该注意的潜在问题或影响

---

编辑：更具体地说（作为一个例子），我指的是servlet容器环境中的Java web应用程序服务器端会话。

您是否想到了“分布式会话”的精确定义

我认为您的想法是有一个客户端（例如浏览器）和一个服务器（例如servlet引擎）会话状态是在客户端和服务器之间分配的，因此，例如，客户端必须在每个请求中发送特定的cookie，服务器必须识别哪个会话属于哪个客户端

有一些基本问题需要解决：一致性、可靠性和可伸缩性，通过让会话状态使其中一个或另一个，或两者都变得困难

简单情况：服务器在每次请求后将状态持久化到数据库。相当可靠，但价格昂贵（每次DB写入），可扩展性很强，可以有多个服务器副本。应用程序开发人员必须确保状态可以持久化——这通常意味着类需要可序列化。如果你在课程中放了很多东西，那会很贵

因此，请将其保留在内存中：不要将会话持久化，请将其保留在内存中。这会以牺牲可靠性为代价来提高性能，现在，如果我们失去了服务器，就失去了会话。我们需要确保来自客户机的每个请求都发送到同一个服务器实例，因此可伸缩性非常棘手。我们不能简单地将请求卸载到其他服务器副本，因为它们不会有会话

因此，分发会话：一些应用服务器有聪明的分发方案，可以将会话传递给其他实例。通常认为这比DB便宜，但实际上可能不是。同样，应用程序开发人员需要使会话可序列化。通常，您仍然需要良好的客户机/服务器亲和力，因此您最多会访问同一台服务器，这会减少会话复制

通常我们真正需要做的是选择。并非所有的课程都很重要。我们不想失去一辆购物车，但是我们刚才看到的清单呢？假设这个列表只是有点过时了，那就重要了

因此，我的一般性建议是：不要将会话状态用于您真正关心的事情，不要将会话状态用作一般转储场。总的来说，开发人员在将事情放入会话中的能力要比在重新整理时强得多。大型（超过k或2个）持久会话是一个严重的问题

---

这是一条经验法则：把重要的东西保存到数据库中，考虑把一些东西放进cookie（有效地给客户提供责任），只把那些可以很容易地重新创建的内容放入会话中。然后，您可以只依赖简单的会话关联，而不依赖服务器实例之间的持久性/分布。

您对“分布式会话环境”的确切含义是什么？什么样的会议？什么类型的分发？servlet容器上的Web应用程序服务器端会话数据。我会把这个添加到原来的帖子里！好问题！谢谢我从来没有像你说的那样详细地考虑过可伸缩性的影响。哇，这是一篇精彩的文章，还有几件我绝对没有想到的事情。我真的很感谢你的回应。