Custom cache key - CDN - Alibaba Cloud Documentation Center

Mengonfigurasi custom cache key memungkinkan Anda membuat aturan untuk menghasilkan kunci cache berdasarkan bagian-bagian berbeda dari permintaan HTTP, seperti URI, parameter permintaan, header HTTP, atau variabel kustom. Hal ini menyatukan permintaan untuk file yang sama ke dalam satu kunci cache yang seragam, sehingga meningkatkan rasio hit cache, mengurangi pengambilan asal (origin fetches), serta menurunkan waktu respons dan konsumsi bandwidth.

Perbandingan dan pemilihan fitur

Konflik antara custom cache key dan parameter filtering: Mengaktifkan parameter filtering akan menghapus semua parameter yang mengikuti karakter ? dari URL. Hal ini menyebabkan aturan parameter permintaan pada custom cache key Anda gagal berjalan. Sebelum menggunakan custom cache key, nonaktifkan terlebih dahulu parameter filtering.

Fitur custom cache key lebih komprehensif dan direkomendasikan dibandingkan parameter filtering. Tabel berikut membandingkan konfigurasinya.

Kasus penggunaan	Parameter filtering	Custom cache key
Abaikan semua parameter permintaan dalam kunci cache	Atur Ignore Parameters ke Yes, dan biarkan bidang Retain Specified Parameters kosong.	Tambahkan aturan parameter permintaan: Action: Retain Parameter Name: Atur ke nama parameter yang tidak ada, misalnya `example-argument`.
Pertahankan hanya parameter permintaan `key1` dalam kunci cache	Atur Ignore Parameters ke Yes, dan atur Retain Specified Parameters ke `key1`.	Tambahkan aturan parameter permintaan: Action: Retain Parameter Name: key1
Hapus hanya parameter permintaan `key1` dari kunci cache	Atur Remove Specified Parameters ke `key1`.	Tambahkan aturan parameter permintaan: Action: Delete Parameter Name: key1

Rewrite origin parameters: Fitur custom cache key hanya memodifikasi kunci cache dan tidak mengubah URL untuk pengambilan asal (origin fetch). Permintaan origin fetch tetap sama dengan permintaan klien. Untuk memodifikasi parameter permintaan yang dikirim ke origin Anda, gunakan Rewrite origin parameters.
Purge cache: Setelah Anda mengonfigurasi custom cache key, tugas purge by URL mungkin gagal mencocokkan konten yang di-cache. Untuk memastikan purge berhasil, Anda harus menggunakan kunci cache akhir yang dihasilkan oleh aturan Anda sebagai objek yang akan dipurge.

Kasus penggunaan

Penting

Fitur custom cache key tidak memodifikasi URL untuk pengambilan asal (origin fetch). Fitur ini hanya mengubah kunci cache. Permintaan origin fetch tetap sama dengan permintaan asli klien.

Kunci cache adalah ID unik untuk file yang di-cache pada titik kehadiran CDN (POP). Setiap file yang di-cache pada POP memiliki kunci cache yang sesuai. Secara default, kunci cache adalah URL permintaan klien, termasuk semua parameternya.

Kasus penggunaan 1: Menyatukan permintaan

Permintaan klien yang berbeda sering kali menyertakan parameter kompleks dalam URL. Meskipun beberapa permintaan ditujukan untuk file yang sama, POP CDN memperlakukan permintaan dengan parameter URL berbeda sebagai permintaan untuk file yang berbeda. Hal ini mengakibatkan beberapa salinan file yang sama tersimpan dalam cache dan meningkatkan jumlah pengambilan asal.

Anda dapat menggunakan aturan custom cache key untuk menyatukan kunci cache bagi permintaan serupa. Hal ini mengurangi laju pengambilan asal.

Kasus penggunaan 2: Membedakan permintaan

Ketika permintaan klien memiliki URL yang sama, CDN memperlakukannya sebagai permintaan untuk file yang sama. Namun, Anda mungkin ingin menyajikan file berbeda berdasarkan bidang client dalam header HTTP yang membedakan sistem klien. 场景一

Dalam kasus ini, Anda dapat menggunakan custom cache key untuk menambahkan nilai bidang client ke kunci cache. Hal ini menghasilkan kunci cache yang berbeda untuk setiap permintaan. 场景二

Penting

Jika suatu fitur menggunakan Rule Condition dari Rules Engine, prioritas Rule Condition tersebut yang menentukan urutan eksekusi, bukan pengaturan prioritas fitur tersebut.

Prosedur

Login ke CDN console.
Di panel navigasi kiri, klik Domain Names.
Pada halaman Domain Names, temukan nama domain target lalu klik Manage di kolom Actions.
Di panel navigasi domain, klik Cache.

Pada tab Custom Cache Key, klik Configure untuk mengonfigurasi Cache Key.

Parameter	Deskripsi
Rule Condition	Rule Condition mengidentifikasi permintaan berdasarkan berbagai parameter untuk menentukan apakah suatu konfigurasi berlaku untuk permintaan tertentu. Penting Jika suatu aturan menggunakan Rule Condition, prioritas Rule Condition tersebut yang menentukan urutan pencocokan, bukan urutan konfigurasi fitur tersebut. Do not use: Tidak menggunakan Rule Condition. Untuk menambah atau mengedit Rule Condition, kelola melalui Rules Engine.
URIs	Saat URI permintaan klien cocok dengan Source URI dalam konfigurasi, sistem menggunakan Final URI yang dikonfigurasi untuk menggantikan Source URI dalam menghasilkan Cache Key. Final URI yang dikonfigurasi kemudian digunakan untuk menggantikan Source URI dalam membangun Cache Key. Anda dapat mengonfigurasi beberapa kebijakan penggantian URI. Jika terdapat beberapa kebijakan, pencocokan dilakukan secara berurutan dari atas ke bawah. Begitu Source URI ditemukan cocok, sistem menggunakan Final URI yang sesuai untuk melakukan penggantian dan menghentikan pencocokan terhadap kebijakan berikutnya. Source URI: URI yang dimulai dengan garis miring (/) dan tidak menyertakan awalan http:// atau nama domain. Ekspresi reguler `PCRE` didukung. Final URI: URI yang dimulai dengan garis miring (/) dan tidak menyertakan awalan http:// atau nama domain.
Request Parameter	Operasi dilakukan pada parameter dari URL permintaan asli. Anda dapat melakukan operasi Add, Delete, Modify, dan Reserve, dan hasilnya ditambahkan ke Cache Key. Jika Anda mengonfigurasi beberapa operasi, operasi tersebut dieksekusi secara berurutan dari atas ke bawah. Add: Menambahkan parameter permintaan baru ke Cache Key. Misalnya, jika URL asli adalah `http://image.example.com/cat.jpg` dan Anda menambahkan parameter permintaan baru `type=jpg`, maka Cache Key-nya adalah `http://image.example.com/cat.jpg?type=jpg`. Delete: Menghapus parameter yang ditentukan dari URL permintaan asli saat menghasilkan kunci cache. Misalnya, jika URL asli adalah `http://image.example.com/cat.jpg?type=jpg`, dan Anda menghapus parameter `type`, maka kunci cache-nya adalah `http://image.example.com/cat.jpg`. Modify: Memodifikasi parameter tertentu dalam URL permintaan asli saat Cache Key dihasilkan. Misalnya, jika URL asli adalah `http://image.example.com/cat.jpg?type=jpg` dan Anda memodifikasi parameter menjadi `type=png`, maka Cache Key-nya adalah. Reserve: Saat Cache Key dihasilkan, hanya parameter yang ditentukan dari URL permintaan asli yang dipertahankan. Misalnya, jika URL asli adalah `http://image.example.com/cat.jpg?type=jpg&path=image` dan Anda mempertahankan parameter `type`, maka Cache Key-nya adalah `http://image.example.com/cat.jpg?type=jpg`.
HTTP Headers	Menambahkan nilai header HTTP tertentu dari permintaan asli klien ke kunci cache. Anda dapat mengonfigurasi beberapa nama header, dipisahkan dengan spasi. Nilainya ditambahkan ke kunci cache sesuai urutan header yang ditentukan. Misalnya, URL asli adalah `http://image.example.com/cat.jpg`, dan permintaan klien membawa `HTTP header (path:image)`. Jika header permintaan `path` diatur dalam HTTP Headers, maka Cache Key-nya adalah `http://image.example.com/cat.jpgimage`.
Custom Variables	Anda dapat menggunakan ekspresi reguler untuk mencocokkan nilai dari parameter permintaan, header HTTP, parameter cookie, atau Path dalam permintaan asli klien. Saat ditemukan kecocokan, nilai yang sesuai ditambahkan ke kunci cache. Untuk detailnya, lihat Contoh konfigurasi.

Klik OK.

Contoh konfigurasi

URIs

Permintaan untuk http://aliyundoc.com/a/b/image.jpg dan http://aliyundoc.com/a/b/c/image.jpg akan diperlakukan sebagai permintaan untuk file yang sama. Kunci cache untuk file ini adalah http://aliyundoc.com/c/image.jpg. Contoh aturan penulisan ulang URI: tulis ulang Source URI /a/b menjadi Final URI /c, dan tulis ulang Source URI /a/b/c menjadi Final URI /c.

Request Parameter

Permintaan klien untuk http://aliyundoc.com/a/b/image.jpg?delete_par=1&modify_par=1 akan memiliki add_par=1 ditambahkan, delete_par dihapus, dan nilai modify_par diubah menjadi 2 sesuai aturan, menghasilkan kunci cache akhir http://aliyundoc.com/a/b/image.jpg?modify_par=2&add_par=1.

Penting

Jika beberapa operasi dikonfigurasi untuk parameter permintaan yang sama, urutan prioritas operasinya adalah: Add > Delete > Retain > Modify.

Aksi Delete hanya mendukung satu nama parameter. Untuk menghapus beberapa parameter, Anda harus membuat aturan Delete terpisah untuk masing-masing parameter.

HTTP Headers

Nilai header User-Agent dan Accept-Language dari permintaan klien ditambahkan ke Cache Key. Misalnya, jika permintaan untuk http://aliyundoc.com/a/b/image.jpg berisi header User-Agent=Mozilla/5.0 (Linux; X11) dan Accept-Language=en, maka Cache Key untuk permintaan tersebut adalah http://aliyundoc.com/a/b/image.jpgMozilla/5.0(Linux;X11)en. Di kotak teks HTTP HEADER, masukkan bidang header permintaan yang ingin Anda sertakan, seperti User-Agent dan Accept-Language.

Custom Variables

Contoh 1

Nama variabel adalah language, sumbernya adalah Request Header, bidang sumbernya adalah Accept-Language, aturan pencocokannya adalah ([%w]+),([%w]+), dan ekspresi variabelnya adalah $1aa. Contoh konfigurasi variabel kustom: Atur Variable name ke language, pilih Request Header sebagai Source, masukkan Accept-Language sebagai Source field, masukkan ([%w]+),([%w]+) sebagai Match rule, dan masukkan $1aa sebagai Variable expression.

Klien meminta http://aliyundoc.com/a/b/image.jpg dengan header HTTP Accept-Language=en,ch . Aturan pencocokan akan menangkap en dan menetapkannya ke $1 dalam ekspresi variabel. Ekspresi variabel juga menambahkan aa di akhir, menghasilkan nilai variabel enaa dengan alias language. Nilai ini kemudian ditambahkan ke URL untuk membentuk kunci cache akhir: http://aliyundoc.com/a/b/image.jpgenaa.

Catatan

$n dalam ekspresi variabel merujuk pada konten yang ditangkap oleh kelompok dalam tanda kurung ke-n dalam aturan pencocokan. Misalnya, dalam Contoh 1, dengan Accept-Language=en,ch dan aturan pencocokan ([%w]+),([%w]+), $1=en dan $2=ch.

Contoh 2

Nama variabel adalah expired, sumbernya adalah Request Cookie, bidang sumbernya adalah a, aturan pencocokannya adalah [%w]+:(.*), dan ekspresi variabelnya adalah $1. Contoh konfigurasi variabel kustom: - Variable name: expired - Source: Request Cookie - Source field: a - Match rule: [%w]+:(.*) - Variable expression: $1

Klien meminta http://aliyundoc.com/a/b/image.jpg dengan cookie Cookie a=expired_time:12635187. Aturan pencocokan akan menangkap 12635187, menetapkannya ke $1 dalam ekspresi variabel, dan memberinya alias expired. Nilai ini kemudian ditambahkan ke URL untuk membentuk kunci cache akhir: http://aliyundoc.com/a/b/image.jpg12635187.

Contoh 3

Atur baik aturan URI maupun variabel kustom.

URI:

Gabungkan semua permintaan dengan URI yang cocok dengan /abc/.*/abc menjadi /abc. Source URI adalah /abc/.*/abc, dan Final URI adalah /abc.

Variabel Kustom:

Nama variabel adalah testname, sumbernya adalah Path, aturan pencocokannya adalah /abc/xyz/(.*), dan ekspresi variabelnya adalah $1. Nama variabel: testname; Sumber: Path; Aturan pencocokan: /abc/xyz/(.*); Ekspresi variabel: $1

Klien meminta URL http://aliyundoc.com/abc/xyz/abc/image.jpg. Berdasarkan konfigurasi URI, kunci cache digabung menjadi http://aliyundoc.com/abc/image.jpg. Kemudian, berdasarkan konfigurasi variabel kustom, URL ini cocok dengan /abc/xyz/(.*). Pada titik ini, $1 diberi nilai abc/image.jpg dan ditambahkan ke kunci cache, membentuk kunci cache akhir: http://aliyundoc.com/abc/image.jpgabc/image.jpg. Hal ini memungkinkan Anda menggabungkan aturan untuk menerapkan logika caching yang lebih kompleks.

Jika variabel kustom untuk Cache Key tidak ditemukan kecocokannya, ekspresi variabel $1 tidak akan digabungkan ke Cache Key.

Contoh 4

Atur baik Rule Condition maupun variabel kustom untuk menghasilkan kunci cache berbeda bagi permintaan dari klien mobile dan PC.

Mobile Rule Condition:

Header User-Agent berisi salah satu string berikut: *Mobile*,*Android*,*iPhone*,*ipad*.

PC Rule Condition:

Header User-Agent tidak berisi string berikut: *Mobile*,*Android*,*iPhone*,*ipad*.

Mobile custom cache key:

Untuk Rule Condition, pilih Mobile. Untuk Custom Variables, atur Variable Name ke Mobile, Source ke Path, Matching Rule ke /, dan Variable Expression ke +mobile.

PC custom cache key:

Untuk Rule Condition, pilih PC, dan untuk Custom Variables, Variable Name adalah PC, Source adalah Path, Matching Rule adalah /, dan Variable Expression adalah +pc.

Untuk permintaan klien ke http://aliyundoc.com/image.jpg, permintaan tersebut akan cocok dengan aturan custom cache key Mobile atau PC berdasarkan nilai User-Agent. Kunci cache akhir untuk klien Mobile adalah http://aliyundoc.com/image.jpg+mobile, dan kunci cache akhir untuk klien PC adalah http://aliyundoc.com/image.jpg+pc.

FAQ

Hit cache tak terduga dengan token

Jika permintaan dengan token berbeda tetap mengenai cache tanpa origin fetch setelah Anda mengonfigurasi custom cache key, ikuti langkah troubleshooting berikut:

Periksa konfigurasi: Pastikan Anda telah menambahkan header HTTP yang berisi token ke custom cache key, atau Anda telah mengatur waktu kedaluwarsa cache ke 0 detik.
Purge cache: Setelah memodifikasi konfigurasi, Anda harus mengirimkan purge direktori untuk membersihkan cache lama. Refresh URL tidak mendukung karakter wildcard *, sehingga kami merekomendasikan menggunakan purge direktori.
Validasi sisi klien: Bersihkan cache browser atau restart browser lalu coba lagi. Periksa header respons untuk status cache MISS guna memastikan permintaan tidak mengenai cache CDN.
Investigasi backend: Jika header respons menunjukkan MISS tetapi tidak ada log di backend Anda, periksa konfigurasi load balancer backend dan log gateway untuk memastikan permintaan mencapai origin.
Verifikasi izin: Jika Anda tidak dapat mengakses log detail, pastikan akun Anda memiliki izin manajemen untuk domain CDN. Atau, mintalah izin AliyunSupportFullAccess melalui akun utama dan berikan EagleID untuk troubleshooting lebih lanjut.

Diferensiasi cache mobile dan PC tidak efektif

Jika konfigurasi custom cache key Anda untuk klien mobile dan PC tidak berfungsi sebagaimana mestinya, ikuti langkah troubleshooting berikut:

Periksa konflik konfigurasi: Pastikan fitur Parameter Filtering tidak diaktifkan. Fitur ini bertentangan dengan custom Cache Keys dan mencegah konfigurasi berjalan.
Periksa kelengkapan konfigurasi: Pastikan Anda telah mengonfigurasi variabel kustom untuk Mobile dan PC. Ekspresi variabel untuk aturan Mobile harus diatur ke +mobile, dan ekspresi untuk aturan PC harus +pc. Untuk contoh konfigurasi, lihat "Contoh 4" dalam topik ini.
Tunggu propagasi: Setelah mengirimkan konfigurasi, tunggu 5 hingga 10 menit agar konfigurasi tersebar ke seluruh jaringan CDN.
Troubleshooting lebih lanjut: Jika masalah tetap berlanjut setelah memverifikasi langkah-langkah di atas, berikan EagleID dari respons pengujian agar kami dapat memeriksa log CDN untuk investigasi lebih lanjut.

Menggunakan custom cache key tanpa ESA

Ya. Custom cache key adalah fitur caching dasar CDN dan dapat digunakan tanpa mengaktifkan ESA.

Jalur: Login ke CDN console, buka Domain Names, klik Manage untuk nama domain target, pilih Cache di panel navigasi kiri, lalu pada tab Custom Cache Key, klik Configure.

Penting

Jika fitur parameter filtering diaktifkan, Anda harus menonaktifkannya terlebih dahulu. Jika tidak, konfigurasi parameter permintaan dalam custom Cache Key Anda akan menjadi tidak valid.

Custom cache key untuk API dinamis

Tidak. CDN dirancang untuk mempercepat sumber daya statis dan tidak mempercepat API dinamis. Fitur custom cache key mengoptimalkan strategi caching untuk sumber daya statis, seperti dengan menstandarkan parameter URL atau membedakan antar klien, dan tidak cocok untuk skenario caching API dinamis. Untuk akselerasi konten dinamis, pertimbangkan penggunaan DCDN.