Yii 应用程序中的重复或交叉会话？答案

【问题标题】：Duplicate or Crossover Sessions in Yii application?Yii 应用程序中的重复或交叉会话？
【发布时间】：2016-04-22 17:09:25
【问题描述】：

我知道像 PHP Session ID Duplication? 和 How unique is the php session id 这样的讨论，但我提出了一个问题，看起来像是重复会话，无法弄清楚可能是什么原因造成的。

有一个 Yii 1.1 应用程序在 PHP 5.5 上运行，设置包括两个 Apache Web 服务器、负载平衡 (BigIp) 和两个用于用户数据缓存和会话处理的 Memcache 服务器。每天登录该应用的平均流量约为 10,000 名访问者。

在负载平衡器故障转移后报告了第一个事件。然而，从那时起，MySQL 上实现了会话日志记录机制，以跟踪每个登录用户生成的会话，并防止另一个用户使用先前生成的会话登录。

如果捕获到重复会话，则用户将注销并重新生成会话。

到目前为止的结果表明，几乎每天都有至少一两个用户获得重复会话的情况，因此实施的机制开始解决它。

尽管强烈建议此类事件在应用程序的生命周期内极不可能发生，但我仍会监视日志，表明正在发生一些奇怪的事情。我可以就可能导致问题的原因提出一些建议。

我认为可能以某种方式连接的另一个问题是，尽管一个会话在 10 分钟无活动后过期，但经常注意到用户将在 10 分钟内登录 3-4 次，在我看来，这是似乎表明内存缓存随机丢失会话。

该设置不使用粘性会话，这意味着每个用户请求都在服务器 1 或服务器 2 上随机提供。

看起来像

我进行了一些进一步的搜索，发现了一个我认为更适合我描述的术语：“会话交叉”。

【问题讨论】：

嗨，如果您没有在 LB 中使用粘性会话并将会话数据保存在内存缓存中，那么将会话数据仅保存在其中一个服务器中可能是个好主意。也许这就是“10分钟内登录3-4次”的原因。（见serverfault.com/questions/164350/…）。此外，memcache 可能会丢失数据（当 memcache 空间已满时）
我提到了粘性会话案例，因为我已经看到很多关于这种方法的参考资料，但是，我认为当 memcached 处于“游戏”中时，您不必“担心”这一点。 . 虽然在我描述的情况下，似乎不能正常工作 100%

【解决方案1】：

问题是笼统的给出一个具体的答案，尝试通过检查系统和改变事物来获取更多信息。

如果你不使用粘性会话，显然你的会话存储必须共享，也许 memcache 运行了两次？

尝试粘性会话，看看它是否有所作为。

尝试其他会话存储，例如tempfs 中的文件以及粘性会话。

检查 sessionid 的随机性，可能随机生成器被设置相同的种子欺骗。有时它有助于切换 php 的执行方式 modphp->fcgi

祝你好运

【讨论】：

您能否详细说明 memcache 运行两次？我知道我的问题会针对不同的方面进行检查，但到目前为止还无法确定 memcache、负载均衡器、php 等是否责备。我只能肯定地说，在负载均衡器的故障转移期间，该案例具有高度可重现性。在那个特定时间，几乎所有用户的会话似乎都混在一起
根据digitalocean.com/community/tutorials/… "如果没有这个 Memcached 设置，如果您的应用程序在多个服务器上进行负载平衡，则有必要在负载平衡器上配置会话粘性。这样可以维护用户体验并防止它们不会突然被注销。配置 Memcached 来处理会话将确保 Memcached 池中的所有云服务器具有相同的会话数据集，从而无需粘在一台服务器上来保留会话。"
我希望您有可以分析问题的暂存系统。所以我建议改变你的设置，看看会发生什么。例如。只运行一个共享的 memcache 服务器，如果这样你就知道在哪里搜索问题。

【解决方案2】：

好吧，只是实际思考。会话数据存储在文件中。只要此会话文件存在，会话就处于活动状态。因此，您可以确定是否正在使用特定的 session-id。

所以你可以做的是：

警告，这是一种实用的方法，我希望 PHP 不应该获得重复的 session-id，如果是这种情况，应该将其作为要修复的错误报告给 PHP 项目。

【讨论】：

会话数据存储在memcache中，它应该至少持续十分钟，除非有任何活动。根据这条评论，stackoverflow.com/a/27298129/1234825 面临重复会话应该是非常罕见的，但根据日志，每天至少有几起用户被分配相同会话 id 的情况
两件事，首先是有运行 php 的网站每天有 +mln 用户，所以肯定有一个修复。第二个只是预感，如果app存储了session-id会发生什么，第二天用户再次打开app，app会将session-id发送到服务器，但是现在这个session-id已经被某人使用了别的？我相信通常应用程序会超时/删除会话 ID 并与您的服务器通信空白，这意味着没有设置会话 ID。您是否检查过您在客户端的会话超时时间是否与服务器上的超时时间相同？
你说得很好，彼得，我现在正在做一些搜索，我遇到了一个可以更好地描述这种情况的术语“会话交叉”我在这里遇到了它mail-archives.apache.org/mod_mbox/tomcat-users/200404.mbox/…> 所以我倾向于认为这主要不是重复会话生成，而是用户之间的会话交叉。客户端的 cookie 配置为在不活动的 10 分钟内过期，我相信服务器端配置了相同的时间

【解决方案3】：

您的内存缓存服务器是如何连接的？它们都用于阅读和写作吗？采用什么策略？

我还从 Redis 知道，它在内存不足时（随机）丢弃键，也许 memcache 有类似的东西？

【讨论】：

对一个memcache server over over没有特殊处理，都是用50的权重，都是用来读写的。我不熟悉 memcache 中随机丢弃键的问题，除了它已满时，但我真的怀疑它达到接近其完全限制的任何地方
如果同时使用memcache进行读写，如何保持同步，会不会有延迟？
正如我在另一条评论中提到的，你不需要对内存缓存使用粘性digitalocean.com/community/tutorials/…