Apakah yang perlu saya lakukan jika cache tulis dua kali Redis dan MySQL tidak konsisten? Perkongsian penyelesaian

Apakah yang perlu saya lakukan jika cache tulis dua kali Redis dan MySQL tidak konsisten? Artikel ini akan berkongsi dengan anda bagaimana untuk menyelesaikan masalah cache double-write inconsistency Saya harap ia dapat membantu anda!

redis dan mysql double-write cache tidak konsisten:

Tetapi dari segi mengemas kini cache, untuk 更新完数据库，是更新缓存呢，还是删除缓存。 atau Pertama 删除缓存，再更新数据库，其实大家存在很大的争议。 Pada masa ini tiada blog komprehensif yang menganalisis beberapa penyelesaian ini. Jadi blogger menulis artikel ini dengan tergetar dan berisiko dikritik oleh semua orang.

Teks

Tetapkan masa tamat tempoh untuk data cache

Biar saya membuat penjelasan dahulu cache Masa tamat adalah penyelesaian untuk memastikan konsistensi akhirnya. Di bawah penyelesaian ini, kami boleh menetapkan masa tamat tempoh untuk data yang disimpan dalam cache Semua operasi tulis tertakluk kepada pangkalan data dan kami hanya perlu melakukan yang terbaik untuk operasi cache. Maksudnya, jika penulisan pangkalan data berjaya dan kemas kini cache gagal, maka selagi masa tamat tempoh dicapai, permintaan baca seterusnya secara semula jadi akan membaca nilai baru dari pangkalan data dan mengisi semula cache. Oleh itu, idea yang dibincangkan seterusnya tidak bergantung pada penyelesaian menetapkan masa tamat untuk cache.

Di sini, mula-mula kita membincangkan tiga strategi kemas kini:

1. Kemas kini pangkalan data dahulu, kemudian kemas kini cache
2. Padam cache dahulu, kemudian Kemas kini pangkalan data
3. Kemas kini pangkalan data dahulu, kemudian padamkan cache

Kemas kini pangkalan data dahulu, kemudian kemas kini cache

Ini penyelesaian umumnya ditentang oleh semua orang. kenapa? Terdapat dua perkara berikut:

• Sebab satu (perspektif keselamatan benang)

(1) Thread A mengemas kini pangkalan data
(2) Thread B mengemas kini pangkalan data
(3) Thread B mengemas kini cache
(4) Thread A mengemas kini cache

Ini bermakna meminta A untuk mengemas kini cache harus lebih awal daripada meminta B untuk mengemas kini cache Walau bagaimanapun , atas sebab rangkaian dan lain-lain, Tetapi B mengemas kini cache lebih awal daripada A. Ini mengakibatkan data kotor dan oleh itu tidak dipertimbangkan.

• Sebab Kedua (Perspektif Senario Perniagaan)

(1) Jika anda mempunyai keperluan perniagaan dengan lebih banyak senario penulisan pangkalan data dan kurang senario membaca data, gunakan ini Penyelesaian ini akan menyebabkan cache yang akan dikemas kini dengan kerap sebelum data dibaca, yang membazirkan prestasi.

(2) Jika nilai yang anda tulis ke pangkalan data tidak ditulis terus ke dalam cache, ia mesti melalui satu siri pengiraan yang kompleks dan kemudian ditulis ke dalam cache. Kemudian, mengira nilai yang ditulis ke cache sekali lagi setiap kali ia ditulis ke pangkalan data sudah pasti satu pembaziran prestasi. Jelas sekali, memadam cache adalah lebih sesuai.

Padam cache dahulu, dan kemudian kemas kini pangkalan data

Sebab penyelesaian ini akan membawa kepada ketidakkonsistenan ialah. Pada masa yang sama, seorang meminta A untuk melakukan operasi kemas kini, dan yang lain meminta B untuk melaksanakan operasi pertanyaan. Kemudian situasi berikut akan berlaku:

(1) Minta A melakukan operasi tulis dan padam cache
(2) Minta B untuk bertanya dan mendapati cache tidak wujud
(3 ) Minta B untuk menanyakan pangkalan data untuk mendapatkan nilai lama
(4) Minta B untuk menulis nilai lama ke cache
(5) Minta A untuk menulis nilai baru ke pangkalan data

Keadaan di atas akan membawa kepada ketidakkonsistenan. Selain itu, jika anda tidak menetapkan strategi masa tamat tempoh untuk cache, data akan sentiasa menjadi data kotor.

Jadi, bagaimana untuk menyelesaikannya? Gunakan strategi pemadaman berganda tertunda

Pemadaman berganda tertunda cache

public class CacheServiceImpl implements ICacheService {

    @Resource
    private RedisOperator redisOperator;
    
    @Autowired
    private IShopService shopService;

    //1. 采用延时双删，解决数据库和缓存的一致性
    @Override
    public void updateHotCount(String id) {
        try {
            //删除缓存
            redisOperator.del("redis_key_" + id);
            //更新数据库
            shopService.updataHotShop();
            Thread.sleep(1000);//休眠1秒
            //延时删除
            redisOperator.del("redis_key_" + id);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }


    }

    @Override
    public Integer getHotCount(String id) {
        return null;
    }}

Penjelasan:

1. Hapuskan cache dahulu
2. Tulis ke pangkalan data sekali lagi
3. Tidur selama 1 saat, dan kemudian padamkan cache (Dengan melakukan ini, data kotor yang dicache yang disebabkan dalam masa 1 saat boleh dipadamkan semula.)

Memandangkan situasi di atas, pembaca harus menilai logik perniagaan membaca data yang memakan masa bagi projek mereka sendiri. Kemudian masa tidur untuk menulis data adalah berdasarkan penggunaan masa logik perniagaan untuk membaca data, ditambah dengan beberapa ratus milisaat. Tujuannya adalah untuk memastikan permintaan baca tamat, dan permintaan tulis boleh memadamkan data kotor yang dicache yang disebabkan oleh permintaan baca.

Bagaimana jika pangkalan data menggunakan seni bina pemisahan baca-tulis? (Pustaka utama bertanggungjawab untuk operasi menulis, dan perpustakaan hamba bertanggungjawab untuk operasi membaca)

ok, dalam kes ini, sebab ketidakkonsistenan data adalah seperti berikut, masih terdapat dua permintaan dan satu permintaan A melakukan operasi kemas kini, dan satu lagi permintaan B untuk melaksanakan operasi pertanyaan.

(1) Minta A untuk melakukan operasi tulis, padam cache dan minta A untuk menulis data ke pustaka utama Penyegerakan daripada pustaka hamba belum bermula

(2) (dalam 1s) Minta B untuk menanyakan cache , cache tidak dijumpai, dan B diminta untuk menanyakan pangkalan data hamba Pada masa ini, penyegerakan induk-hamba belum selesai, dan nilai lama ditemui, dan nilai lama ditulis pada cache.

(3) Pangkalan data induk melengkapkan penyegerakan induk-hamba, dan pangkalan data hamba bertukar kepada nilai baharu

Proses di atas ialah masalah ketidakkonsistenan data, dan kelewatan pemadaman dua kali strategi juga digunakan. Walau bagaimanapun, masa tidur diubah suai berdasarkan masa tunda penyegerakan tuan-hamba, ditambah beberapa ratus ms

Jika strategi penyingkiran penyegerakan ini diguna pakai, apakah yang perlu saya lakukan jika daya pemprosesan dikurangkan ?

ok, kemudian jadikan pemadaman kedua tidak segerak. Mulakan benang sendiri dan padamkannya secara tidak segerak. Dengan cara ini, permintaan bertulis tidak perlu tidur untuk tempoh masa sebelum kembali. Melakukannya meningkatkan daya tampung.

Pemadaman kedua, apakah yang perlu saya lakukan jika pemadaman gagal?

Ini adalah soalan yang sangat bagus, kerana jika pemadaman gagal untuk kali kedua, situasi berikut akan berlaku. Masih terdapat dua permintaan, satu permintaan A untuk melaksanakan operasi kemas kini, dan satu lagi permintaan B untuk melaksanakan operasi pertanyaan Untuk kemudahan, ia diandaikan sebagai satu pangkalan data:

(1) Permintaan A kepada. lakukan operasi tulis dan padam cache
( 2) Minta B untuk membuat pertanyaan dan mendapati bahawa cache tidak wujud
(3) Minta B untuk menanyakan pangkalan data untuk mendapatkan nilai lama
(4) Minta B untuk menulis nilai lama ke dalam cache
(5) Minta A untuk menulis Pangkalan Data nilai baharu
(6) Permintaan A cuba memadamkan nilai cache yang ditulis oleh permintaan B, tetapi gagal.

ok, maksudnya. Jika pemadaman cache gagal untuk kali kedua, cache dan ketidakkonsistenan pangkalan data akan berlaku lagi.

Bagaimana untuk menyelesaikannya?

Untuk penyelesaian khusus, mari lihat analisis blogger mengenai strategi kemas kini mengemas kini pangkalan data dahulu dan kemudian memadam cache.

Padam mekanisme percubaan semula cache

Sama ada Pemadaman dua kali tertunda atau Cache-Aside mengendalikan pangkalan data dahulu dan kemudian memadam cache , mungkin terdapat masalah ketidakkonsistenan data yang disebabkan oleh kegagalan memadam cache dalam langkah kedua. Anda boleh menggunakan penyelesaian ini untuk mengoptimumkan: jika pemadaman gagal, hanya padamkannya beberapa kali lagi untuk memastikan pemadaman cache berjaya~ Jadi anda boleh memperkenalkan mekanisme cuba semula cache padam

1. (1) Kemas kini data pangkalan data
   (2) Pemadaman cache gagal kerana pelbagai masalah
   (3) Hantar kunci yang perlu dipadamkan ke baris gilir mesej
   (4) Habis mesej sendiri, Dapatkan kunci yang perlu dipadam
   (5) Teruskan mencuba semula operasi pemadaman sehingga berjaya

Walau bagaimanapun, penyelesaian ini mempunyai kekurangan , menyebabkan banyak pencerobohan ke dalam kod baris perniagaan. Jadi kita mempunyai pilihan kedua Dalam pilihan kedua, mulakan program langganan untuk melanggan binlog pangkalan data untuk mendapatkan data yang perlu dikendalikan. Dalam aplikasi, mulakan program baharu untuk mendapatkan maklumat daripada program langganan ini dan padamkan cache.

Baca biglog dan padam cache secara tak segerak

Prosesnya adalah seperti yang ditunjukkan dalam rajah di bawah:

( 1) Kemas kini Data pangkalan data
(2) Pangkalan data akan menulis maklumat operasi ke dalam log binlog
(3) Program langganan mengekstrak data dan kunci yang diperlukan
(4) Mulakan bahagian baharu bukan- kod perniagaan untuk mendapatkan maklumat
(5) Cuba padamkan operasi cache dan dapati pemadaman gagal
(6) Hantar maklumat ke baris gilir mesej
(7) Dapatkan semula data daripada baris gilir mesej dan cuba semula operasi.

Catatan: Program langganan binlog di atas mempunyai perisian tengah siap sedia dipanggil canal dalam mysql, yang boleh melengkapkan fungsi melanggan log binlog. Bagi Oracle pula, blogger buat masa ini tidak tahu sama ada terdapat middleware siap pakai yang boleh digunakan. Selain itu, bagi mekanisme cuba semula, penulis blog menggunakan baris gilir mesej. Jika keperluan konsistensi tidak begitu tinggi, mulakan sahaja urutan baru dalam program dan cuba sekali-sekala Anda boleh menggunakan ini secara fleksibel, tetapi saya hanya memberikan idea.

Artikel ini sebenarnya adalah ringkasan penyelesaian ketekalan sedia ada di Internet. Mengenai strategi kemas kini untuk memadam cache terlebih dahulu dan kemudian mengemas kini pangkalan data, terdapat juga rancangan untuk mengekalkan baris gilir memori Blogger melihatnya dan merasakan bahawa pelaksanaannya sangat rumit dan tidak perlu, jadi tidak perlu memberikannya. dalam artikel. Akhir sekali, saya harap anda semua mendapat sesuatu.

[Cadangan berkaitan: tutorial video mysql]

Atas ialah kandungan terperinci Apakah yang perlu saya lakukan jika cache tulis dua kali Redis dan MySQL tidak konsisten? Perkongsian penyelesaian. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!