Mari analisa konsistensi cache Redis, penembusan cache, pecahan cache dan isu salji cache bersama-sama

Artikel ini membawa anda pengetahuan yang berkaitan tentang Redis, yang terutamanya memperkenalkan ketekalan cache, penembusan cache, pecahan cache, salji cache dan penyegerakan tulis bagi data cache. Mari kita lihat isu ketekalan DB Saya harap ia akan membantu semua orang.

Cadangan berkaitan: "Analisis masalah storan kunci panas dalam Redis dan bercakap tentang penyelesaian kepada pengecualian cache"

(1) Masalah konsistensi ketidaksahihan cache

Penggunaan cache am ialah: baca cache dahulu, dan jika ia tidak wujud, baca dari DB, dan kemudian Hasilnya ditulis ke cache pada kali berikutnya data dibaca, data boleh diperolehi terus dari cache. [Cadangan berkaitan: Tutorial Video Redis]

Pengubahsuaian data adalah untuk membatalkan data cache secara langsung, dan kemudian mengubah suai kandungan DB untuk mengelakkan pengubahsuaian DB berjaya, tetapi tembolok data tidak dikosongkan kerana rangkaian atau masalah lain , mengakibatkan data kotor. Tetapi ini masih tidak dapat mengelakkan penjanaan data kotor Dalam senario serentak: Anggapkan bahawa perniagaan mempunyai sejumlah besar permintaan baca dan ubah suai untuk data Key:Hello Value:World. Thread A membaca Key:Hello dari OCS, mendapat hasil Not Found, mula meminta data daripada DB, dan mendapat data Key:Hello Value:World seterusnya, ia bersedia untuk menulis data ini ke OCS, tetapi sebelum menulis ke OCS (network , Menunggu CPU boleh menyebabkan kelajuan pemprosesan thread A menjadi perlahan.) Satu lagi thread B meminta untuk mengubah suai data Key:Hello Value:OCS dan mula-mula melakukan tindakan cache penolakan (kerana thread B tidak tahu sama ada data ini wujud , jadi ia secara langsung melakukan operasi tidak sah). OCS berjaya memproses permintaan yang tidak sah. Kembali ke utas A untuk meneruskan menulis OCS dan tulis Key:Hello Value:World ke dalam cache Tugasan Thread A juga berjaya mengubah suai kandungan data DB kepada Key:Hello Value:OCS. Untuk menyelesaikan masalah ini, OCS telah mengembangkan protokol Memcached (awan awam tidak lama lagi akan menyokongnya) dan menambah antara muka deleteAndIncVersion. Antara muka ini sebenarnya tidak memadamkan data, tetapi melabelkan data untuk menunjukkan bahawa ia telah tamat tempoh, dan meningkatkan nombor versi data jika data tidak wujud, NULL ditulis, dan nombor versi data rawak juga dijana. Penulisan OCS menyokong perbandingan atom nombor versi: dengan mengandaikan nombor versi masuk adalah konsisten dengan nombor versi data yang disimpan oleh OCS atau data asal tidak wujud, penulisan dibenarkan, jika tidak pengubahsuaian ditolak.

Kembali ke tempat kejadian sebentar tadi: Thread A membaca Key:Hello daripada OCS, mendapat hasil Not Found, mula meminta data daripada DB dan mendapatkan data Key:Hello Value:World, kemudian bersedia untuk menulis kepada OCS Untuk sekeping data ini, maklumat nombor versi lalai kepada 1 sebelum A menulis kepada OCS, satu lagi thread B memulakan tindakan untuk mengubah suai data Key:Hello Value:OCS pertama kali melakukan tindakan padam cache permintaan deleteAndIncVersion dan menjana versi rawak No. 12345 (bersetuju lebih besar daripada 1000). Kembali ke utas A dan teruskan menulis kepada OCS, meminta untuk menulis Key:Hello Value:World Pada masa ini, sistem cache mendapati bahawa maklumat nombor versi masuk tidak sepadan (1! = 12345), penulisan gagal dan tugas thread A tamat ;Thread B juga berjaya mengubah suai kandungan data DB kepada Key:Hello Value:OCS.

Pada masa ini, data dalam OCS ialah Key:Hello Value:NULL Version:12345; data dalam DB ialah Key:Hello Value:OCS dalam tugasan baca seterusnya, data dalam DB akan dicuba semula untuk menulis dalam OCS.

(2) Isu penyegerakan tulis data cache dan konsistensi DB

Apabila skala tapak web berkembang dan kebolehpercayaan bertambah baik, ia akan menghadapi penggunaan berbilang IDC. Setiap IDC mempunyai sistem DB dan cache bebas, dan ketekalan cache telah menjadi isu yang menonjol.

Pertama sekali, untuk memastikan kecekapan tinggi, sistem cache akan menghalang IO cakera, walaupun ia menulis BINLOG sudah tentu, demi prestasi, sistem cache hanya boleh memadam secara serentak dan tidak tulis secara serentak, jadi penyegerakan cache secara amnya akan diutamakan daripada ketibaan penyegerakan DB (Lagipun, sistem cache jauh lebih cekap), maka akan ada senario di mana tiada data dalam cache dan data lama dalam DB. Pada masa ini, terdapat permintaan perniagaan untuk data, dan cache baca Tidak Ditemui Data lama yang dibaca daripada DB dan dimuatkan ke dalam cache masih merupakan data lama Apabila penyegerakan data DB tiba, hanya DB yang dikemas kini. dan data kotor yang dicache tidak boleh dibersihkan.

Seperti yang dapat dilihat daripada situasi di atas, punca ketidakkonsistenan ialah sistem heterogen tidak boleh menyegerak secara kolaboratif Ia tidak dapat menjamin bahawa data DB disegerakkan terlebih dahulu dan data cache disegerakkan kemudian. Jadi kita perlu mempertimbangkan bagaimana sistem cache menunggu untuk penyegerakan DB, atau bolehkah kedua-duanya berkongsi mekanisme penyegerakan? Penyegerakan cache juga bergantung pada DB BINLOG yang merupakan penyelesaian yang boleh dilaksanakan.

DB dalam IDC1 disegerakkan kepada DB dalam IDC2 melalui BINLOG Dalam kes ini, pengubahsuaian data IDC2-DB juga akan menjana BINLOGnya sendiri Penyegerakan data cache boleh dilakukan melalui IDC2-DB BINLOG. Selepas modul penyegerakan cache menganalisis BINLOG, ia membatalkan kekunci cache yang sepadan dan menukar penyegerakan daripada selari kepada bersiri, memastikan pesanan itu.

(3) Penembusan cache (DB mengalami trafik pertanyaan yang tidak perlu)

Kaedah 1: Ia adalah penapis Bloom. Ia adalah algoritma probabilistik dan struktur data yang sangat cekap ruang, digunakan untuk menentukan sama ada elemen berada dalam set (serupa dengan Hashset). Terasnya ialah vektor binari panjang dan satu siri fungsi cincang. Laksanakan penapis mekar menggunakan jambu batu Google. 1) Terdapat kadar salah pengiraan Apabila bilangan elemen yang disimpan meningkat, kadar salah pengiraan juga meningkat 2) Dalam keadaan biasa, elemen tidak boleh dipadamkan daripada penapis Bloom 3) Proses menentukan panjang tatasusunan dan bilangan fungsi cincang adalah kompleks, dan pengedaran Apakah senario penggunaan penapis Long? 1) Penapisan alamat spam (bilangan alamat adalah besar) 2) Penyahduplikasi alamat URL Crawler 3) Menyelesaikan masalah pecahan cache

Kaedah 2: Simpan hasil kosong dan tetapkan masa untuk hasil kosong

(4) Cache avalanche (cache ditetapkan pada masa tamat tempoh yang sama, menyebabkan puncak banjir DB)

Kaedah 1: Kebanyakan pereka sistem mempertimbangkan untuk menggunakan kunci atau baris gilir untuk memastikan cache tunggal Benang (proses) menulis untuk mengelakkan sebilangan besar permintaan serentak jatuh pada sistem storan asas semasa kegagalan

Kaedah 2: Nilai rawak masa kegagalan

(5) Pecahan cache ( titik panas) Kunci, longsor kecil yang disebabkan oleh sebilangan besar permintaan baca serentak)

Apabila cache tamat tempoh pada masa tertentu, terdapat sejumlah besar serentak permintaan untuk Kunci ini pada masa ini Permintaan ini Jika didapati bahawa cache telah tamat tempoh, data biasanya akan dimuatkan dari DB bahagian belakang dan ditetapkan semula ke cache Pada masa ini, permintaan serentak yang besar boleh mengatasi dengan serta-merta DB hujung belakang

Kaedah 1: 1. Gunakan cache yang diedarkan Untuk menyokong kunci mutex, tetapkan kunci mutex Apabila operasi kembali berjaya, operasi DB muatkan akan dilakukan dan cache akan diset semula. Dengan kata lain, muatkan DB hanya akan diproses oleh satu utas.

Kaedah 2: Gunakan kunci mutex terlebih dahulu: tetapkan nilai tamat masa (masa tamat1) dalam nilai, tamat masa1 adalah lebih kecil daripada tamat masa memcache sebenar (masa tamat2) Apabila tamat masa1 dibaca daripada cache Apabila anda mendapati ia telah tamat tempoh , teruskan masa tamat1 dan tetapkannya semula ke cache Kemudian muatkan data dari pangkalan data dan tetapkannya ke cache Ini meningkatkan pencerobohan kod perniagaan dan meningkatkan kerumitan pengekodan. Tidak pernah tamat tempoh": Dari perspektif redis, memang tiada masa tamat tempoh ditetapkan, yang memastikan tiada masalah tamat tempoh kunci tempat liputan, iaitu, ia tidak tamat tempoh "secara fizikal". Dari perspektif fungsi, jika ia tidak tamat tempoh. tamat tempoh, maka tidak. Adakah ia statik? Jadi kami menyimpan masa tamat tempoh dalam nilai yang sepadan dengan kunci Jika didapati telah tamat tempoh, cache dibina melalui benang tak segerak, iaitu, tamat tempoh "logik". >

(6) Masalah kepenuhan cache dan kehilangan data biasa dalam sistem cache

Perlu berdasarkan analisis perniagaan tertentu Biasanya kami menggunakan strategi LRU untuk mengendalikan limpahan, dan Redis Strategi kegigihan RDB dan AOF untuk memastikan situasi tertentu

Video Pengaturcaraan

Atas ialah kandungan terperinci Mari analisa konsistensi cache Redis, penembusan cache, pecahan cache dan isu salji cache bersama-sama. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!