Temu duga Backend: Bagaimanakah anda mereka bentuk kontrak cache stale-while-revalidate yang selamat?

Arahan dan persekitaran

Anda mengendalikan GET /catalog di belakang CDN dan cache aplikasi. Origin boleh menjadi perlahan semasa pelaksanaan (deploy), tetapi pelanggan lebih suka melihat katalog yang sedikit lapuk berbanding halaman kosong. Reka bentuk pengepala cache dan laluan pengesahan semula sambil memastikan data penyewa (tenant) kekal terasing dan kesegaran boleh diukur.

Anggap respons katalog adalah awam bagi setiap penyewa, penulisan melalui origin, dan perubahan harga kecemasan mesti dipaparkan dengan cepat. Jawapan mesti membezakan antara sandaran ketersediaan dengan kebenaran untuk menyajikan status sensitif.

Perkara yang diuji oleh penemu duga

• Sama ada anda memahami kesegaran, keusangan, pengesahan semula dan dasar stale-if-error yang berasingan.
• Sama ada kunci cache berbeza mengikut penyewa, kebenaran, lokaliti (locale) dan perundingan kandungan.
• Sama ada ralat cache (misses) serentak mencetuskan satu permintaan origin atau menyebabkan thundering herd.
• Sama ada pengendali boleh membatalkan penyajian data usang dan membuktikan kesegaran dengan metrik.

Soalan penjelasan sebelum menjawab

1. Adakah respons ini awam, mengikut skop penyewa, atau khusus untuk pengguna? Data peribadi tidak boleh dikongsi oleh CDN sama sekali.
2. Apakah usia maksimum yang diterima untuk bacaan normal dan semasa gangguan origin? Ini menjadi tetingkap kesegaran dan keusangan yang berasingan.
3. Bolehkah perubahan harga atau kebenaran membatalkan objek serta-merta? Jika ya, tambahkan pembersihan (purge) atau kunci berversi dan bukannya mempercayai TTL semata-mata.
4. Adakah pengesah (validators) tersedia? ETag atau Last-Modified mengubah pengambilan semula penuh kepada pengesahan semula bersyarat.

Kerangka jawapan 30 saat

"Saya menetapkan tetingkap segar, tetingkap stale-while-revalidate yang terhad, dan tetingkap stale-if-error yang berasingan. Kunci cache merangkumi setiap perwakilan dan sempadan kebenaran; data khusus pengguna adalah peribadi. Hit usang mengembalikan respons dengan pantas dan mencetuskan satu permintaan bersyarat di latar belakang, manakala ralat serentak digabungkan (coalesced). Perubahan kecemasan membersihkan (purge) atau membuat versi kunci. Metrik mendedahkan usia, hasil pengesahan semula, penggunaan stale-if-error dan ujian kebocoran rentas penyewa, dan pengendali boleh melumpuhkan penyajian data usang."

Analisis mendalam langkah demi langkah

1. Asingkan kesegaran daripada ketersediaan

max-age mentakrifkan berapa lama respons yang disimpan kekal segar. stale-while-revalidate membenarkan cache menyajikan respons usang untuk tempoh terhad semasa ia mengesahkan semula di latar belakang. stale-if-error ialah peruntukan ketersediaan berasingan untuk ralat origin. Kedua-dua arahan tidak menjadikan data usang itu betul, dan respons dengan must-revalidate atau peraturan no-cache yang berkenaan tidak boleh digunakan semula sewenang-wenangnya.

Katalog awam mungkin menggunakan tetingkap segar yang pendek dan tetingkap usang terhad yang lebih panjang. Titik akhir kebenaran, baki akaun atau harga kecemasan harus menggunakan private, no-store, laluan purge, atau dasar yang jauh lebih ketat. Risiko perniagaan yang menentukan tetingkap tersebut, bukan tetapan lalai cache.

2. Bina kunci cache dan kontrak respons yang selamat

Kunci mesti menyertakan penyewa, lokaliti, pengekodan dan sebarang pengepala permintaan yang dinamakan oleh Vary. Jangan sekali-kali membiarkan respons yang disahkan masuk ke dalam cache kongsi melainkan perwakilan tersebut secara eksplisit bersifat awam dan bebas daripada kebenaran. Respons boleh menyatakan dasarnya dengan jelas:

Cache-Control: public, max-age=30, stale-while-revalidate=120, stale-if-error=600
Vary: Accept-Encoding, Accept-Language, X-Tenant-ID
ETag: "catalog-tenant-7-v42"

Pelayan mesti mengesahkan bahawa X-Tenant-ID diperoleh daripada laluan atau hos yang disahkan, bukan nilai klien yang sewenang-wenangnya. Jika sempadan penyewa tidak dapat diwakili dengan selamat dalam kunci, lumpuhkan caching kongsi.

3. Sahkan semula tanpa thundering herd

Apabila hit usang berlaku, kembalikan kandungan yang disimpan dan masukkan satu pengesahan semula ke dalam giliran bagi setiap kunci cache. Gunakan kunci (lock) pendek atau pemetaan single-flight supaya sepuluh ribu pembaca tidak membuat sepuluh ribu panggilan origin. Pengesah semula menghantar If-None-Match; 304 Not Modified memperbaharui kesegaran tanpa menggantikan kandungan, manakala 200 baharu menggantikan objek dan pengesah.

Jika pengesahan semula gagal dengan ralat sementara, simpan objek lama hanya dalam batas stale-if-error. Rekod kegagalan dan usia. Jangan lanjutkan tetingkap usang tanpa had dengan menetapkan semula pemasa secara berulang-ulang.

4. Jadikan pembatalan eksplisit

TTL ialah jaring keselamatan, bukan kawalan kecemasan. Perubahan harga atau kebenaran harus menerbitkan peristiwa pembatalan berversi atau membersihkan (purge) kunci yang terjejas. Laluan penulisan boleh mengesahkan versi baharu sebelum menerbitkan peristiwa; pengguna mestilah idempoten dan boleh dimainkan semula (replayable). Jika proses purge tidak dapat disahkan, API boleh melampirkan tempoh must-revalidate yang pendek atau memintas cache untuk penyewa yang terjejas.

5. Ukur dan kendalikan dasar

Jejak usia respons, nisbah hit segar, nisbah hit stale-while-revalidate, kiraan stale-if-error, kependaman pengesahan semula, kadar 304, kadar ralat origin, perbalahan kunci (lock contention) dan kardinaliti kunci cache. Berikan amaran apabila usia usang menghampiri maksimum, lonjakan stale-if-error yang tidak dijangka dan kegagalan ujian rentas penyewa.

Sediakan bendera ciri (feature flag) atau suis pemati (kill switch) peringkat laluan untuk menghentikan penyajian respons usang. Uji cold miss, hit usang serentak, tamat masa origin, perubahan pengesah, perlumbaan purge (purge races), pengepala penyewa, varian lokaliti dan kemas kini harga kecemasan. Penentu ujian (test oracle) ialah kontrak kesegaran dan pengasingan, bukan sekadar angka kependaman yang lebih rendah.

Contoh jawapan berkualiti tinggi

Saya akan bermula dengan mengklasifikasikan data. Katalog awam dalam skop penyewa boleh mempunyai max-age=30, stale-while-revalidate=120, dan stale-if-error=600 yang dijustifikasikan secara berasingan; data khusus pengguna atau kebenaran harus bersifat peribadi atau tidak dicache. Kunci menyertakan dimensi penyewa dan perwakilan, dan respons membawa pengesah.

Apabila hit usang berlaku, saya menyajikan kandungan dan menjalankan satu pengesahan semula bersyarat bagi setiap kunci. 304 memperbaharui kesegaran, dan 200 menggantikan objek. Kegagalan origin sementara boleh menggunakan tetingkap stale-if-error yang terhad, tidak sekali-kali menggunakan pemasa yang ditetapkan semula tanpa henti. Penulisan menerbitkan peristiwa purge atau versi yang idempoten untuk perubahan mendesak. Saya memantau usia, penggunaan data usang, hasil pengesahan semula dan pengasingan penyewa, bersama-sama suis pemati untuk penyajian data usang.

Kesilapan lazim

• Kesilapan: Menggunakan stale-while-revalidate pada data akaun atau kebenaran → Sebab ia gagal: respons usang yang pantas boleh mendedahkan keputusan kebenaran yang tidak sah → Penyelesaian: pastikan data sensitif kekal peribadi atau tidak dicache.
• Kesilapan: Meniadakan penyewa atau lokaliti daripada kunci → Sebab ia gagal: satu perwakilan boleh disajikan kepada sempadan yang lain → Penyelesaian: terbitkan dan uji setiap dimensi kunci.
• Kesilapan: Memperbaharui pemasa usang selepas setiap pengesahan semula yang gagal → Sebab ia gagal: data daripada gangguan boleh kekal selama-lamanya → Penyelesaian: kuat kuasakan tarikh akhir keusangan mutlak.
• Kesilapan: Menghantar satu permintaan origin bagi setiap pembaca data usang → Sebab ia gagal: lonjakan pembacaan data usang menjadi thundering herd → Penyelesaian: gunakan pengesahan semula single-flight bagi setiap kunci.
• Kesilapan: Menganggap TTL sebagai pembatalan kecemasan → Sebab ia gagal: perubahan mendesak perlu menunggu tarikh luput → Penyelesaian: terbitkan peristiwa purge atau pemversian dan sahkan penyelesaiannya.

Soalan susulan dan jawapan

Mengapa tidak menggunakan stale-if-error sahaja?

Ia hanya membantu apabila permintaan origin mengalami ralat. stale-while-revalidate menambah baik kependaman normal dengan menyajikan respons lama sementara penyegaran yang berjaya sedang berjalan. Kedua-duanya menyelesaikan keadaan yang berbeza dan memerlukan batasan serta metrik yang berasingan.

Apakah yang berlaku apabila pengesah berubah semasa pembersihan (purge)?

Buat versi objek dan pastikan peristiwa purge adalah idempoten. Pengesahan semula yang melihat pengesah lama tidak boleh menimpa versi yang lebih baharu; bandingkan versi objek atau cap masa komit sebelum menggantikan entri cache. Jika susunan tidak pasti, pintas cache seketika untuk kunci tersebut.

Bolehkah CDN mencache respons yang disahkan dengan Vary: Authorization?

Secara teknikalnya ia boleh dilakukan dalam beberapa sistem, tetapi ia merupakan reka bentuk berisiko tinggi. Lebih baik gunakan private atau perwakilan awam penyewa yang eksplisit. Jika cache kongsi tidak dapat dielakkan, buktikan ketepatan kunci, kebebasan kebenaran, pembersihan (purge) dan pengasingan rentas penyewa dengan ujian integrasi serta kawalan operasi.