Mari kita bincangkan tentang tiga isu caching Redis

Artikel ini membawakan anda pengetahuan yang berkaitan tentang Redis Ia terutamanya memperkenalkan tiga jenis masalah cache, iaitu penembusan cache, pecahan cache dan runtuhan cache saya harap ia berguna kepada semua orang.

Pembelajaran yang disyorkan: Tutorial pembelajaran Redis

1. Aplikasi cache Redis

Dalam senario perniagaan sebenar kami, Redis biasanya digunakan bersama dengan pangkalan data lain untuk mengurangkan tekanan pada pangkalan data bahagian belakang , seperti dengan hubungan pangkalan data MySQL digunakan bersama.

Redis akan cache data yang kerap ditanya dalam MySQL , seperti Hot data, supaya apabila pengguna datang untuk mengakses, mereka tidak perlu bertanya dalam MySQL, tetapi terus mendapatkan data cache dalam Redis, sekali gus mengurangkan tekanan bacaan pada pangkalan data bahagian belakang.

Jika data yang ditanya oleh pengguna tidak tersedia dalam Redis, permintaan pertanyaan pengguna akan dipindahkan ke pangkalan data MySQL Apabila MySQL mengembalikan data kepada klien, ia juga akan cache data dalam dalam Redis, supaya apabila pengguna membaca semula, mereka boleh mendapatkan data terus daripada Redis. Carta alir adalah seperti berikut:

Sudah tentu, kami tidak sentiasa boleh menggunakan Redis sebagai pangkalan data cache. Pelayaran yang lancar, kita akan menghadapi tiga masalah cache biasa:

• Penembusan cache
• 2.1 Pengenalan
• Penembusan Cache bermaknaapabila pengguna menanyakan data tertentu, ia tidak wujud dalam Redis Data ini bermaksud bahawa cache tidak terkena Pada masa ini, permintaan pertanyaan akan dipindahkan ke pangkalan data lapisan kegigihan MySQL. Didapati bahawa data tidak wujud dalam MySQL hanya boleh mengembalikan objek kosong, yang bermaksud bahawa pertanyaan itu gagal. Jika terdapat terlalu banyak permintaan sedemikian, atau jika pengguna menggunakan permintaan sedemikian untuk melakukan serangan berniat jahat, ia akan memberi banyak tekanan kepada pangkalan data MySQL dan bahkan runtuh Fenomena ini dipanggil penembusan cache.

2.2 Penyelesaian

Caching objek kosong Apabila MySQL mengembalikan objek kosong, Redis cache objek dan menetapkan masa tamat tempoh untuknya.

Apabila pengguna memulakan permintaan yang sama sekali lagi,

objek kosong

akan diperoleh daripada cache Permintaan pengguna disekat dalam lapisan cache, dengan itu melindungi pangkalan data bahagian belakang, tetapi Terdapat juga beberapa masalah dengan pendekatan ini Walaupun permintaan tidak boleh memasuki MSQL, strategi ini akan

menduduki ruang cache Redis.

Bloom filter Pertama, pengguna boleh melawati Semua kekunci data tempat liputan disimpan dalam penapis Bloom (juga dipanggil pemanasan cache) Apabila pengguna memintanya, ia akan melalui penapis Bloom terlebih dahulu, Penapis Bloom Ia akan dinilai sama ada yang diminta. kunci wujud

Jika ia tidak wujud, permintaan akan ditolak secara langsung. Jika tidak, pertanyaan akan terus dilaksanakan Pertama, pergi ke cache untuk membuat pertanyaan ke pangkalan data untuk membuat pertanyaan. Berbanding dengan kaedah pertama, menggunakan kaedah penapis

Bloom adalah lebih cekap dan praktikal.

Rajah proses adalah seperti berikut:

Pemanasan awal cache: merujuk kepada proses pemanasan awal cache terlebih dahulu apabila sistem bermula. Data yang berkaitan dimuatkan ke dalam sistem cache Redis. Ini mengelakkan memuatkan data apabila pengguna memintanya.

2.3 Perbandingan penyelesaian

Kedua-dua penyelesaian boleh menyelesaikan masalah penembusan cache, tetapi senario penggunaannya berbeza:

Cache objek kosong: Sesuai untuk senario di mana bilangan kunci untuk data kosong adalah terhad dan kebarangkalian permintaan kunci berulang adalah tinggi.

Penapis Bloom : Sesuai untuk senario di mana kunci data kosong berbeza dan kebarangkalian permintaan kunci berulang adalah rendah.

3. Pecahan cache

3.1 Pengenalan

Pecahan cache merujuk kepada The data yang ditanya oleh pengguna tidak wujud dalam cache, tetapi wujud dalam pangkalan data bahagian belakang Sebab fenomena ini adalah biasanya disebabkan oleh tamat tempoh kunci dalam cache . Sebagai contoh, kunci data panas menerima sejumlah besar akses serentak sepanjang masa Jika kunci tiba-tiba gagal pada masa tertentu, sejumlah besar permintaan serentak akan memasuki pangkalan data bahagian belakang, menyebabkan tekanannya meningkat serta-merta. Fenomena ini dipanggil pecahan cache.

3.2 Penyelesaian

Tukar masa tamat tempoh

Tetapkan data hotspot tidak pernah Luput.

Kunci Teragih

Menggunakan kaedah Kunci Teragih untuk mereka bentuk semula cache Penggunaan kaedah adalah seperti berikut:

• Dikunci: Apabila kami menanyakan data mengikut kunci, kami mula-mula menanyakan cache Jika tidak , penguncian dilakukan melalui kunci yang diedarkan Proses pertama untuk memperoleh kunci memasuki pangkalan data bahagian belakang untuk membuat pertanyaan dan menampan hasil pertanyaan kepada Redis.
• Membuka kunci: Apabila proses lain mendapati bahawa kunci diduduki oleh proses tertentu, mereka memasuki keadaan menunggu Selepas membuka kunci, proses lain mengakses kunci cache mengikut giliran.

3.3 Perbandingan penyelesaian

Tidak pernah luput: Penyelesaian ini tidak mempunyai Tetapan yang sebenar masa tamat sebenarnya menghapuskan siri bahaya yang disebabkan oleh kekunci panas, tetapi akan terdapat ketidakkonsistenan data, dan kerumitan kod akan meningkat.

Mutex lock: Penyelesaian ini agak mudah, tetapi ia mempunyai bahaya tersembunyi tertentu Jika terdapat masalah dengan proses pembinaan cache atau ia mengambil masa yang lama , mungkin terdapat masalah Terdapat risiko kunci dan sekatan kolam benang, tetapi kaedah ini boleh mengurangkan beban storan bahagian belakang dengan lebih baik dan mencapai konsistensi yang lebih baik.

4. Cache avalanche

4.1 Pengenalan

Cache avalanche merujuk kepada kumpulan besar dalam kunci cache tamat tempoh pada masa yang sama, dan jumlah akses data adalah sangat besar pada masa ini, menyebabkan peningkatan mendadak dalam tekanan pada pangkalan data bahagian belakang, malah fenomena ini dipanggil cache avalanche. Ia berbeza daripada pecahan cache. Pecahan cache berlaku apabila kunci tempat liputan tiba-tiba tamat tempoh apabila jumlah konkurensi sangat besar, manakala salji cache berlaku apabila sejumlah besar kunci tamat tempoh pada masa yang sama, jadi ia bukan susunan yang sama. magnitud sama sekali.

4.2 Penyelesaian

Mengendalikan Tamat Tempoh

Cache runtuhan salji dan cache adalah serupa, jadi anda juga boleh menggunakan kaedah

data tempat liputan tidak pernah luput untuk mengurangkan tamat tempoh serentak sejumlah besar kunci. Selain itu, tetapkan masa tamat tempoh rawak untuk kunci untuk mengelakkan tamat tempoh kunci secara berpusat.

redis ketersediaan tinggi

Satu Redis mungkin gagal kerana runtuhan salji, jadi anda boleh menambah beberapa Redis lagi ,

bina kluster, jika satu gagal, yang lain boleh terus bekerja.

Pembelajaran yang disyorkan:

Tutorial pembelajaran Redis

Atas ialah kandungan terperinci Mari kita bincangkan tentang tiga isu caching Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!