我一直在研究设置分布式 session 环境的影响，并希望确保我没有遗漏任何要点。
关于开发将在分布式 session 环境中运行的应用程序，我发现的主要开发问题是 session 中可能保存的数据丢失。显然，所有内容都必须序列化或转换为无状态(或两者的组合)，这对于任何已经编码用于大量 session 使用的应用程序来说可能是一项重大任务。
还有其他我应该注意的潜在问题或影响吗？
编辑:更具体地说(作为示例)，我指的是 servlet 容器环境中的 Java Web 应用程序服务器端 session 。
最佳答案
您是否引用过您心中的“分布式 session ”的准确定义？
我认为你的想法是，有一个客户端(例如浏览器)和一个服务器(例如servlet引擎)，并且 session 状态是分布式的，因为 session 的责任在客户端和服务器之间分配 - 所以例如，客户端必须在每个请求中发送特定的 cookie，并且服务器必须识别哪个 session 属于哪个客户端。
有一些基本问题需要解决:一致性、可靠性和可扩展性，通过 session 状态使其中一个或另一个或两者都变得困难。
简单情况:服务器在每次请求后将状态保存到数据库中。相当可靠，但昂贵(每次都写入数据库)，相当可扩展，可以拥有许多服务器副本。应用程序开发人员必须确保状态可以持久 - 这通常意味着类需要可序列化。如果你在 session 中放入很多东西，它就会变得昂贵!
因此，将其保留在内存中:我们不要持久化 session ，而是将其保留在内存中。这会以牺牲可靠性为代价而获得更好的性能，现在如果我们失去服务器，我们就会失去 session 。我们需要确保来自客户端的每个请求都发送到同一个服务器实例，因此可扩展性很棘手。我们不能简单地将请求卸载到其他服务器副本，它们不会拥有 session 。
因此分发 session :一些应用程序服务器具有巧妙的分发方案来将 session 传递给其他实例。通常这被认为比数据库便宜，但实际上可能并非如此。应用程序开发人员再次需要使 session 可序列化。通常，您仍然需要良好的客户端/服务器关联性，以便大多数时候都访问同一服务器，这会减少 session 复制。
通常我们真正需要做的是有选择性。并非所有 session 都很重要。我们不想失去购物车，但是我们刚刚看到的 list 呢？假设该列表只是有点过时了，这会很重要吗？
因此，我的一般建议是:不要将 session 状态用于您真正关心的事情，不要将 session 状态用作一般的垃圾场。总的来说，开发人员更擅长将事情放入 session 中，而不是再次整理。大型(超过 k 或两个)持久 session 是一个严重的问题。
因此，根据经验:将重要的内容保存到数据库中，考虑将一些内容放入 cookie 中(有效地将责任交给客户端)，仅将可以轻松重新创建的内容放入 session 中。然后，您可以仅依赖简单的 session 亲和性，而无需服务器实例之间的持久性/分布。
关于java - 分布式 session 对发展的影响，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3841341/