1. Mengapa menggunakan Redis
Blogger percaya bahawa pertimbangan utama untuk menggunakan redis dalam projek adalah prestasi dan keselarasan. Sudah tentu, redis juga mempunyai fungsi lain seperti kunci yang diedarkan, tetapi jika ia hanya untuk fungsi lain seperti kunci yang diedarkan, terdapat perisian tengah lain (seperti zookpeer, dll.) sebaliknya, dan tidak perlu menggunakan redis. Oleh itu, soalan ini dijawab terutamanya dari dua perspektif: prestasi dan konkurensi.
Jawapan: Seperti yang ditunjukkan di bawah, dibahagikan kepada dua mata
(1) Prestasi
Apabila masa pelaksanaan diperlukan Bila SQL adalah sangat panjang dan hasilnya tidak kerap berubah, kami mengesyorkan menyimpan keputusan dalam cache. Dengan cara ini, permintaan seterusnya akan dibaca daripada cache, supaya permintaan boleh dijawab dengan cepat.
Luar topik: Saya tiba-tiba ingin bercakap tentang standard respons pantas ini. Malah, bergantung pada kesan interaksi, tiada piawaian tetap untuk masa tindak balas ini. Tetapi seseorang pernah memberitahu saya: "Dalam dunia yang ideal, lompatan halaman kami perlu diselesaikan dalam sekelip mata, dan operasi dalam halaman perlu diselesaikan dengan segera. Untuk memberikan pengalaman pengguna yang terbaik, operasi yang mengambil masa lebih daripada satu saat harus diberikan gesaan Kemajuan dan membenarkan penggantungan atau pembatalan pada bila-bila masa "
Jadi berapa lama masa yang diambil dalam sekelip mata, sekejap atau sekejap?
Menurut rekod "Maha Sangha Vinaya"
Satu saat adalah satu pemikiran, dua puluh pemikiran adalah satu saat, dua puluh saat adalah satu jentikan jari, dua puluh jentikan jari adalah satu Luo Su, dua puluh Luo Ramalan awal adalah satu saat, satu hari dan satu malam adalah tiga puluh saat.
Jadi, selepas pengiraan yang teliti, sesaat ialah 0.36 saat, sesaat ialah 0.018 saat, dan satu petik jari ialah 7.2 saat.
(2) Concurrency
Seperti yang ditunjukkan dalam rajah di bawah, dalam kes concurrency yang besar, semua permintaan mengakses terus pangkalan data, dan pengecualian sambungan akan berlaku dalam pangkalan data. Dalam kes ini, menggunakan operasi penimbalan Redis adalah perlu supaya permintaan terlebih dahulu mengakses Redis dan bukannya mengakses pangkalan data secara langsung.
2. Apakah keburukan menggunakan Redis? mesti difahami pada asasnya, anda akan menghadapi beberapa masalah apabila menggunakan redis, dan terdapat hanya beberapa masalah biasa.
Jawapan: Terutamanya empat soalan(1) Masalah ketekalan tulis dua cache dan pangkalan data
(2) Masalah runtuhan cache
(3) Masalah kerosakan cache
(4) Masalah perbalahan koncurrency cache
Ini saya sendiri rasa empat masalah ini agak biasa dalam projek Penyelesaian khusus diberikan di bawah.
Anda boleh merujuk kepada: "Cache avalanche, penembusan cache, cache preheating, cache update, cache degradation and other issues! 》3. Mengapakah Redis berbenang tunggal begitu pantas?
Analisis: Soalan ini sebenarnya adalah penyiasatan tentang mekanisme dalaman redis. Mengikut pengalaman temu bual penulis blog, ramai orang sebenarnya tidak memahami model kerja single-threaded Redis. Oleh itu, isu ini masih harus dikaji semula.
Jawapan: Terutamanya tiga perkara berikut
(1) Operasi memori tulen
(2) Operasi satu benang, mengelakkan penukaran konteks yang kerapMod Perniagaan 1
Setiap kali pelanggan menghantar kurier, Xiaoqu akan menugaskan kurier untuk mengawasinya, dan kemudian kurier akan memandu untuk menghantar kurier . Perlahan-lahan Xiaoqu menemui masalah berikut dengan kaedah perniagaan iniPuluhan kurier pada dasarnya menghabiskan masa mereka merompak kereta, dan kebanyakan kurir menghadapi masalah dalam keadaan terbiar, sesiapa yang mengambil kereta itu boleh menghantar kurier
Apabila bilangan kurier bertambah, begitu juga kurier mendapati kedai kurier semakin sesak , tidak ada cara untuk mengupah kurier baharuMod perniagaan dua
Perbandingan
Membandingkan dua kaedah perniagaan di atas, adakah jelas bahawa kaedah kedua lebih cekap dan lebih baik? Dalam metafora di atas:Setiap kurier -------------------> Setiap utas
Setiap ekspres --------------------> Setiap soket (strim I/O)
Permintaan pelanggan untuk penghantaran ekspres-------------->Permintaan daripada pelanggan
Kaedah perniagaan Xiaoqu- - ------------>Kod berjalan pada pelayan
Sebuah kereta---------------- -- ----->Bilangan teras CPU
Jadi kami mempunyai kesimpulan berikut
1 Kaedah perniagaan pertama ialah model konkurensi tradisional, setiap I /. Strim O (Express) diuruskan oleh utas baharu (Expressor).
2. Kaedah pengurusan kedua ialah pemultipleksan I/O. Hanya terdapat satu utas (kurier) yang menguruskan berbilang aliran I/O dengan menjejak status setiap aliran I/O (lokasi penghantaran setiap kurier).
Berikut adalah analogi kepada model benang redis sebenar, seperti yang ditunjukkan dalam rajah
Rujuk rajah di atas, secara ringkasnya, ia ialah. Semasa operasi, pelanggan Redis kami akan mencipta soket dengan jenis acara yang berbeza. Di bahagian pelayan, terdapat program pemultipleksan I/0 yang meletakkannya dalam baris gilir. Kemudian, penghantar acara fail mengambilnya dari baris gilir dan memajukannya kepada pemproses acara yang berbeza.
Perlu diambil perhatian bahawa untuk mekanisme pemultipleksan I/O ini, redis juga menyediakan perpustakaan fungsi pemultipleksan seperti pilih, epoll, evport dan kqueue Anda boleh mempelajarinya sendiri.
4. Jenis data Redis dan senario penggunaan setiap jenis data
Analisis: Adakah anda fikir soalan ini sangat asas? Walau bagaimanapun, mengikut pengalaman temu duga, sekurang-kurangnya 80% orang tidak dapat menjawab soalan ini. Adalah disyorkan bahawa selepas menggunakannya dalam projek, anda boleh menghafalnya dengan analogi untuk mendapatkan pengalaman yang lebih mendalam dan bukannya menghafalnya dengan hati. Pada asasnya, pengaturcara yang berkelayakan akan menggunakan semua lima jenis.
Jawapan: Terdapat lima jenis
(1) Rentetan
Ini sebenarnya sangat biasa, melibatkan operasi dapatkan/set yang paling asas, nilai boleh menjadi String atau nombor. Secara amnya, beberapa fungsi pengiraan kompleks dicache.
(2)cincang
Nilai di sini menyimpan objek berstruktur dan lebih mudah untuk mengendalikan salah satu medan. Apabila blogger melakukan log masuk tunggal, mereka menggunakan struktur data ini untuk menyimpan maklumat pengguna, menggunakan cookieId sebagai kunci dan menetapkan 30 minit sebagai masa tamat tempoh cache, yang boleh mensimulasikan kesan seperti sesi dengan baik.
(3) senarai
Menggunakan struktur data Senarai, anda boleh melaksanakan fungsi baris gilir mesej ringkas. Selain itu, kami juga boleh menggunakan perintah lrange untuk melaksanakan fungsi paging berasaskan Redis Kaedah ini mempunyai prestasi dan pengalaman pengguna yang sangat baik.
(4) set
Kerana set ialah koleksi nilai unik. Oleh itu, fungsi deduplikasi global boleh dilaksanakan. Mengapa tidak menggunakan Set yang disertakan dengan JVM untuk penyahduplikasian? Kerana sistem kami biasanya digunakan dalam kelompok, adalah menyusahkan untuk menggunakan Set yang disertakan dengan JVM Adakah terlalu menyusahkan untuk menyediakan perkhidmatan awam hanya untuk melakukan penduaan global?
Selain itu, dengan menggunakan persilangan, kesatuan, perbezaan dan operasi lain, anda boleh mengira pilihan biasa, semua pilihan, pilihan unik anda sendiri dan fungsi lain.
(5) set diisih
set diisih mempunyai skor parameter berat tambahan, dan elemen dalam set boleh disusun mengikut skor. Anda boleh membuat aplikasi ranking dan mengambil operasi TOP N. Di samping itu, dalam artikel bertajuk "Analisis Skim Tugasan Tertunda Teragih", disebutkan bahawa set diisih boleh digunakan untuk melaksanakan tugas tertunda. Aplikasi terakhir adalah untuk melakukan carian julat.
5. Strategi tamat tempoh Redis dan mekanisme penghapusan ingatan
Kepentingan isu ini adalah jelas dan dapat dilihat sama ada Redis digunakan. Contohnya, jika anda hanya boleh menyimpan 5 GB data dalam Redis, tetapi anda menulis 10 GB data, 5 GB data akan dipadamkan. Bagaimana anda memadamkannya? Selain itu, data anda telah menetapkan masa tamat tempoh, tetapi apabila masa tamat, penggunaan memori masih agak tinggi. Pernahkah anda memikirkan sebabnya
Jawapan:
Redis menggunakan pemadaman biasa. + Strategi pemadaman malas.
Mengapa tidak menggunakan strategi pemadaman berjadual
Pemadaman berjadual, gunakan pemasa untuk memantau kunci dan padamkannya secara automatik apabila tamat tempoh. Walaupun memori dikeluarkan dalam masa, ia menggunakan banyak sumber CPU. Memandangkan di bawah permintaan serentak yang tinggi, CPU perlu menumpukan pada pemprosesan permintaan dan bukannya operasi pemadaman nilai utama, kami berputus asa menggunakan strategi ini
Bagaimanakah pemadaman biasa + pemadaman malas berfungsi?
Padam secara tetap Redis menyemak setiap 100ms secara lalai untuk melihat jika terdapat kunci tamat tempoh, padamkannya. Perlu diingat bahawa redis tidak menyemak semua kekunci setiap 100ms, tetapi memilihnya secara rawak untuk pemeriksaan (jika semua kekunci disemak setiap 100ms, bukankah redis akan tersekat)? Jika anda hanya menggunakan strategi pemadaman berkala, banyak kunci tidak akan dipadamkan selepas masa tamat tempoh.
Jadi, pemadaman malas berguna. Maksudnya, apabila anda mendapat kunci, redis akan menyemak sama ada kunci telah tamat tempoh jika ia mempunyai masa tamat tempoh yang ditetapkan? Jika ia tamat tempoh, ia akan dipadamkan pada masa ini.
Adakah tiada masalah lain jika kita mengamalkan pemadaman biasa + pemadaman malas?
Tidak, jika kunci tidak dipadamkan jika ia dipadamkan dengan kerap. Kemudian anda tidak meminta kunci serta-merta, yang bermaksud pemadaman malas tidak berkuat kuasa. Dengan cara ini, ingatan redis akan menjadi lebih tinggi dan lebih tinggi. Kemudian mekanisme penghapusan ingatan harus diguna pakai.
Terdapat baris konfigurasi dalam redis.conf
# maxmemory-policy volatile-lru
Konfigurasi ini dikonfigurasikan dengan strategi penghapusan memori (apa, anda tidak mempunyai' t mengkonfigurasinya? Okay Refleksi pada diri sendiri)
1) noeviction: Apabila memori tidak mencukupi untuk menampung data yang baru ditulis, operasi tulis baharu akan melaporkan ralat. Tiada siapa yang harus menggunakannya.
Apabila ruang memori tidak mencukupi untuk menyimpan data baharu, algoritma allkeys-lru akan mengalih keluar kunci yang paling kurang digunakan baru-baru ini daripada ruang kunci. Disyorkan, sedang digunakan dalam projek.
3) allkeys-random: Apabila memori tidak mencukupi untuk menampung data yang baru ditulis, kunci dialih keluar secara rawak daripada ruang kunci. Tiada siapa yang sepatutnya menggunakannya Jika anda tidak mahu memadamkannya, sekurang-kurangnya gunakan Kekunci dan padamkannya secara rawak.
4) volatile-lru: Apabila memori tidak mencukupi untuk menampung data yang baru ditulis, dalam ruang kekunci dengan set masa tamat, kunci yang paling kurang digunakan baru-baru ini dialih keluar. Secara amnya, kaedah ini hanya digunakan apabila redis digunakan sebagai kedua-dua cache dan storan berterusan. Tidak disyorkan
5) rawak meruap: Apabila memori tidak mencukupi untuk menampung data yang baru ditulis, kunci dialih keluar secara rawak daripada ruang kunci dengan masa tamat tempoh ditetapkan. Masih tidak disyorkan
6) volatile-ttl: Apabila memori tidak mencukupi untuk menampung data yang baru ditulis, dalam ruang kunci dengan masa tamat tempoh ditetapkan, kunci dengan masa tamat tempoh lebih awal akan dialih keluar terlebih dahulu. Tidak disyorkan
ps: Jika kunci tamat tempoh tidak ditetapkan dan prasyarat tidak dipenuhi maka kelakuan strategi volatile-lru, volatile-random dan volatile-ttl pada dasarnya adalah sama seperti noeviction (tidak dipadamkan) .
6. Isu ketekalan tulis dua kali redis dan pangkalan data
Dalam sistem teragih, isu konsistensi adalah masalah biasa. Masalah ini boleh dibezakan lagi kepada konsistensi akhirnya dan konsistensi yang kuat. Jika pangkalan data dan cache ditulis dua kali, pasti akan ada ketidakkonsistenan. Untuk menjawab soalan ini, fahami premis terlebih dahulu. Iaitu, jika terdapat keperluan konsistensi yang kuat untuk data, ia tidak boleh dicache. Semua yang kami lakukan hanya boleh menjamin konsistensi akhirnya. Penyelesaian yang kami cadangkan sebenarnya hanya boleh mengurangkan kebarangkalian kejadian yang tidak konsisten, tetapi tidak boleh menghapuskannya sepenuhnya. Oleh itu, data dengan keperluan konsistensi yang kukuh tidak boleh dicache.
Berikut ialah pengenalan ringkas kepada analisis terperinci dalam artikel "Analisis Pangkalan Data Teragih dan Skim Konsistensi Tulis Dua Cache". Mula-mula, pakai strategi kemas kini yang betul, kemas kini pangkalan data dahulu, dan kemudian padamkan cache. Sediakan langkah sandaran, seperti menggunakan baris gilir mesej, sekiranya pemadaman cache gagal.
7. Cara menangani masalah penembusan cache dan salji cache
Syarikat perisian tradisional bersaiz kecil dan sederhana jarang menghadapi dua masalah ini, sejujurnya. Jika terdapat projek serentak yang besar, trafik akan menjadi sekitar berjuta-juta. Kedua-dua isu ini mesti dipertimbangkan secara mendalam.
Jawapan: Seperti yang ditunjukkan di bawah
Penembusan cache, iaitu, penggodam sengaja meminta data yang tidak wujud dalam cache, menyebabkan semua permintaan dihantar ke pangkalan data , oleh itu pengecualian sambungan pangkalan data.
Penyelesaian:
Apabila cache gagal, gunakan kunci mutex untuk memperoleh kunci dahulu, dan kemudian minta pangkalan data sebaik sahaja kunci diperoleh. Jika kunci tidak diperoleh, kemudian tidur untuk tempoh masa dan cuba lagi
(2) Gunakan strategi kemas kini tak segerak dan kembali terus tanpa mengira sama ada kunci itu mempunyai nilai. Simpan masa tamat cache dalam nilai nilai Setelah cache tamat tempoh, benang akan dimulakan secara tidak segerak untuk membaca pangkalan data dan mengemas kini cache. Operasi prapemanasan cache (memuatkan cache sebelum memulakan projek) diperlukan.
Menyediakan mekanisme pemintasan yang boleh menentukan dengan cepat sama ada permintaan itu sah. Contohnya, gunakan penapis Bloom untuk mengekalkan siri kunci yang sah dan sah secara dalaman. Tentukan dengan cepat sama ada Kunci yang dibawa dalam permintaan itu sah dan sah. Kalau haram balik terus.
Cache avalanche, iaitu, cache gagal di kawasan yang besar pada masa yang sama Pada masa ini, gelombang permintaan lain datang, dan akibatnya, semua permintaan dihantar ke pangkalan data, mengakibatkan. sambungan pangkalan data yang tidak normal.
Penyelesaian:
(1) Tambahkan nilai rawak pada masa tamat tempoh cache untuk mengelakkan kegagalan kolektif.
(2) Gunakan kunci mutex, tetapi daya pemprosesan penyelesaian ini menurun dengan ketara.
(3) Penimbalan berganda. Kami mempunyai dua cache, cache A dan cache B. Masa tamat tempoh cache A ialah 20 minit, dan tiada masa tamat tempoh untuk cache B. Lakukan sendiri operasi pemanasan cache. Kemudian pecahkan perkara berikut
Saya membaca pangkalan data daripada cache A, dan kembali terus jika ada
II A tidak mempunyai data , jadi ia kembali terus daripada cache A B membaca data, kembali terus dan memulakan urutan kemas kini secara tidak segerak.
III Urutan kemas kini mengemas kini cache A dan cache B pada masa yang sama.
8 Bagaimana untuk menyelesaikan masalah persaingan utama serentak dalam Redis
Analisis: Masalah ini secara kasarnya ialah terdapat berbilang subsistem yang menetapkan kunci pada masa yang sama. Apakah yang perlu kita perhatikan pada masa ini? Pernahkah anda memikirkannya? Selepas menyemak hasil carian Baidu terlebih dahulu, penulis blog mendapati hampir semua jawapan disyorkan menggunakan mekanisme transaksi redis. Blogger tidak mengesyorkan menggunakan mekanisme transaksi redis. Oleh kerana persekitaran pengeluaran kami pada asasnya ialah persekitaran kluster redis, operasi perkongsian data dilakukan. Apabila satu tugasan melibatkan berbilang operasi kunci, kunci ini tidak semestinya disimpan pada pelayan Redis yang sama. Oleh itu, mekanisme transaksi redis sangat tidak berguna.
Jawapan: Seperti yang ditunjukkan di bawah
(1) Jika anda mengendalikan kunci ini, pesanan tidak diperlukan
Dalam kes ini, sediakan diedarkan Untuk kunci, semua orang mengambil kunci Setelah anda mengambil kunci, lakukan sahaja operasi yang ditetapkan.
(2) Jika anda mengendalikan kunci ini, urutan yang diperlukan ialah
Andaikan terdapat kunci1, sistem A perlu menetapkan kunci1 kepada nilaiA, sistem B perlu menetapkan kunci1 kepada nilaiB dan sistem C perlu menetapkan kunci1 kepada nilaiB.kunci1 ditetapkan kepada nilaiC
menjangkakan nilai kunci1 akan berubah dalam susunan nilaiA-->nilaiB-->nilaiC. Pada masa ini, kita perlu menyimpan cap masa semasa menulis data ke pangkalan data. Andaikan cap masa adalah seperti berikut: 10}
Bayangkan jika sistem B memperoleh kunci terlebih dahulu, ia akan menetapkan nilai kunci1 kepada {valueB 3:05}. Apabila sistem A memperoleh kunci, jika ia mendapati bahawa cap masa nilaiA yang disimpannya lebih awal daripada cap masa yang disimpan dalam cache, sistem A tidak akan melaksanakan operasi yang ditetapkan. Dan seterusnya.
Kaedah lain, seperti menggunakan baris gilir dan menukar kaedah yang ditetapkan kepada akses bersiri, juga boleh digunakan. Pendek kata, bersikap fleksibel.
Atas ialah kandungan terperinci Apakah lapan masalah klasik Redis?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
Perisian pangkalan data yang biasa digunakan
Apakah pangkalan data dalam memori?
Yang manakah mempunyai kelajuan bacaan yang lebih pantas, mongodb atau redis?
Cara menggunakan redis sebagai pelayan cache
Bagaimana redis menyelesaikan ketekalan data
Bagaimanakah mysql dan redis memastikan konsistensi penulisan dua kali?
Apakah data yang biasanya disimpan oleh redis cache?
Apakah 8 jenis data redis
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
