Ich entwickle ein Langzeitprojekt mit dem CodeIgniter 3-Framework. Seit mehreren Monaten haben wir Probleme mit zufälligen Sitzungsverlusten. Ich habe die Framework-Dateien auf die neueste Version (3.1.13) aktualisiert. Es sieht so aus, als ob das Problem dadurch auf dem Entwicklungsserver behoben wurde, aber in der Produktion besteht es immer noch. Aber mir ist aufgefallen, dass dies jetzt nur dann passiert, wenn die Antwort ein neues Sitzungscookie sendet, was passiert, wenn die Sitzungs-ID neu generiert wird. Wenn ich $config['sess_time_to_update'] ändere, wird die erforderliche Zeit korrekt angezeigt.
Der Unterschied zwischen einem Entwicklungsserver und einem Produktionsserver ist der Sitzungstreiber – es handelt sich um eine Datei auf dem Entwicklungsserver, während wir in der Produktion Memcached verwenden. Also habe ich ein Experiment durchgeführt und den Treiber auf Datei umgestellt, und die Sitzung ging nicht mehr verloren. Ich habe auch versucht, es mit dem Redis-Treiber einzurichten, und auch das hat keine Probleme verursacht. Es muss also ein Problem mit dem Memcached-Treiber sein. Aber ich möchte nicht gegen ein anderes eintauschen. Es gibt keine Fehler in den Protokollen. Ich habe auch überprüft, ob die Datei php.ini und die zwischengespeicherten Variablen beide Standardwerte haben.
CodeIgniter v3.1.13, PHP 7.4.3, Amazon ElastiCache für Memcached
Dies ist die Konfiguration:
$config['sess_driver'] = 'memcached'; $config['sess_cookie_name'] = 'ci_session'; $config['sess_expiration'] = 14400; $config['sess_save_path'] = 'host.com:11211'; $config['sess_match_ip'] = FALSE; $config['sess_time_to_update'] = 300; $config['sess_regenerate_destroy'] = FALSE;
Für Ideen, wo Sie suchen oder was Sie überprüfen sollten, wären wir sehr dankbar.
查看此答案。显然，如果您将会话的最大过期时间设置为大于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数据库来代替会话存储，我认为生产环境上的性能不会有太大不同在这两种情况下。如果您使用的是 AWS ElastiCache Memcached 集群，请检查您在配置中使用的终端节点
$config['sess_save_path']。一种选择是使用配置端点（其中包含.cfg.），另一种选项是单个节点端点（包含.0001.、.0002.等）。如果您使用配置终端节点，请确保启用了自动发现（需要在服务器上进行额外安装 -适用于 PHP 的 ElastiCache 集群客户端）。如果不启用，您的节点将无法正确解析，从而导致此类问题。事实证明我就是这种情况。我尝试在会话start、regenerate和destroy上记录消息，并且使用文件驱动程序会发生重新生成，而使用 memcached 时它甚至不会调用除
session_start()之外的任何函数。经过一番调查后，我决定重新检查主机并偶然发现这个AWS 中的指南。事实证明，在问题开始时，第二个节点已添加到我们的 Memcached 集群中，但我们一直在使用配置端点，而没有设置此自动发现。我根本不确定设置是如何工作的。因此，我将$config['sess_save_path']更改为其中一个节点的端点，问题就消失了。在我安装和设置所需的模块之前，并且在节点未更改的情况下，此解决方案应该有效。