用于存储 Web 会话的 FOSS 解决方案答案

【问题标题】：FOSS solution for storing web sessions用于存储 Web 会话的 FOSS 解决方案
【发布时间】：2013-06-07 16:30:56
【问题描述】：

上下文

我正在开发一个简单的 Web 应用程序（用 python/pyramid 编写），它使用底层 http 服务作为数据存储，并通过使用后端 http 通信与合作伙伴集成。此 Web 应用程序将部署在 3 个或更多节点中，并预先配备负载均衡器

大部分用户导航数据将存储在服务器端的会话中（我不想用加密的 cookie 数据加载浏览器），这带来了如何正确复制会话的问题。适当的负载平衡和避免用户导航中断很重要，因此我不想使用粘性会话也不想丢失会话数据。

我应该使用什么？我正在考虑将我的会话数据存储在关键数据存储（memcached、redis、cassandra 或 couchbase）或关系数据存储（postgresql 或 mysql）上

这是我的previous question on the topic，我尝试在其中指出不同数据存储的高点和低点。问题已关闭，因为很难理解问题是什么，所以我在没有我意见的情况下简化并创建了这个问题

【问题讨论】：

取决于您的会话数据是否需要能够在守护程序重新启动或系统重新启动后继续存在。
是的，应该。我不想以任何方式破坏用户导航
在这种情况下，您需要查看哪些后端能够在重启后幸存下来。如果您经常将数据同步到磁盘，基于 FS 的 (postgresql/mysql) 可以，基于内存的 (memcached/redis) 可能还可以，但是如果它们意外死亡，您将始终丢失数据，所以如果你真的很在意，你可能应该选择基于 FS 的商店。
我确实更倾向于使用基于内存的键值存储。如果我的数据存储本身被复制，那么在重新启动后幸存下来应该不是问题

【解决方案1】：

Couchbase 服务器被广泛用作分布式会话存储。您可能知道 Couchbase 是构建在 Memcached 协议之上的 NoSQL 数据库。

这意味着您拥有 Memcached 的速度和可靠性，以及 Couchbase 集群的强大功能。集群上的分区速度非常快，因为客户端（或 moxi，memcached 代理）负责选择会话应该去的节点，并根据需要异步复制它（因此不会影响性能）。

免责声明：我是 Couchbase 的技术传播者

【讨论】：

有趣的是，我们已经在一些项目中使用 couchbase 进行会话存储，但它们都有竞争条件，因为复制是异步的，但实际上由于这些系统的性质，它不会发生。阅读docs 确实沙发库默认是异步的，但“它被设计为同步”。你能给我指点如何使它同步，如果它确实是一个好主意。我知道我会对性能产生影响，但我想知道这种影响是否确实相当大

【解决方案2】：

我使用pyramid_beaker 来存储会话数据。它将beaker 库包装成金字塔。

在生产服务器上，我使用 memcached 后端。我不记得我选择了哪个库来支持它。

一些实现细节：

我将 pyramid_beaker 分叉到 pyramid_beaker_https，并对所有用户使用 2 个 cookie。一种是“仅限http”，它返回公共数据和站点查看权限。另一个是“仅限 https”，用于 /account 下的所有内容和任何写入操作。
我还添加了一个“自动登录”cookie。如果会话身份验证失败（因为 memcached 出现故障，并且现在无效），则定期重置自动登录会加密数据以重新创建 cookie 会话。
我会跟踪会话中每次登录的发生情况，因此自动登录需要对任何 /account 或选择写入操作重新进行身份验证。

【讨论】：

有趣。使用 memcached 让我担心的是丢失一个节点并破坏用户导航。为了正确使用，我可能需要将会话写入所有 memcached 节点并从所有节点读取并获取最新版本的数据
“扰乱用户导航”是什么意思？
表示用户在导航时可能会得到意想不到的结果，比如会话失效、被注销、收到5XX页面或服务器端导致连接问题
这就是我使用自动登录 cookie 的原因。如果会话无效，则在失败之前尝试使用基于 cookie 的加密会话来创建新的服务器端会话和 cookie。您不应该将会话写入所有 memcached 节点，只写入一个。这是对性能和内存的浪费。 memcached 的设计初衷不是为了安全或持久——它是一个快速的轻量级缓存。如果你想避免 memcache 失败，你可以使用 mongodb 或 redis，这两者都可以在 beaker 中支持。我对“用户导航”的担忧是您是否在会话中使用面包屑跟踪用户。
TBH，当我切换到使用自动登录 cookie 时，我实际上发现根本不需要服务器端会话。如果始终可以通过此 cookie 对用户进行身份验证，并且您使用 JS 将中间表单数据存储在 web storage 中，那么剩下哪些用例需要服务器端会话？