Cache Redis dan kaedah ketekalan data MySQL

Punca permintaan

Dalam senario perniagaan konkurensi tinggi, pangkalan data dalam kebanyakan kes adalah pautan paling lemah untuk akses pengguna serentak. Oleh itu, anda perlu menggunakan redis untuk melakukan operasi penimbalan supaya permintaan boleh mengakses redis terlebih dahulu dan bukannya mengakses pangkalan data secara terus seperti MySQL.

Senario perniagaan ini terutamanya menyelesaikan masalah membaca data daripada cache Redis Operasi perniagaan secara amnya dijalankan mengikut proses dalam rajah di bawah.

Secara amnya tiada masalah dalam membaca langkah cache, tetapi apabila kemas kini data terlibat: kemas kini pangkalan data dan cache, isu konsistensi data antara cache (Redis) dan pangkalan data (MySQL) terdedah kepada berlaku.

Sama ada anda menulis pangkalan data MySQL dahulu dan kemudian memadam cache Redis atau memadam cache dahulu dan kemudian menulis ke pangkalan data, ketidakkonsistenan data mungkin berlaku; Berikan contoh:

1. Jika cache Redis dipadamkan dan benang lain datang untuk membaca sebelum ia mempunyai masa untuk menulis ke pangkalan data MySQL, dan mendapati bahawa cache kosong, ia membaca data dari pangkalan data dan menulisnya ke cache Pada masa ini , cache mengandungi data kotor.

2. Jika pustaka ditulis dahulu, dan benang menulis pustaka ranap sebelum cache dipadamkan, dan cache tidak dipadamkan, ketidakkonsistenan data juga akan berlaku.

Oleh kerana menulis dan membaca adalah serentak dan susunan tidak dapat dijamin, akan terdapat ketidakselarasan data antara cache dan pangkalan data.

Tathagata menyelesaikannya? Berikut ialah dua penyelesaian, mudah dahulu dan kemudian sukar, dipilih berdasarkan perniagaan dan kos teknikal.

Penyelesaian ketekalan cache dan pangkalan data

1. Pilihan pertama: pakai strategi pemadaman berganda tertunda

Lakukan operasi redis.del (kunci) sebelum dan selepas menulis perpustakaan, dan tetapkan tamat masa yang munasabah.

Kod pseudo adalah seperti berikut

​tulisan kekosongan awam(Kunci rentetan,Data objek){

redis.delKey(key);

​db.updateData(data);

Thread.sleep(500);

redis.delKey(key);

}

2. Langkah-langkah khusus ialah:

​1) Padamkan cache dahulu

​2) Kemudian tulis pangkalan data

3) Tidur selama 500 milisaat

4) Padamkan cache sekali lagi

Jadi, bagaimanakah 500 milisaat ini ditentukan, dan berapa lama ia harus tidur?

Anda perlu menilai logik perniagaan membaca data yang memakan masa projek anda. Tujuannya adalah untuk memastikan permintaan baca tamat, dan permintaan tulis boleh memadamkan data kotor yang dicache yang disebabkan oleh permintaan baca.

Sudah tentu, strategi ini juga perlu mempertimbangkan penyegerakan yang memakan masa antara redis dan master-slave pangkalan data. Masa tidur terakhir untuk menulis data: Tambahkan beberapa ratus milisaat pada masa yang diperlukan untuk membaca logik perniagaan data. Contohnya: tidur selama 1 saat.

3. Tetapkan masa tamat tempoh cache

Secara teorinya, menetapkan masa tamat untuk cache adalah penyelesaian untuk memastikan konsistensi akhirnya. Semua operasi tulis tertakluk kepada pangkalan data Selagi masa tamat cache dicapai, permintaan baca seterusnya secara semula jadi akan membaca nilai baharu daripada pangkalan data dan mengisi semula cache.

4. Kelemahan pelan ini

Menggabungkan strategi pemadaman berganda + tetapan tamat masa cache, senario kes terburuk ialah data tidak konsisten dalam tempoh tamat masa dan ia juga meningkatkan masa menulis permintaan.

2. Penyelesaian kedua: cache kemas kini tak segerak (mekanisme penyegerakan berdasarkan melanggan binlog)

1. Idea teknikal keseluruhan:

Penggunaan langganan tambahan binlog MySQL + baris gilir mesej + kemas kini data tambahan kepada redis

1) Baca Redis: Data panas pada asasnya dalam Redis

2) Menulis MySQL: Penambahan, pemadaman dan pengubahsuaian adalah semua operasi pada MySQL

3) Kemas kini data Redis: binlog operasi data MySQ dikemas kini kepada Redis

​2. Kemas kini Redis

1) Operasi data terutamanya dibahagikan kepada dua blok:

Satu adalah volum penuh (tulis semua data ke redis sekali gus)

Satu adalah tambahan (kemas kini masa nyata)

Apa yang kita bincangkan di sini ialah kenaikan, yang merujuk kepada kemas kini, memasukkan dan memadam data perubahan mysql.

2) Selepas membaca binlog, analisanya dan gunakan baris gilir mesej untuk menolak dan mengemas kini data cache redis setiap stesen.

Dengan cara ini, sebaik sahaja penulisan baru, kemas kini, padam dan operasi lain berlaku dalam MySQL, mesej berkaitan binlog boleh ditolak ke Redis, dan Redis akan mengemas kini Redis berdasarkan rekod dalam binlog.

Malah, mekanisme ini hampir sama dengan mekanisme sandaran tuan-hamba MySQL, kerana sandaran tuan-hamba MySQL juga mencapai konsistensi data melalui binlog.

Di sini anda boleh menggunakan canal (rangka kerja sumber terbuka Alibaba) dalam kombinasi, yang mana anda boleh melanggan binlog MySQL Canal meniru permintaan sandaran pangkalan data hamba mysql, supaya kemas kini data Redis mencapai kesan yang sama.

Sudah tentu, anda juga boleh menggunakan pihak ketiga yang lain untuk alat tolak mesej di sini: kafka, rabbitMQ, dll. untuk menolak kemas kini ke Redis.

Atas ialah kandungan terperinci Cache Redis dan kaedah ketekalan data MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!