P粉7978557902023-09-01 15:45:09
查看此答案。显然,如果您将会话的最大过期时间设置为大于memcached的过期限制,则可能会出现此问题。在那篇文章中,OP 通过修复以下配置变量解决了这个问题,您可以尝试:
define('SESSION_TIME_OUT', x); ini_set('session.gc_maxlifetime', SESSION_TIME_OUT); ini_set('session.cache_expire', SESSION_TIME_OUT); session_start();
另一种选择是删除 memcached
并使用内存驻留 sqlite3
数据库来代替会话存储,我认为生产环境上的性能不会有太大不同在这两种情况下。
P粉7627302052023-09-01 11:17:20
如果您使用的是 AWS ElastiCache Memcached 集群,请检查您在配置中使用的终端节点 $config['sess_save_path']
。一种选择是使用配置端点(其中包含 .cfg.
),另一种选项是单个节点端点(包含 .0001.
、.0002.
等)。如果您使用配置终端节点,请确保启用了自动发现(需要在服务器上进行额外安装 - 适用于 PHP 的 ElastiCache 集群客户端)。如果不启用,您的节点将无法正确解析,从而导致此类问题。
事实证明我就是这种情况。我尝试在会话 start、regenerate 和 destroy 上记录消息,并且使用文件驱动程序会发生重新生成,而使用 memcached 时它甚至不会调用除 session_start()
之外的任何函数。经过一番调查后,我决定重新检查主机并偶然发现 这个AWS 中的指南。事实证明,在问题开始时,第二个节点已添加到我们的 Memcached 集群中,但我们一直在使用配置端点,而没有设置此 自动发现。我根本不确定设置是如何工作的。因此,我将 $config['sess_save_path']
更改为其中一个节点的端点,问题就消失了。在我安装和设置所需的模块之前,并且在节点未更改的情况下,此解决方案应该有效。