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']
更改為其中一個節點的端點,問題就消失了。在我安裝和設定所需的模組之前,並且在節點未更改的情況下,此解決方案應該有效。