Memadam Cache NGINX Meletakkan Ralat Nyahpaut Kritikal dalam Log Ralat

Maklumat dalam pos ini adalah berdasarkan kepada caching FastCGI pada NGINX 1.4.6 yang berjalan di Ubuntu Server 14.04 x64. Ia mungkin sah atau tidak sah untuk versi lain.

(Kemaskini 2025: Dalam tempoh antara saya menulis pos asal ini dan sekarang, banyak yang telah berubah. Pelayan lebih pantas dan murah, jadi saya sebenarnya tidak mengesyorkan pendekatan yang diterangkan dalam pos ini di mana saya cuba menguruskan tamat tempoh cache hanya untuk menyelamatkan beberapa generasi kandungan dinamik tambahan. Saya akan meninggalkan kandungan ini di sini untuk rujukan masa depan dan sekiranya seseorang benar-benar memerlukannya atas apa jua alasan. Saya belum mengesahkan bahawa ini masih berfungsi untuk versi NGINX yang terkini, namun saya rasa ia masih berfungsi).

Selepas memigrasi beberapa laman dari Apache ke NGINX, saya sangat menyukai kemampuan caching terbina dalamnya, yang berfungsi dengan sangat baik di bawah kebanyakan keadaan tanpa banyak campur tangan daripada saya.

Namun, untuk salah satu laman tersebut, saya benar-benar memerlukan keupayaan untuk membersihkan cache (secara penuh dan membuang entri individu) sendiri. Edisi komuniti percuma NGINX hanya menyokong tamat tempoh cache berasaskan masa (iaitu, anda boleh menetapkannya untuk memeriksa jika sesuatu telah berubah selepas sejam, sehari, dll.). Tetapi bagaimana jika tidak ada cara yang boleh dipercayai untuk menentukan terlebih dahulu bila sesuatu sumber akan berubah? Contohnya, saya tidak tahu jika ia akan mengambil masa sejam, sehari atau setahun sebelum saya kembali dan mengedit sesuatu dalam pos ini – dan mengapa hanya cache selama sejam jika caching selama sehari akan memadai?

Inilah di mana keupayaan untuk membersihkan cache secara manual (atau dengan membiarkan aplikasi web anda memberitahu NGINX bahawa sesuatu perlu dibersihkan) diperlukan. Pihak di sebalik NGINX jelas menyedari keperluan ini kerana ciri ini disokong dalam versi berbayar produk mereka – tetapi walaupun mereka sememangnya berhak untuk menetapkan lesen mereka mengikut cara yang mereka mahu, harga agak tinggi bagi saya apabila fungsi ini adalah satu-satunya ciri berbayar yang benar-benar saya perlukan.

Beruntungnya, ia mendapati bahawa anda hanya boleh memadamkan fail dari direktori cache sendiri dan NGINX akan mengenalinya dan mengambil salinan baru dari backend anda tanpa masalah. Namun, jika anda melakukannya tanpa menyesuaikan konfigurasi anda, kemungkinan besar anda akan melihat banyak mesej yang serupa dengan ini dalam log ralat anda selepas beberapa ketika:

Nampaknya ralat ini berlaku apabila NGINX sendiri cuba untuk memadamkan entri cache selepas masa yang ditetapkan oleh parameter inactive pada arahan fastcgi_cache_path. Lalai untuk ini hanya 10 minit, tetapi anda boleh menetapkannya kepada nilai yang anda mahu. Jika anda menetapkannya kepada, katakanlah, 10 tahun, kemungkinan besar anda belum memulakan semula pelayan pada masa itu, jadi indeks kunci dalam memori akan telah dipadamkan pada masa itu. Jika anda melakukan ini, anda perlu memastikan bahawa anda membersihkan cache sendiri, NGINX tidak lagi akan melakukannya untuk anda.

Saya rasa sangat pelik bahawa ia dianggap sebagai ralat kritikal bahawa entri cache tidak boleh dipadamkan kerana ia tidak wujud. Hakikat bahawa klasifikasi keterukannya begitu tinggi bermaksud bahawa ia mustahil untuk dibuang hanya dengan mengabaikan entri log di bawah ambang tertentu. Sebaik sahaja salinan baru diambil dari backend, entri itu akan wujud semula, jadi ini seharusnya menjadi amaran sahaja, pada pendapat saya.

Sekarang, jika entri cache tidak dapat dipadamkan kerana masalah dengan kebenaran atau sesuatu yang ketiga, itu akan menjadi ralat kritikal, kerana ia mungkin membuat NGINX terus menyajikan kandungan yang di-cache lama selepas masa tamat tempohnya, tetapi proses pembersihan nampaknya tidak membuat perbezaan ini.