我们在HA中有2个pfSense FW，后面是主/从集群中的2个Zen负载均衡器，在这些后面是运行NGinx，PHP-FPM，PHP-APC的3个前端Web堆栈服务器。在同一网段中，主/从复制中有 2 个 MySQL 数据库服务器。
前端的 PHP 会话应在 1440 秒后"清理"：
session.gc_maxlifetime = 1440
.
当用户浏览器关闭时，Cookie 将过期：
session.cookie_lifetime = 0
今天，一位最终用户提醒我们，他们登录了（网站上基于 PHP 的登录表单），但被验证为完全不同的用户。至少可以说这很不方便。
ZLB设置为使用Hash：Sticky Client。他们应该在会话期间将用户粘在单个前端 （FE） 上。我能想到这种情况发生的唯一原因是两个 FE 生成了相同的 PHP 会话 ID，然后不知何故，用户不幸被 LB 定向到另一个 FE。
我的问题很多，但现在，我只有几个：
- 我可以为每个前端服务器设置不同的 SESSID 名称吗？这会阻止 FE 生成相同的会话 ID 吗？这至少会导致用户注销，而不是以其他用户身份再次登录！
- 我们使用 lsyncd 和一大堆 inotifywatch 进程同步站点数据，但不同步包含会话的/var/lib/php 目录。我故意没有这样做...我现在在想也许我应该同步它。Lsyncd 将能够在修改会话后的大约 10 秒内跨所有 3 个前端复制会话文件。作为临时修复的好主意？
最后，我非常清楚客户端应该使用数据库来存储会话。这将完全消除它能够复制会话 ID。但是现在，他们不愿意在开发时间表中优先考虑这一点。
想法非常受欢迎，因为我正在努力寻找一个简单的出路，即使是作为临时措施。我不能让其他客户端以其他用户身份登录。这是一个巨大的禁忌。
谢谢！！
从您的问题来看，您对问题有些困惑 - 并且不清楚您要解决的问题。
今天，我们收到最终用户的提醒，他们登录了（网站上基于PHP的登录表单），但被认证为完全不同的用户
这里可能会发生几件事。
当用户浏览器关闭时，Cookie 将过期：
并非如此。根据浏览器的配置方式，大多数浏览器将在重新启动后保留会话 Cookie。由于这是在客户端控制的，因此您无法对此做太多事情。
前端的 PHP 会话应在 1440 秒后"清理"
这里的魔术词是"之后"——垃圾收集是随机触发的。会话文件可以保留更长的时间，默认处理程序将在 TTL 过期后愉快地检索和反序列化会话数据。
您是否控制应用程序代码？（如果没有，您的帖子在这里偏离主题）。如果是这样，那么您的代码中可能存在会话固定和劫持漏洞（但这是基于用户提供的描述 - 这通常是不精确和误导性的）。
内容也可能被不恰当地缓存在堆栈中的某个位置。
你没有说网站是在HTTP，HTTPS还是混合上运行，如果涉及HTTPS，SSL在哪里终止。这些是了解问题可能出现在哪里的关键。
接下来的步骤是确保：
-
您的代码中有注销功能，该功能会销毁会话数据并更改会话 ID
-
在身份验证时更改会话 ID
-
基于会话的脚本返回适当的缓存信息（包括可变：Cookie 标头）两个系统几乎不可能同时生成相同的会话 ID。
真的，您想摆脱使用粘性会话。这并不难。
您的前端有 2 层，它们没有增加任何功能或性能价值，并且由于您使用的是粘性会话，因此实际上没有容量或弹性值!!谁把这个卖给你，都是一路笑到银行。