我一直在研究建立分布式会话环境的意义，并希望确保我没有遗漏任何重点。
关于开发将在分布式会话环境中运行的应用程序，我发现的主要开发问题是可能在会话中保留的数据丢失。显然，所有内容都必须被序列化或转换为无状态（或两者的组合），这对于已经为重会话使用而编码的任何应用程序来说都是一项重大任务。
我应该注意其他任何潜在的问题或影响吗？
编辑：更具体（作为示例），我指的是servlet容器环境中的Java Web应用程序服务器端会话。
答案 0 :(得分：7)
您是否参考了您想到的“分布式会话”的精确定义？
我认为你的想法是有一个客户端（例如一个浏览器）和一个服务器（例如一个servlet引擎），并且会话状态是在会话的责任分布在客户端和服务器之间的意义上分布的 - 所以例如，客户端必须为每个请求发送一个特定的cookie，服务器必须识别哪个会话属于哪个客户端。
需要解决的基本问题是：一致性，可靠性和可扩展性，通过让会话状态使您成为一个或另一个，或两者都很困难。
简单案例：服务器在每次请求后将状态持久保存到数据库。相当可靠，但价格昂贵（每次DB写），相当可扩展，可以有很多服务器副本。应用程序开发人员必须确保状态可以持久化 - 这通常意味着类需要是可序列化的。如果你在会话中放了很多东西，那就太贵了！
所以保持记忆：让我们不要坚持会话，把它留在内存中。这样做会以牺牲可靠性为代价，现在如果我们丢失了服务器，我们会丢失会话。我们需要确保来自客户端的每个请求都转到同一个服务器实例，因此可伸缩性很棘手。我们不能简单地将请求卸载到其他服务器副本，它们没有会话。
因此分发会话：一些应用服务器具有聪明的分发方案，以将会话传递给其他实例。通常这被认为比数据库便宜，实际上可能不是。应用程序开发人员再次需要使会话可序列化。通常，您仍然需要良好的客户端/服务器关联性，因此您最常点击同一服务器，这会导致会话复制次数减少。
我们真正需要做的就是选择性。并非所有会话都很重要。我们讨厌失去一个购物车，但我们刚才看到的列表？假设这个列表有点过时了就重要了。
因此我的一般建议是：不要将会话状态用于您真正关心的事情，不要将会话状态用作一般倾销场。大多数开发人员在将事情放入会话方面要比他们再次整理更好。大型（超过k或两个）持续会话是一个严重的问题。
因此，根据经验法则：将重要内容保存到数据库中，考虑将一些内容放入cookie中（有效地对客户端负责），只在会话中放入可以轻松重新创建的内容。然后，您可以只依赖简单的会话亲缘关系，而不依赖于服务器实例之间的持久性/分发。