Artikel ini membawa anda pengetahuan yang berkaitan tentang Redis, yang terutamanya memperkenalkan cara memastikan ketekalan cache redis dan pangkalan data, termasuk mengemas kini cache dan mengemas kini pangkalan data, dsb. Semoga ia membantu semua orang.

Pembelajaran yang disyorkan: Tutorial pembelajaran Redis

1. Empat strategi penyegerakan:

Ingin memastikan caching Konsisten dengan penulisan berganda pangkalan data, terdapat 4 cara, iaitu, 4 strategi penyegerakan:

1. Kemas kini cache dahulu, kemudian kemas kini pangkalan data
2. Kemas kini pangkalan data dahulu, kemudian kemas kini cache;
3. Daripada 4 strategi penyegerakan ini, apa yang perlu kita bandingkan ialah:
4. Kaedah manakah yang lebih sesuai untuk mengemas kini cache atau memadam cache? Perlukah pangkalan data dikendalikan dahulu atau cache dahulu?

2. Kemas kini cache atau padam cache

Seterusnya, mari analisa sama ada kita perlu mengemas kini cache atau memadam cache.

2.1 Kemas kini cache

Kelebihan

:

Cache dikemas kini dalam masa setiap kali data berubah, jadi kehilangan kurang berkemungkinan berlaku semasa pertanyaan.

Kelemahan:

Mengemas kini cache agak mahal. Jika data perlu menjalani pengiraan yang rumit sebelum ditulis ke cache, kemas kini cache yang kerap akan menjejaskan prestasi pelayan. Jika ini adalah senario perniagaan di mana data ditulis dengan kerap, mungkin tiada perniagaan yang membaca data apabila cache kerap dikemas kini.

2.2 Padam cache

Kelebihan

:

Operasi mudah, tidak kira sama ada operasi kemas kini rumit atau tidak, data dalam cache akan menjadi dipadamkan secara langsung.

Kelemahan:

Selepas memadamkan cache, cache pertanyaan seterusnya akan terlepas dan pangkalan data perlu dibaca semula. Daripada perbandingan di atas, secara umum, memadam cache adalah penyelesaian yang lebih baik.

3 Kendalikan pangkalan data atau cache dahulu Seterusnya, mari analisa sama ada pangkalan data atau cache perlu dikendalikan terlebih dahulu.

Mula-mula, kami akan memadam cache dahulu dan mengemas kini pangkalan data terlebih dahulu, dan membuat perbandingan di

:

3.1 Padam cache dahulu dan kemudian kemas kini pangkalan data
出現(xiàn)失敗

Seperti di atas Gambar menunjukkan masalah yang mungkin berlaku apabila cache dipadamkan dahulu dan kemudian pangkalan data dikemas kini:

Thread A berjaya memadamkan cache, tetapi thread A gagal mengemas kini pangkalan data;

Thread B memadamkan cache daripada cache Baca data daripada cache kerana cache dipadamkan, proses B tidak boleh mendapatkan data daripada cache, dan kemudian membaca data daripada pangkalan data; , kemas kini data dalam pangkalan data gagal, dan benang B berjaya memperoleh data lama daripada pangkalan data, dan kemudian mengemas kini data ke cache.

• Akhirnya, data cache dan pangkalan data adalah konsisten, tetapi ia masih data lama
• 3.2 Kemas kini pangkalan data dahulu dan kemudian padamkan cache

Seperti yang ditunjukkan di atas, pangkalan data dikemas kini dahulu dan kemudian cache dipadamkan apabila

ialah:

Thread A berjaya mengemas kini pangkalan data. , tetapi utas A gagal memadamkan cache;出現(xiàn)失敗

Benang B berjaya membaca cache Memandangkan pemadaman cache gagal, utas B membaca data lama dalam cache.

• Akhirnya, utas A berjaya memadamkan cache dan utas lain mengakses data yang sama dalam cache, yang sama dengan data dalam pangkalan data.
• Akhirnya, data cache dan pangkalan data adalah konsisten, tetapi beberapa urutan akan membaca data lama.
• Selepas perbandingan di atas, kami mendapati bahawa pada masa , adalah mustahil untuk membezakan dengan jelas kaedah mana yang lebih baik: memadam cache dahulu atau mengemas kini pangkalan data dahulu, berfikir bahawa kedua-duanya mempunyai masalah. Kami akan membandingkan kedua-dua kaedah ini kemudian, tetapi di sini kita membincangkan terlebih dahulu bagaimana untuk menyelesaikan masalah yang timbul dalam senario di atas?

Malah, tidak kira kaedah mana yang kami gunakan di atas untuk menyegerakkan cache dan pangkalan data, apabila langkah kedua gagal, adalah disyorkan untuk

menggunakan mekanisme cuba semula untuk menyelesaikan masalah 出現(xiàn)失敗 dua gambar di atas Sudah dicat.

Seterusnya kita akan membandingkan pemadaman cache dahulu dan mengemas kini pangkalan data terlebih dahulu dalam

---

:

---

---

Seperti yang ditunjukkan di atas, cache dipadamkan pertama Kemas kini pangkalan data sekali lagi Kemungkinan masalah dalam 沒有出現(xiàn)失敗時:

• Thread A berjaya memadamkan cache;
• Thread B gagal membaca cache; >Thread B berjaya mengemas kini data lama ke cache;
• Dapat dilihat bahawa kedua-dua langkah proses A berjaya, tetapi disebabkan keselarasan, proses B mengakses cache antara dua langkah ini.
• Hasil akhirnya ialah data lama disimpan dalam cache dan data baharu disimpan dalam pangkalan data, dan kedua-dua data itu tidak konsisten.

Seperti yang ditunjukkan di atas, pangkalan data dikemas kini terlebih dahulu dan kemudian cache dipadamkan dalam

:

---

---

Thread A berjaya mengemas kini pangkalan data;
Thread B berjaya membaca cache; 沒有出現(xiàn)失敗時

Thread A berjaya memadamkan cache.

• Dapat dilihat bahawa
• cache terakhir adalah konsisten dengan data dalam pangkalan data, dan kedua-duanya adalah data terkini
. Tetapi utas B membaca data lama semasa proses ini mungkin terdapat utas lain seperti utas B yang membaca data lama dalam cache antara dua langkah ini, tetapi kerana kelajuan pelaksanaan kedua-dua langkah ini akan menjadi lebih cepat, Jadi kesannya tidak. besar. Selepas dua langkah ini, apabila proses lain membaca data cache, masalah yang serupa dengan proses B tidak akan berlaku.
• Kesimpulan akhir:

Selepas perbandingan, anda akan mendapati bahawa mengemas kini pangkalan data terlebih dahulu dan kemudian memadamkan cache adalah penyelesaian dengan kesan yang kurang. Jika langkah kedua gagal, mekanisme cuba semula boleh digunakan untuk menyelesaikan masalah. 4. Kelewatan pemadaman berganda

Kami menyebut di atas bahawa

jika cache dipadamkan dahulu dan kemudian pangkalan data dikemas kini

, ia mungkin menyebabkan masalah walaupun terdapat tiada kegagalan dalam data

. Jika dalam aplikasi sebenar, kita perlu memilih kaedah ini kerana pertimbangan tertentu, adakah cara untuk menyelesaikan masalah ini? Jawapannya ya, iaitu menggunakan strategi pemadaman berganda tertunda

Idea asas pemadaman berganda tertunda adalah seperti berikut

: Padam cache; Kemas kini pangkalan data ;tidur N milisaat;

Padam cache sekali lagi.
3. Selepas menyekat untuk satu tempoh masa, padamkan cache sekali lagi untuk memadamkan data yang tidak konsisten dalam cache
. Bagi masa tertentu, anda perlu menilai anggaran masa perniagaan anda dan menetapkannya mengikut masa ini.
4. 4.1 Apa yang perlu dilakukan jika seni bina memisahkan bacaan dan penulisan?

	public?void?write(String?key,?Object?data)?{
????????Redis.delKey(key);
????????db.updateData(data);
????????Thread.sleep(1000);
????????Redis.delKey(key);
????}

Jika pangkalan data menggunakan seni bina pemisahan baca-tulis, maka masalah baharu akan timbul, seperti yang ditunjukkan di bawah:

Pada masa ini, dua permintaan datang, minta A (operasi kemas kini ) dan minta B (operasi pertanyaan)

Minta operasi kemas kini, padam Redis

Minta pustaka utama untuk melakukan operasi kemas kini, dan pustaka utama dan pustaka hamba untuk menyegerakkan; data ;
Sila minta B untuk operasi pertanyaan dan mendapati tiada data dalam Redis;

Pergi dan dapatkan data daripada perpustakaan;
1. Pada masa ini, penyegerakan data belum selesai, dan data yang diperolehi Ia adalah data lama
3. Penyelesaian pada masa ini adalah untuk menanyakan pangkalan data untuk mengisi data dalam Redis, kemudian memaksanya untuk menunjuk ke pangkalan data utama; untuk pertanyaan.
4. Apakah yang perlu saya lakukan jika pemadaman gagal?

Jika pemadaman masih gagal, anda boleh menambah bilangan percubaan semula, tetapi nombor ini mesti dihadkan Apabila melebihi nombor tertentu, langkah seperti ralat pelaporan, rekod rekod dan penghantaran peringatan e-mel mesti diambil.

5. Gunakan baris gilir mesej untuk mengimbangi pemadaman

Kemas kini pangkalan data dahulu, kemudian padamkan cache

Situasi ini juga akan menyebabkan masalah dikemas kini dengan jayanya, tetapi Jika ralat berlaku semasa peringkat pemadaman cache dan pemadaman tidak berjaya, maka apabila membaca cache sekali lagi pada masa ini, data akan menjadi salah setiap kali.

Penyelesaian pada masa ini ialah menggunakan baris gilir mesej untuk mengimbangi pemadaman. Logik perniagaan khusus diterangkan dalam istilah seperti berikut:

Minta urutan A untuk mengemas kini pangkalan data dahulu
Ralat telah dilaporkan semasa memadam Redis, dan pemadaman gagal;

Pada masa ini, kunci Redis dihantar ke baris gilir mesej sebagai badan mesej

Sistem memadamkan Redis sekali lagi selepas menerima mesej yang dihantar oleh baris gilir mesej; ?? >Tetapi penyelesaian ini akan mempunyai kelemahan, iaitu ia akan menyebabkan banyak pencerobohan ke dalam kod perniagaan dan digabungkan secara mendalam, jadi akan ada kaedah pengoptimuman pada masa ini Kami tahu bahawa pangkalan data Mysql dikemas kini binlog selepas operasi Kita semua boleh mencari operasi yang sepadan, kemudian kita boleh melanggan log binlog pangkalan data Mysql untuk mengendalikan cache.
2. Pembelajaran yang disyorkan:
3. Tutorial Redis

Atas ialah kandungan terperinci Bagaimana untuk memastikan konsistensi antara cache Redis dan pangkalan data. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!