Bagaimana untuk memastikan konsistensi dua tulis antara Redis dan MySQL? (Meituan Ermian)

Prakata

Pada bulan April, seorang rakan pergi ke Meituan untuk temu duga Dia berkata dia ditanya bagaimana untuk memastikan konsistensi dwi-tulisan antara Redis dan MySQL? Soalan ini sebenarnya bertanya bagaimana untuk memastikan konsistensi cache dan pangkalan data dalam senario dua tulis? Artikel ini akan membincangkan dengan anda cara menjawab soalan ini.

• alamat github, terima kasih untuk setiap bintang

Bercakap tentang konsistensi

Ketekalan bermaksud data kekal konsisten Dalam sistem teragih, ia boleh difahami sebagai nilai data dalam berbilang nod adalah konsisten.

• Konsistensi yang kuat: Tahap konsistensi ini paling sesuai dengan gerak hati pengguna. Apa yang diperlukan oleh sistem ialah apa yang dibaca Pengalaman pengguna adalah baik, tetapi ia sukar untuk melaksanakan. Selalunya memberi impak yang besar kepada prestasi sistem
• Konsistensi yang lemah : Tahap ketekalan ini menyekat sistem daripada dapat membaca nilai bertulis serta-merta selepas penulisan berjaya, ia juga tidak menjamin bahawa nilai bertulis boleh dibaca serta-merta selepas penulisan itu berjaya. Janjikan berapa lama masa yang diperlukan untuk data menjadi konsisten, tetapi kami akan cuba sedaya upaya untuk memastikan data boleh mencapai keadaan yang konsisten selepas tertentu. tahap masa (seperti tahap kedua)
• Ketekalan Akhirnya: Ketekalan Akhir Ia adalah kes khas konsistensi yang lemah Sistem akan memastikan keadaan ketekalan data boleh dicapai dalam tempoh tertentu tempoh masa. Sebab mengapa konsistensi akhir disebut secara berasingan di sini adalah kerana ia adalah model konsistensi yang sangat dihormati dalam konsistensi yang lemah, dan ia juga merupakan model yang sangat dihormati dalam industri untuk konsistensi data dalam sistem teragih yang besar

Tiga mod caching klasik

Caching boleh meningkatkan prestasi dan melegakan tekanan pangkalan data, tetapi menggunakan cache juga boleh menyebabkan masalah ketidakkonsistenan data. Bagaimanakah kita biasanya menggunakan cache? Terdapat tiga corak caching klasik:

• Corak Tepi Cache
• Baca-Terus/Tulis melalui
• Tulis di belakang

Cache -Aside Pattern

Cache-Aside Pattern, iaitu bypass cache mod, dicadangkan untuk menyelesaikan masalah ketidakkonsistenan data antara cache dan pangkalan data sebanyak mungkin.

Proses baca Cache-Aside

Proses permintaan baca Corak Cache-Aside adalah seperti berikut:

1. Semasa membaca, baca cache dahulu Jika cache terkena, kembalikan data terus
2. Jika cache tidak kena, baca pangkalan data, keluarkan data dari pangkalan data, masukkan ke dalam. cache, dan kembalikan respons pada masa yang sama.

Proses tulis Cache-Aside

Corak Cache-AsideProses permintaan tulis adalah seperti berikut:

Apabila mengemas kini, mula-mula kemas kini pangkalan data dan kemudian padamkan cache .

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

Read/Write Through mod, pelayan menggunakan cache sebagai storan data utama. Interaksi antara aplikasi dan cache pangkalan data diselesaikan melalui lapisan cache abstrak.

Baca-Terus

Baca-TerusProses ringkasnya adalah seperti berikut

1. Baca dari cache Data akan dikembalikan terus selepas membaca
2. Jika ia tidak boleh dibaca, ia akan dimuatkan daripada pangkalan data, ditulis ke cache, dan kemudian respons akan dikembalikan.

Adakah proses ringkas ini hampir sama dengan Cache-Aside? Sebenarnya, Baca-Terus hanyalah lapisan tambahan Penyedia Cache, dan prosesnya adalah seperti berikut:

Baca Lalu sebenarnya hanyalah Cache-Aside, yang akan menjadikan kod program lebih ringkas dan mengurangkan beban pada sumber data. Mod

Tulis-Terus

Tulis-Terus, apabila permintaan tulis berlaku, sumber data dan data cache turut dilengkapkan oleh lapisan abstraksi cache Proses kemas kini adalah seperti berikut:

Tulis di belakang (tulisan cache tak segerak)

Tulis di belakang dan Baca-Terus/Tulis-Terus Terdapat persamaan, bertanggungjawab untuk caching dan membaca dan menulis pangkalan data. Terdapat perbezaan besar antara mereka: Cache ProviderBaca/Tulis Melalui mengemas kini cache dan data secara serentak, manakala Tulis Di Belakang hanya mengemas kini cache dan tidak mengemas kini pangkalan data secara langsung Melalui Cara asynchronous untuk mengemas kini pangkalan data.

Dengan cara ini, konsistensi antara cache dan pangkalan data tidak kukuh

Sistem dengan keperluan konsistensi tinggi harus digunakan dengan berhati-hati . Tetapi ia sesuai untuk senario penulisan yang kerap Mekanisme Kolam Penampan InnoDB MySQL menggunakan mod ini.

Apabila mengendalikan cache, patutkah anda memadamkan cache atau mengemas kini cache?

Dalam senario perniagaan umum, kami menggunakan mod

Cache-Aside. Sesetengah rakan mungkin bertanya, Cache-AsideApabila menulis permintaan, mengapakah memadamkan cache dan bukannya mengemas kini cache?

Apabila kami mengendalikan cache, patutkah kami memadamkan cache atau mengemas kini cache? Mari lihat contoh dahulu:

1. Thread A mula-mula memulakan operasi tulis, dan langkah pertama ialah mengemas kini pangkalan data
2. Thread B kemudian memulakan operasi tulis Operasi tulis, langkah kedua mengemas kini pangkalan data
3. Atas sebab rangkaian dan lain-lain, utas B mengemas kini cache terlebih dahulu
4. 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.

Mengemas kini cache mempunyai dua kelemahan berbanding pemadaman cache:

• Jika nilai cache yang anda tulis diperoleh selepas pengiraan yang rumit. Jika cache dikemas kini dengan kerap, prestasi akan sia-sia.
• Apabila terdapat banyak senario penulisan pangkalan data dan sedikit senario pembacaan data, data sering dikemas kini sebelum ia dibaca, yang juga membazirkan prestasi (sebenarnya, dalam senario di mana terdapat banyak penulisan, Menggunakan cache tidak sangat menjimatkan kos)

Dalam kes penulisan dua kali, adakah pangkalan data harus dikendalikan dahulu atau cache terlebih dahulu?

Cache-AsideDalam mod cache, sesetengah rakan masih mempunyai soalan semasa menulis permintaan, mengapakah ia mengendalikan pangkalan data terlebih dahulu? Mengapa tidak mengendalikan cache dahulu?

Andaikan terdapat dua permintaan, A dan B, meminta A untuk melakukan operasi kemas kini dan meminta B untuk melakukan pertanyaan dan operasi membaca.

1. Thread A memulakan operasi tulis, langkah pertama ialah del cache
2. Pada masa ini, thread B memulakan operasi baca, cache miss
3. Thread B diteruskan Baca DB, baca keluar data lama
4. Kemudian thread B set data lama ke dalam cache
5. Thread A menulis data terkini dalam DB

Jiang Zi ada masalah La, Data cache dan pangkalan data tidak konsisten. Cache menyimpan data lama, dan pangkalan data menyimpan data baharu . Oleh itu, Cache-Aside mod cache memilih untuk mengendalikan pangkalan data dahulu dan bukannya cache dahulu.

Cache Delayed Double Delete

Sesetengah rakan mungkin mengatakan bahawa anda tidak perlu mengendalikan pangkalan data dahulu, hanya gunakan strategi Cache Delayed Double Delete strategi? Apakah pemadaman berganda tertunda?

1. Padam cache dahulu
2. kemudian kemas kini pangkalan data
3. Tidur sebentar (contohnya, 1 saat) dan padamkan cache sekali lagi.

Berapa lama biasanya masa yang diambil untuk tidur seketika? Adakah mereka semua 1 saat?

Masa tidur ini = masa yang diperlukan untuk membaca data logik perniagaan + beberapa ratus milisaat. Untuk memastikan permintaan baca tamat, permintaan tulis boleh memadamkan data kotor cache yang mungkin dibawa oleh permintaan baca.

Padam mekanisme percubaan semula cache

Sama ada pemadaman berganda tertunda atau operasi pertama pangkalan data Cache-Aside dan kemudian pemadaman cache, Jika langkah kedua pemadaman cache gagal, kegagalan pemadaman akan mengakibatkan data kotor~

Jika pemadaman gagal, padamkannya beberapa kali untuk memastikan pemadaman cache berjaya~ Jadi anda boleh memperkenalkan untuk memadamkan mekanisme Cuba semula

1. Tulis permintaan untuk mengemas kini pangkalan data
2. Pemadaman cache gagal atas sebab tertentu
3. Letakkan kunci yang gagal dipadamkan ke dalam baris gilir mesej
4. Gunakan mesej daripada baris gilir mesej dan dapatkan kunci untuk dipadamkan
5. Cuba semula operasi pemadaman cache

Baca biglog Asynchronous deleted of cache

Mekanisme cache pemadaman cuba semula tidak mengapa, tetapi ia akan menyebabkan banyak pencerobohan kod perniagaan. Malah, anda juga boleh menghapuskan kunci secara tak segerak melalui binlog pangkalan data .

Mengambil mysql sebagai contoh, anda boleh menggunakan saluran Alibaba untuk mengumpul log binlog dan menghantarnya ke baris gilir MQ, dan kemudian mengesahkan dan memproses mesej kemas kini melalui mekanisme ACK , padamkan cache dan pastikan data Cache konsisten

Pembelajaran yang disyorkan: "Tutorial Video Redis"

Atas ialah kandungan terperinci Bagaimana untuk memastikan konsistensi dua tulis antara Redis dan MySQL? (Meituan Ermian). Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!