Bagaimana untuk menyelesaikan masalah dwi-tulis antara Redis dan MySQL

Tulis di hadapan

Tegasnya, adalah mustahil untuk menjamin konsistensi untuk sebarang operasi bukan atom, melainkan penyekatan membaca dan menulis digunakan untuk mencapai konsistensi yang kuat, jadi matlamat yang kami kejar dalam seni bina cache adalah konsisten akhirnya.
Caching meningkatkan prestasi dengan mengorbankan konsistensi yang kuat.

Ini ditentukan oleh teori CAP. Senario yang boleh digunakan untuk sistem cache ialah senario ketekalan tidak kukuh, yang dimiliki oleh AP dalam CAP.

Tiga strategi baca dan tulis cache berikut mempunyai kelebihan dan kekurangan mereka sendiri, dan tidak ada yang terbaik.

Tiga strategi cache baca-tulis

Corak Cache-Aside (mod cache memintas)

Corak Cache-Aside, mod cache pintasan, dicadangkan untuk Menyelesaikan ketidakkonsistenan data masalah antara cache dan pangkalan data sebanyak mungkin.

Baca: Baca data daripada cache dan kembalikan terus selepas membaca. Jika ia tidak boleh dibaca, muatkannya daripada pangkalan data, tuliskannya ke cache, dan kemudian kembalikan respons.
Tulis: Apabila mengemas kini, mula-mula kemas kini pangkalan data dan kemudian padamkan cache.

Read-Through/Write-Through (penembusan baca-tulis)

Read/Write Through Pattern Di bahagian pelayan, cache dianggap sebagai storan data utama, membaca data daripadanya dan menulis data dalam. Tanggungjawab perkhidmatan Cache adalah untuk membaca dan menulis data DB, dengan itu mengurangkan beban pada aplikasi.

Oleh kerana Redis cache yang diedarkan yang sering kami gunakan tidak menyediakan fungsi cache untuk menulis data kepada DB, ia tidak digunakan dengan banyak.

Tulis : Semak cache dahulu, jika ia tidak wujud dalam cache, kemas kini DB terus. Jika ia wujud dalam cache, cache akan dikemas kini dahulu, dan kemudian perkhidmatan cache akan mengemas kini DB dengan sendirinya (Kemas kini cache dan DB serentak).

Baca: Baca data daripada cache dan kembalikan terus selepas membaca. Jika ia tidak boleh dibaca, muatkannya daripada DB dahulu, tuliskannya ke cache dan kemudian kembalikan respons.

Write Behind Pattern (tulis cache tak segerak)

Write Behind Pattern sangat serupa dengan Corak Baca/Tulis Melalui Kedua-duanya dikendalikan oleh perkhidmatan cache untuk membaca dan menulis cache dan DB.

Walau bagaimanapun, terdapat perbezaan besar antara kedua-duanya: Baca/Tulis Melalui mengemas kini cache dan DB secara serentak, manakala Write Behind Caching hanya mengemas kini cache dan tidak mengemas kini DB secara langsung, sebaliknya Kemas kini DB dalam cara kelompok tak segerak.

Jelas sekali, kaedah ini membawa cabaran yang lebih besar kepada konsistensi data Contohnya, jika data cache mungkin tidak dikemas kini secara tak segerak kepada DB, perkhidmatan cache mungkin hang, yang akan menyebabkan bencana yang lebih besar.

Strategi ini juga sangat jarang berlaku dalam proses pembangunan harian kami, tetapi ini tidak bermakna ia mempunyai sedikit senario aplikasi Contohnya, penulisan mesej tak segerak dalam baris gilir mesej ke cakera dan mekanisme Kolam Penampan InnoDB MySQL semuanya. gunakan strategi seperti ini.

Prestasi tulis DB di bawah Write Behind Pattern adalah sangat tinggi, yang sangat sesuai untuk sesetengah senario di mana data kerap berubah dan keperluan ketekalan data tidak begitu tinggi, seperti bilangan tontonan dan suka.

Analisis mod cache pintasan

Beberapa soalan mengenai Corak Tepi Cache

Mod cache pintasan ialah perkara yang paling kami gunakan dalam kehidupan seharian. Berdasarkan mod cache pintasan yang diperkenalkan di atas, kami mungkin mempunyai soalan berikut.

Mengapa operasi tulis memadamkan cache dan bukannya mengemas kini cache? dalam langkah pertama. Thread B memulakan operasi tulis lain dan mengemas kini pangkalan data dalam langkah kedua Atas sebab rangkaian dan lain-lain, thread B mengemas kini cache terlebih dahulu dan thread A mengemas kini cache.

Pada masa ini, cache menyimpan data A (data lama), dan pangkalan data menyimpan data B (data baharu

tidak konsisten dan data kotor muncul. Jika ia memadamkan cache dan bukannya mengemas kini cache

, masalah data kotor ini tidak akan berlaku.

Malah, adalah mungkin untuk mengemas kini cache apabila operasi menulis diperlukan, tetapi kami perlu menambah kunci/kunci yang diedarkan untuk memastikan tiada isu keselamatan benang semasa mengemas kini cache. Semasa proses menulis data, mengapa kita perlu mengemas kini DB dahulu dan kemudian memadam cache?

Jawapan

: Contohnya , permintaan 1 ialah operasi tulis Jika Mula-mula padam cache A, permintaan 2 ialah operasi baca, baca cache A dahulu, ketahui bahawa cache telah dipadamkan (dipadamkan oleh permintaan 1), dan kemudian baca pangkalan data, tetapi pada masa ini. permintaan 1 belum sempat mengemas kini data dalam masa, kemudian minta 2 Apa yang dibaca adalah data lama, dan permintaan 2 juga akan meletakkan data lama dibaca ke dalam cache, menyebabkan data tidak konsisten.

Malah, anda boleh memadam cache dahulu dan kemudian mengemas kini pangkalan data Contohnya, jika anda menggunakan

strategi pemadaman berganda tertunda tidur selama 1 saat dan kemudian hapuskan cache. sekali lagi, anda boleh memadam semua data dalam 1 saat Data kotor yang dicache yang disebabkan oleh ini dipadamkan semula. Ia tidak semestinya 1 saat, ia bergantung pada perniagaan anda,

Walau bagaimanapun, pendekatan ini tidak disyorkan

, kerana banyak faktor mungkin berlaku dalam 1 saat ini, dan ketidakpastian terlalu besar.
Dalam proses menulis data, adakah boleh mengemas kini DB dahulu dan kemudian memadam cache?

Jawapan:

Secara teori, ketidakkonsistenan data mungkin masih berlaku, tetapi kebarangkaliannya sangat kecil.

Anggapkan terdapat dua permintaan, satu meminta A melakukan operasi pertanyaan dan satu meminta B melakukan operasi kemas kini, maka situasi berikut akan berlaku

(1) Cache baru sahaja tamat tempoh
(2) Minta A untuk menanyakan pangkalan data dan mendapatkan nilai lama
(3) Minta B untuk menulis nilai baharu ke dalam pangkalan data
(4) Permintaan B untuk memadam cache
(5) Minta A untuk menulis nilai lama yang terdapat ke dalam cache ok Jika situasi di atas berlaku, data kotor memang akan berlaku.

Walau bagaimanapun, kebarangkalian perkara ini berlaku tidaklah tinggi

Terdapat keadaan kongenital untuk situasi di atas berlaku, iaitu operasi penulisan pangkalan data secara berperingkat ( 3) adalah lebih kecil daripada itu dalam langkah ( Operasi pangkalan data baca 2) mengambil sedikit masa, jadi adalah mungkin untuk membuat langkah (4) mendahului langkah (5).

Namun, jika anda memikirkannya dengan teliti, operasi baca pangkalan data adalah lebih cepat daripada operasi tulis (jika tidak, mengapa kita melakukan pemisahan membaca dan menulis? Maksud melakukan pemisahan baca dan tulis adalah kerana operasi baca adalah lebih pantas dan menggunakan kurang sumber), jadi langkah (3) mengambil masa yang lebih sedikit daripada langkah (2), dan keadaan ini sukar berlaku.

Adakah terdapat sebab lain untuk ketidakkonsistenan itu?

Jawapan: Jika pemadaman cache gagal, ia akan menyebabkan isu tidak konsisten

Bagaimana untuk menyelesaikannya?
Gunakan Canal untuk melanggan binlog pangkalan data dan dapatkan data yang perlu dikendalikan. Mulakan program lain untuk mendapatkan maklumat daripada program langganan ini dan padamkan cache.

Kecacatan Corak Ketepikan Cache

Kecacatan 1: Data pertama yang diminta mestilah tiada dalam cache

Penyelesaian: Data hotspot boleh dimasukkan terlebih dahulu dalam cache.

Kecacatan 2: Operasi tulis yang kerap akan menyebabkan data dalam cache kerap dipadamkan, yang akan menjejaskan kadar hit cache.

Senario konsistensi yang kukuh antara pangkalan data dan data cache: Apabila mengemas kini DB, cache juga dikemas kini, tetapi kami perlu menambah kunci/kunci yang diedarkan untuk memastikan tiada isu keselamatan benang semasa mengemas kini cache. Senario di mana pangkalan data dan data cache tidak konsisten boleh dibenarkan buat sementara waktu: apabila mengemas kini DB, cache juga dikemas kini, tetapi masa tamat tempoh yang agak singkat ditambahkan pada cache Ini memastikan bahawa walaupun data tidak konsisten, kesannya akan menjadi agak kecil.

Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan masalah dwi-tulis antara Redis dan MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!