Mari kita bincangkan tentang cara menangani masalah kunci panas cache dalam Redis? Perkongsian penyelesaian biasa

Bagaimana untuk menangani masalah kunci panas di Redis? Artikel berikut akan memperkenalkan kepada anda penyelesaian biasa kepada masalah kunci panas cache Redis Saya harap ia akan membantu anda!

Apabila melakukan beberapa perniagaan C-side, adalah tidak dapat dielakkan untuk memperkenalkan cache peringkat pertama untuk menggantikan tekanan pada pangkalan data dan mengurangkan masa tindak balas perniagaan. setiap kali perisian tengah diperkenalkan untuk menyelesaikan masalah Pada masa yang sama, ia pasti akan membawa banyak isu baharu yang memerlukan perhatian, seperti bagaimana untuk mencapai konsistensi cache yang disebutkan dalam artikel sebelumnya "Pangkalan Data dan Konsistensi Cache dalam Amalan". Malah, akan ada beberapa masalah lain, seperti kekunci panas, kekunci besar, dsb. yang mungkin disebabkan apabila menggunakan Redis sebagai cache peringkat pertama Dalam artikel ini, kita akan membincangkan masalah 热key（hot key） dan cara yang munasabah menyelesaikan masalah 热key.

Latar Belakang

热keyApakah masalah dan bagaimanakah ia disebabkan?

Secara umumnya, cache Redis yang kami gunakan ialah versi kluster berbilang nod Apabila membaca dan menulis kunci tertentu, slot yang sepadan akan dikira berdasarkan cincangan kekunci, dan ia boleh didapati berdasarkan. pada slot ini. Serpihan yang sepadan (satu set kelompok redis yang terdiri daripada satu induk dan berbilang hamba) digunakan untuk mengakses K-V. Walau bagaimanapun, dalam proses permohonan sebenar, untuk sesetengah perniagaan tertentu atau beberapa tempoh masa tertentu (seperti aktiviti jualan kilat produk dalam perniagaan e-dagang), sejumlah besar permintaan mungkin berlaku untuk mengakses kunci yang sama. Semua permintaan (dan nisbah baca-tulis permintaan sedemikian adalah sangat tinggi) akan jatuh pada pelayan redis yang sama, dan beban pada redis akan meningkat dengan serius Pada masa ini, penambahan contoh redis baharu ke seluruh sistem akan menjadi tidak berguna, kerana mengikut algoritma cincang, Permintaan untuk kunci yang sama masih akan jatuh pada mesin baharu yang sama, yang akan tetap menjadi kesesakan sistem2, malah menyebabkan keseluruhan kluster ranap Jika nilai kunci tempat liputan ini agak besar, ia juga akan menyebabkan kad rangkaian mencapai kesesakan Masalah ini Dikenali sebagai masalah "kunci panas". [Cadangan berkaitan: Tutorial video Redis]

Seperti yang ditunjukkan dalam Rajah 1 dan 2 di bawah, mereka ialah kluster redis biasa dan akses kunci kluster redis menggunakan lapisan proksi proksi masing-masing.

Seperti yang dinyatakan di atas, kekunci panas akan membawa tekanan beban yang sangat tinggi kepada sebilangan kecil nod dalam kelompok jika tidak dikendalikan dengan betul , maka nod ini mungkin turun, yang akan menjejaskan operasi keseluruhan kluster cache Oleh itu, kita mesti menemui kunci panas dan menyelesaikan masalah kunci panas dalam masa.

1. Pengesanan kunci panas

Pengesanan kunci panas, melihat beberapa kesan ketara yang disebabkan oleh penyebaran gugusan redis dan kunci panas, kami boleh melakukannya melalui proses pemikiran yang kasar dan halus. untuk pengesanan kunci tempat liputan.

1.1 Pemantauan QPS bagi setiap slot dalam kluster

Kesan paling ketara hot key ialah pengagihan trafik di bawah premis bahawa qps dalam keseluruhan kluster redis adalah tidak begitu besar Apabila ia datang kepada masalah slot tidak sekata dalam kelompok, perkara pertama yang boleh kita fikirkan adalah untuk memantau trafik dalam setiap slot Selepas melaporkan, bandingkan trafik setiap slot, dan kemudian kita boleh mencari slot tertentu terjejas apabila kekunci panas muncul. Walaupun pemantauan ini adalah yang paling mudah, butirannya terlalu kasar Ia hanya sesuai untuk penyelesaian pemantauan kelompok awal dan tidak sesuai untuk senario di mana kekunci panas dikesan dengan tepat.

1.2 Mekanisme proksi digunakan sebagai keseluruhan statistik pintu masuk trafik

Jika kita menggunakan mod proksi kelompok redis dalam Rajah 2, kerana semua permintaan akan pergi ke proksi terlebih dahulu Pergi ke nod slot tertentu, kemudian statistik pengesanan kunci panas ini boleh dilakukan dalam proksi Berdasarkan 时间滑动窗口 dalam proksi, setiap kunci dikira, dan kemudian kunci yang melebihi ambang yang sepadan dikira. Untuk mengelakkan terlalu banyak statistik berlebihan, anda juga boleh menetapkan beberapa peraturan untuk mengira kunci yang sepadan dengan awalan dan jenis sahaja. Kaedah ini memerlukan sekurang-kurangnya mekanisme proksi dan mempunyai keperluan untuk seni bina redis.

1.3 redis mekanisme penemuan kunci hotspot berasaskan LFU

Versi di atas redis 4.0 menyokong mekanisme penemuan kunci hotspot berasaskan LFU pada setiap nod, gunakan redis-cli –hotkeysItu sahaja , tambah pilihan –hotkeys apabila melaksanakan redis-cli. Anda boleh menggunakan arahan ini dengan kerap pada nod untuk menemui kunci hotspot yang sepadan.

Seperti yang ditunjukkan di bawah, anda boleh melihat hasil pelaksanaan redis-cli –hotkeys dan maklumat statistik kekunci panas Masa pelaksanaan perintah ini adalah panjang, dan anda boleh menetapkan sehingga pelaksanaan berjadual untuk statistik.

1.4 Pengesanan berdasarkan klien Redis

Memandangkan arahan redis dikeluarkan daripada klien setiap kali, berdasarkan ini kami boleh melakukan statistik dan mengira dalam beberapa kod klien redis. Setiap pelanggan membuat statistik berdasarkan tetingkap gelongsor masa Selepas melebihi ambang tertentu, statistik dilaporkan kepada pelayan, dan kemudian pelayan menghantarnya kepada setiap pelanggan secara seragam, dan mengkonfigurasi masa tamat tempoh yang sepadan.

Kaedah ini kelihatan lebih 优美, tetapi sebenarnya ia tidak begitu sesuai dalam sesetengah senario aplikasi, kerana pengubahsuaian pada bahagian klien akan membawa overhed memori yang lebih besar kepada proses berjalan, yang akan menjadikannya lebih sukar Secara langsung, bahasa dengan pengurusan memori automatik seperti Java dan goLang akan mencipta objek dengan lebih kerap, mencetuskan gc dan menyebabkan masa tindak balas antara muka meningkat.

Akhir sekali, anda boleh membuat pilihan yang sepadan melalui infrastruktur setiap syarikat.

2. Penyelesaian kunci panas

Melalui kaedah di atas kami telah mengesan kunci panas atau slot panas yang sepadan, maka kami perlu menyelesaikan masalah kunci panas yang sepadan. Terdapat beberapa idea untuk menyelesaikan kekunci panas. Mari kita baca satu persatu.

2.1 Hadkan arus untuk kekunci atau slot tertentu

Cara paling mudah dan paling kasar ialah mengehadkan arus untuk slot atau kekunci panas tertentu Penyelesaian ini jelas sesuai untuk Ia kerugian untuk perniagaan, jadi disyorkan untuk hanya menggunakan pengehad semasa tertentu apabila terdapat masalah dalam talian dan kerugian itu perlu dihentikan.

2.2 Gunakan cache peringkat kedua (tempatan)

Cache setempat juga merupakan penyelesaian yang paling biasa digunakan Memandangkan cache peringkat pertama kami tidak dapat menahan tekanan yang begitu besar , Hanya tambah cache tahap kedua. Memandangkan setiap permintaan dikeluarkan oleh perkhidmatan, adalah sesuai untuk menambah cache peringkat kedua ini ke bahagian perkhidmatan Oleh itu, setiap kali pelayan memperoleh kunci panas yang sepadan, ia boleh menggunakan cache tempatan untuk menyimpan salinan sehingga cache setempat tamat tempoh. Kemudian minta sekali lagi untuk mengurangkan tekanan pada kelompok redis. Mengambil java sebagai contoh, guavaCache ialah alat siap sedia. Contoh berikut:

    //本地缓存初始化以及构造
    private static LoadingCache<String, List<Object>> configCache
            = CacheBuilder.newBuilder()
            .concurrencyLevel(8)  //并发读写的级别，建议设置cpu核数
            .expireAfterWrite(10, TimeUnit.SECONDS)  //写入数据后多久过期
            .initialCapacity(10) //初始化cache的容器大小
            .maximumSize(10)//cache的容器最大
            .recordStats()
            // build方法中可以指定CacheLoader，在缓存不存在时通过CacheLoader的实现自动加载缓存
            .build(new CacheLoader<String, List<Object>>() {
                @Override
                public List<Object> load(String hotKey) throws Exception {
                    
                }
            });
    
    //本地缓存获取
    Object result = configCache.get(key);

Kesan terbesar cache tempatan kepada kami ialah masalah ketidakkonsistenan data Berapa lama kami menetapkan masa tamat tempoh cache akan membawa kepada masalah ketidakkonsistenan data dalam talian yang paling lama perlu mengukur tekanan kelompoknya sendiri dan masa ketidakkonsistenan maksimum yang diterima oleh perniagaan.

2.3 Pembuangan kunci

Bagaimana untuk memastikan masalah kunci panas tidak akan berlaku sambil memastikan konsistensi data sebanyak mungkin? Mengeluarkan kunci juga merupakan penyelesaian yang baik.

Apabila kami memasukkannya ke dalam cache, kami membahagikan kunci cache perniagaan yang sepadan kepada berbilang kunci yang berbeza. Seperti yang ditunjukkan dalam rajah di bawah, kami mula-mula membahagikan kunci kepada N bahagian di sisi cache kemas kini Contohnya, jika kunci dinamakan "good_100", maka kita boleh membahagikannya kepada empat bahagian, "good_100_copy1", "good_100_copy2. "," good_100_copy3", "good_100_copy4", kekunci N ini perlu ditukar setiap kali ia dikemas kini atau ditambah. Langkah ini adalah untuk mengalih keluar kunci.

Untuk bahagian perkhidmatan, kita perlu mencari cara untuk menjadikan trafik yang kita akses sama rata, dan cara menambah imbuhan pada kekunci panas yang akan kita akses. Terdapat beberapa cara untuk melakukan cincang berdasarkan alamat IP atau mac mesin, dan kemudian ambil baki nilai dan bilangan kekunci split, dan akhirnya tentukan jenis akhiran kunci yang disambungkan, supaya mesin mana ia akan dipukul apabila perkhidmatan bermula Nombor rawak ialah baki bilangan kekunci belah.

2.4 Satu lagi idea pusat konfigurasi cache tempatan

Bagi mereka yang biasa dengan pusat konfigurasi perkhidmatan mikro, kami idea boleh ditukar kepada ketekalan pusat konfigurasi. Ambil nacos sebagai contoh Bagaimana ia mencapai ketekalan konfigurasi yang diedarkan dan bertindak balas dengan cepat? Kemudian kita boleh membandingkan analogi cache dengan konfigurasi dan melakukannya seperti ini.

长轮询 本地化 konfigurasi. Mula-mula, semua konfigurasi akan dimulakan apabila perkhidmatan bermula, dan kemudian pengundian panjang akan dimulakan dengan kerap untuk memeriksa sama ada konfigurasi pemantauan perkhidmatan semasa telah berubah Jika terdapat perubahan, permintaan tinjauan panjang akan kembali serta-merta untuk mengemas kini konfigurasi setempat; jika tiada perubahan, untuk Semua kod perniagaan menggunakan konfigurasi cache memori tempatan. Ini memastikan ketepatan masa dan ketekalan konfigurasi cache yang diedarkan.

2.5 Pelan lain yang boleh dibuat lebih awal

Setiap penyelesaian di atas adalah agak bebas untuk menyelesaikan masalah utama, jadi jika kita benar-benar menghadapi permintaan perniagaan, kita sebenarnya akan Terdapat masa yang lama untuk mempertimbangkan reka bentuk skema keseluruhan. Untuk isu utama hangat yang disebabkan oleh beberapa senario jualan kilat yang melampau, jika kami mempunyai belanjawan yang mencukupi, kami boleh mengasingkan perniagaan perkhidmatan secara langsung dan kluster cache redis untuk mengelakkan menjejaskan perniagaan biasa, dan pada masa yang sama, kami boleh menggunakan pemulihan bencana yang lebih baik buat sementara waktu dan Langkah mengehadkan semasa.

Beberapa penyelesaian bersepadu

Pada masa ini terdapat banyak penyelesaian peringkat aplikasi yang agak lengkap untuk hotKey di pasaran, antaranya JD.com mempunyai alat hotkey sumber terbuka dalam hal ini , prinsipnya adalah untuk membuat cerapan pada bahagian klien, dan kemudian melaporkan hotkey yang sepadan Selepas bahagian pelayan mengesannya, ia akan menghantar hotkey yang sepadan kepada pelayan yang sepadan untuk caching tempatan, dan cache tempatan ini akan dikemas kini secara serentak selepas. kunci sepadan jauh sudah dikemas kini. Ia kini merupakan penyelesaian 自动探测热key、分布式一致性缓存 yang agak matang, kunci panas runcit JD.com .

Ringkasan

Di atas adalah beberapa penyelesaian yang penulis fahami atau amalkan secara kasar tentang cara menangani hot key, bermula daripada penemuan kunci panas Untuk menyelesaikan dua masalah utama kunci panas. Setiap penyelesaian mempunyai kelebihan dan kekurangan, seperti ketidakkonsistenan perniagaan, kesukaran dalam pelaksanaan, dll. Anda boleh membuat pelarasan dan perubahan yang sepadan berdasarkan ciri semasa perniagaan anda sendiri dan infrastruktur syarikat semasa.

Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila lawati: Pengenalan kepada Pengaturcaraan! !

Atas ialah kandungan terperinci Mari kita bincangkan tentang cara menangani masalah kunci panas cache dalam Redis? Perkongsian penyelesaian biasa. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!