Sesi CodeIgniter 3 hilang apabila menjana semula ID sesi menggunakan pemacu Memcached sahaja

Question

Saya sedang membangunkan projek jangka panjang menggunakan rangka kerja CodeIgniter 3. Selama beberapa bulan kami telah mengalami masalah dengan sesi yang hilang secara rawak. Saya telah mengemas kini fail rangka kerja kepada versi terkini (3.1.13). Nampaknya ini membetulkan isu pada pelayan pembangunan, tetapi dalam pengeluaran ia masih wujud. Tetapi saya perhatikan bahawa sekarang ini hanya berlaku apabila respons menghantar kuki sesi baharu, yang berlaku apabila id sesi dijana semula. Apabila saya menukar $config['sess_time_to_update'] ia mencerminkan masa yang diperlukan dengan betul.

Perbezaan antara pelayan pembangunan dan pelayan pengeluaran ialah pemacu sesi - ia adalah fail pada pelayan pembangunan, manakala dalam pengeluaran kami menggunakan memcached. Jadi saya melakukan percubaan dan menukar pemacu ke fail dan sesi itu tidak lagi hilang. Saya juga cuba menyediakannya dengan pemandu Redis dan itu tidak menyebabkan masalah sama ada. Jadi ia mesti menjadi masalah dengan pemandu Memcached. Tetapi saya tidak mahu berdagang dengan yang lain. Tiada ralat dalam log. Saya juga menyemak bahawa fail php.ini dan pembolehubah memcached kedua-duanya dengan nilai lalai.

CodeIgniter v3.1.13, PHP 7.4.3, Amazon ElastiCache untuk Memcached

Ini ialah konfigurasi:

$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'] = SALAH;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = SALAH;

Sebarang idea di mana hendak dilihat atau perkara yang hendak diperiksa amatlah dihargai.

Answer 1

Semak jawapan ini. Nampaknya masalah ini boleh berlaku jika anda menetapkan masa tamat maksimum sesi menjadi lebih besar daripada had tamat memcached. Dalam siaran itu, OP menyelesaikan masalah dengan membetulkan pembolehubah konfigurasi berikut, anda boleh mencuba:

define('SESSION_TIME_OUT', x);
ini_set('session.gc_maxlifetime', SESSION_TIME_OUT);
ini_set('session.cache_expire', SESSION_TIME_OUT);
session_start();

Pilihan lain ialah mengalih keluar pangkalan data memcached 并使用内存驻留 sqlite3 dan menggantikannya dengan stor sesi, saya tidak fikir prestasi pada pengeluaran akan jauh berbeza dalam mana-mana kes.

Answer 2

Jika anda menggunakan gugusan AWS ElastiCache Memcached, semak titik akhir yang anda gunakan dalam konfigurasi anda $config['sess_save_path']。一种选择是使用配置端点（其中包含 .cfg.），另一种选项是单个节点端点（包含 .0001.、.0002. dsb.). Jika anda menggunakan titik akhir konfigurasi, pastikan autodiscovery didayakan (memerlukan pemasangan tambahan pada pelayan - ElastiCache Cluster Client untuk PHP). Jika tidak didayakan, nod anda tidak akan diselesaikan dengan betul, menyebabkan isu seperti ini.

Ternyata ini berlaku untuk saya. Saya cuba mengelog mesej pada sesi mulakan, hasilkan semula dan musnahkan dan dengan pemacu fail penjanaan semula berlaku, manakala dengan memcached ia tidak memanggil apa-apa selain session_start() sebarang fungsi Selain itu . Selepas beberapa siasatan, saya memutuskan untuk menyemak semula hos dan terjumpa Panduan ini dalam AWS session_start() 之外的任何函数。经过一番调查后，我决定重新检查主机并偶然发现 这个AWS 中的指南。事实证明，在问题开始时，第二个节点已添加到我们的 Memcached 集群中，但我们一直在使用配置端点，而没有设置此 自动发现。我根本不确定设置是如何工作的。因此，我将 $config['sess_save_path']. Ternyata apabila isu itu bermula, nod kedua telah ditambahkan pada kelompok Memcached kami, tetapi kami telah menggunakan titik akhir konfigurasi tanpa menetapkan Penemuan automatik

. Saya tidak pasti bagaimana persediaan berfungsi sama sekali. Jadi saya menukar $config['sess_save_path'] kepada titik akhir salah satu nod dan masalah itu hilang. Penyelesaian ini harus berfungsi sehingga saya memasang dan menyediakan modul yang diperlukan, dan selagi nod tidak berubah. 🎜