Apakah perkara teknikal Redis?

1 Mengapa menggunakan Redis

Apabila menggunakan Redis dalam projek, penulis percaya bahawa prestasi dan keselarasan perlu dipertimbangkan. Sudah tentu, Redis juga mempunyai fungsi lain yang boleh melakukan kunci teragih dan fungsi lain, tetapi jika ia hanya untuk fungsi lain seperti kunci teragih, terdapat perisian tengah lain (seperti Zookpeer, dll.) yang boleh digunakan sebagai gantinya, dan ia tidak perlu menggunakan Redis.

Oleh itu, soalan ini dijawab terutamanya dari dua perspektif: prestasi dan keselarasan:

Prestasi

Seperti yang ditunjukkan dalam rajah di bawah, apabila kita menghadapi SQL yang mengambil masa yang lama untuk dilaksanakan dan keputusan tidak kerap berubah, ia amat sesuai untuk meletakkan hasil yang sedang dijalankan ke dalam cache. Dengan cara ini, permintaan seterusnya dibaca daripada cache, supaya permintaan boleh dijawab dengan cepat.

Penyimpangan: Saya tiba-tiba ingin bercakap tentang standard untuk tindak balas pantas - sebenarnya, tiada standard tetap untuk masa tindak balas ini bergantung pada kesan interaksi. Seseorang pernah menyatakannya kepada saya: "Sebaik-baiknya, lompatan halaman kami harus diselesaikan serta-merta, dan operasi dalam halaman perlu diselesaikan dalam sekelip mata.". Di samping itu, operasi yang memakan masa yang mengambil masa lebih daripada satu sentuhan jari harus mempunyai gesaan kemajuan dan boleh digantung atau dibatalkan pada bila-bila masa, untuk memberikan pengguna pengalaman terbaik. ”

Jadi berapa banyak masa sesaat, sekejap, petik jari?

Menurut "Maha Sangha Vinaya": Satu saat adalah satu pemikiran, dua puluh pemikiran adalah satu seketika , dan dua puluh detik Satu petik jari ialah satu pukulan, dua puluh detik ialah satu saat, dan satu hari satu malam ialah tiga puluh saat

Jadi, selepas pengiraan yang teliti, satu detik ialah 0.36 saat, dan satu saat ialah. 0.018 saat, sehingga 7.2 saat dengan jentikan jari

2 Concurrency

Apabila concurrency tinggi, semua Meminta terus. akses kepada pangkalan data akan menyebabkan pengecualian sambungan pangkalan data, seperti yang ditunjukkan dalam rajah Untuk mengelakkan akses terus ke pangkalan data, kami boleh menggunakan Redis untuk menimbal dalam kes ini dan membiarkan permintaan mengakses Redis dahulu 🎜>

2 Apakah keburukan menggunakan Redis

Semua orang menggunakannya Redis telah digunakan Isu ini mesti difahami secara asasnya, anda akan menghadapi beberapa masalah apabila menggunakan Redis terutamanya empat aspek:

1 masalah konsistensi penulisan dua pangkalan data 2. Masalah cache avalanche

3. Masalah kerosakan cache

4. adalah perkara biasa, dan penyelesaian khusus akan diberikan kemudian tidak menyedari bahawa Redis menggunakan model kerja berutas tunggal Isu ini masih harus dikaji semula. mengelakkan penukaran konteks yang kerap

3. Gunakan mekanisme pemultipleksan I/O yang tidak menyekat

Mari kita bincangkan mekanisme pemultipleksan I/O dengan lebih terperinci, kerana istilah ini terlalu popular untuk orang biasa untuk memahami maksudnya. Contoh: Xiaoqu membuka kedai kurier di City S, yang bertanggungjawab untuk penghantaran ekspres intra-bandar Disebabkan kekangan kewangan, Xiaoqu pada mulanya mengupah banyak kurier, tetapi kemudiannya mendapati bahawa dia hanya mempunyai dana yang mencukupi untuk beroperasi. penghantaran ekspres dengan membeli kereta

Kaedah perniagaan satu:

Setiap kali pelanggan menghantar kurier, Xiaoqu membenarkan kurier mengawasinya, dan kemudian kurier memandu untuk menghantar kurier itu sedikit, Xiaoqu mendapati kewujudan kaedah perniagaan ini Terdapat banyak masalah pada dasarnya mengambil masa mereka untuk mengambil kereta bilangan penghantaran ekspres meningkat, begitu juga bilangan kurier mendapati bahawa kedai penghantaran ekspres semakin sesak, dan tidak ada cara untuk mengupah kurir baharu Penyelarasan antara kurier mengambil banyak masa masa dihabiskan untuk berebut kereta. Berdasarkan kelemahan di atas, Xiaoqu belajar daripada pengalaman dan mencadangkan kaedah perniagaan berikut↓

Kaedah perniagaan dua:

Xiaoqu hanya mengupah satu kurier, dan menandakan penghantaran ekspres daripada pelanggan mengikut destinasi, diletakkan dengan kemas di satu tempat. Akhirnya, kurier mengambil bungkusan mengikut urutan, satu demi satu, mengeluarkan bungkusan dan kemudian kembali untuk mendapatkan pakej seterusnya.

Membandingkan dua kaedah perniagaan di atas, adakah anda rasa kaedah kedua lebih cekap dan lebih baik? Dalam metafora di atas:

1. Setiap kurier → setiap utas

2 Setiap kurier → setiap Soket (aliran I/O) 3 ekspres → keadaan Soket yang berbeza 4. Permintaan pelanggan untuk menghantar ekspres → permintaan daripada pelanggan

5. Kaedah perniagaan Xiaoqu → ​​kod yang dijalankan pada pelayan

6. Satu kereta → Bilangan teras CPU

Jadi, kami mempunyai kesimpulan berikut:

1. penghantaran ekspres) Ada thread baru (courier) terurus.

2. Kaedah pengurusan kedua ialah pemultipleksan I/O. Kurier menguruskan berbilang aliran I/O dengan menjejaki status setiap aliran I/O Ia serupa dengan kurier yang hanya mempunyai seorang untuk menghantar setiap pakej dan perlu mengetahui status penghantaran setiap pakej.

Berikut ialah analogi kepada model benang Redis sebenar, seperti yang ditunjukkan dalam rajah:

Merujuk kepada rajah di atas, secara ringkasnya, Redis-client kami dalam Semasa operasi, Soket dengan jenis acara yang berbeza akan dihasilkan. Di bahagian pelayan, terdapat program pemultipleksan I/O yang meletakkannya dalam baris gilir. Kemudian penghantar acara fail mengambilnya dari baris gilir dan memajukannya ke pemproses acara yang berbeza.

Perlu diambil perhatian bahawa untuk mekanisme pemultipleksan I/O ini, Redis juga menyediakan perpustakaan fungsi pemultipleksan seperti Select, Epoll, Evport dan Kqueue Anda boleh mempelajarinya sendiri.

4 jenis data Redis dan senario penggunaan masing-masing

Apabila anda melihat soalan ini, adakah anda fikir ia sangat asas? Malah, saya juga fikir begitu. 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 lima jenis:

1 Rentetan

Ini sebenarnya Tiada apa-apa. untuk mengatakan. Untuk operasi Set/Dapatkan yang paling biasa, Nilai boleh sama ada String atau nombor Secara amnya, beberapa fungsi pengiraan kompleks dicache.

2 Hash

Nilai di sini ialah pembolehubah yang mengandungi objek berstruktur, yang membenarkan medan khusus manipulasi yang mudah. di dalamnya. Apabila pengarang melakukan log masuk tunggal, saya 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. Selain itu, anda juga boleh menggunakan arahan Lrange Redis untuk melaksanakan fungsi paging, yang mempunyai prestasi cemerlang dan boleh memberikan pengalaman pengguna yang baik.

4 Set

Oleh kerana Set menyusun koleksi nilai unik, ia boleh digunakan secara global Fungsi penyingkiran pendua .

Mengapa tidak menggunakan Set yang disertakan dengan JVM untuk mengalih keluar pendua? Oleh kerana sistem kami biasanya digunakan dalam kelompok, adalah menyusahkan untuk menggunakan Set yang disertakan dengan JVM Adakah perlu untuk mencipta perkhidmatan awam untuk melakukan penyahduplikasian global? Ia terlalu banyak masalah.

Selain itu, dengan menggunakan operasi seperti persimpangan, kesatuan dan perbezaan, anda boleh mengira pilihan biasa, semua pilihan dan pilihan unik anda sendiri.

5 Set Isih

Dengan memberikan parameter Skor kepada elemen dalam set, Set Isih boleh. diisih berdasarkan Skor. Anda boleh membuat aplikasi ranking dan mengambil operasi TOP N. Selain itu, Set Diisih juga boleh digunakan untuk melaksanakan tugas yang tertunda. Aplikasi terakhir adalah untuk melakukan carian julat.

5. Strategi tamat tempoh Redis dan mekanisme penghapusan ingatan

Kepentingan soalan ini adalah jelas, ia boleh mendedahkan sama ada Redis telah digunakan dengan betul. Contohnya, jika Redis anda hanya boleh menyimpan data 5G dan anda menulis 10G, data 5G akan dipadamkan. Bagaimanakah ia dipadamkan? Pernahkah anda berfikir tentang isu ini? Selain itu, data anda telah menetapkan masa tamat, tetapi apabila masa tamat, penggunaan memori masih agak tinggi. Pernahkah anda memikirkan sebabnya

Redis menggunakan strategi pemadaman biasa + pemadaman malas.

Mengapa tidak menggunakan strategi pemadaman berjadual?

Padam selalu Gunakan pemasa untuk memantau Kunci, dan ia akan dipadamkan secara automatik apabila tamat tempoh. Walaupun memori dikeluarkan dalam masa, ia menggunakan banyak sumber CPU. Di bawah permintaan serentak yang besar, CPU harus menggunakan masa untuk memproses permintaan dan bukannya memadamkan kunci, jadi strategi ini tidak diterima pakai.

Bagaimanakah pemadaman biasa + pemadaman malas berfungsi?

Padam secara kerap Secara lalai, Redis menyemak sama ada terdapat kunci tamat tempoh setiap 100ms dan memadamkan kunci tamat tempoh jika ditemui. Perlu diingat bahawa Redis tidak menyemak semua Kekunci setiap 100ms, tetapi memilih dan menyemaknya secara rawak (jika semua Kekunci disemak setiap 100ms, Redis tidak akan tersekat). Oleh itu, jika anda hanya menggunakan strategi pemadaman berkala, banyak kunci tidak akan dipadamkan sehingga akhir masa.

Jadi, pemadaman malas berguna. Maksudnya, apabila anda mendapat Kunci, Redis akan menyemak Jika masa tamat tempoh ditetapkan untuk Kunci ini, adakah ia telah tamat tempoh? Jika ia tamat tempoh, ia akan dipadamkan pada masa ini.

Adakah tiada masalah lain jika kita mengamalkan pemadaman biasa + pemadaman malas?

Tidak, jika anda memadamkannya dengan kerap, Kunci tidak akan dipadamkan. Kemudian anda tidak meminta Key in time, yang bermaksud pemadaman malas tidak berkuat kuasa. Untuk mengelakkan ingatan Redis daripada terus meningkat, mekanisme penghapusan ingatan perlu didayakan.

Terdapat baris konfigurasi dalam Redis.conf:

# maxmemory-policy volatile-lru

Konfigurasi ini dilengkapi dengan penghapusan memori strategi:

Noeviction: Apabila memori tidak mencukupi untuk menampung data yang baru ditulis, operasi tulis baharu akan melaporkan ralat. Tiada siapa yang sepatutnya menggunakannya;

Allkeys-lru: Apabila memori tidak mencukupi untuk menampung data yang baru ditulis, dalam ruang kekunci, keluarkan Kekunci yang paling kurang digunakan baru-baru ini. Disyorkan, ini sedang digunakan dalam projek;

Allkeys-random: Apabila memori tidak mencukupi untuk menampung data yang baru ditulis, kunci dialih keluar secara rawak daripada ruang kunci Tiada siapa yang menggunakannya;

Volatile-lru: Apabila memori tidak mencukupi untuk menampung data yang baru ditulis, dalam ruang kunci dengan set masa tamat, keluarkan Kekunci yang paling kurang digunakan baru-baru ini. Keadaan ini biasanya digunakan apabila Redis digunakan sebagai kedua-dua cache dan storan berterusan. Tidak disyorkan;

Rawak meruap: Apabila memori tidak mencukupi untuk menampung data yang baru ditulis, Kunci dikeluarkan secara rawak daripada ruang kunci dengan masa tamat tempoh. Masih tidak disyorkan;

Volatile-ttl: Apabila memori tidak mencukupi untuk menampung data yang baru ditulis, dalam ruang kunci dengan masa tamat tempoh, kunci dengan masa tamat tempoh lebih awal akan dialihkan 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 asasnya adalah sama seperti Noeviction (tiada pemadaman).

6 Redis dan pangkalan data dua-tulis isu konsisten

Isu konsistensi ialah isu yang diedarkan dan boleh dibahagikan lagi kepada konsistensi akhir dan konsistensi yang kuat. Jika pangkalan data dan cache ditulis dua kali, pasti akan ada ketidakkonsistenan Untuk menjawab soalan ini, kita mesti terlebih dahulu memahami premis: jika terdapat keperluan konsistensi yang kuat untuk data, cache tidak boleh diletakkan. Semua yang kami lakukan hanya boleh menjamin konsistensi akhirnya.

Penyelesaian yang kami cadangkan hanya boleh mengurangkan kemungkinan ketidakkonsistenan, tetapi tidak boleh menghapuskannya sepenuhnya. Oleh itu, data dengan keperluan konsistensi yang kukuh tidak boleh dicache.

"Pangkalan Data Teragih dan Penyelesaian Ketekalan Tulis Dua Cache"

memberikan analisis terperinci Berikut ialah penjelasan ringkas: Mula-mula, pakai strategi kemas kini yang betul dan kemas kini pangkalan data dahulu, dan kemudian padam cache; kedua, kerana mungkin terdapat masalah kegagalan untuk memadam cache, hanya sediakan langkah pampasan, seperti menggunakan baris gilir mesej.

7 Menangani masalah penembusan cache dan salji cache

<.>Secara amnya, syarikat perisian tradisional bersaiz kecil dan sederhana jarang menghadapi penembusan cache dan runtuhan cache. Jika anda ingin mengendalikan berjuta-juta trafik, dua isu ini mesti dipertimbangkan dengan teliti:

1 Menangani penembusan cache

Penembusan cache, iaitu, penggodam sengaja meminta data yang tidak wujud dalam cache, menyebabkan semua permintaan diarahkan ke pangkalan data, menyebabkan sambungan pangkalan data menjadi tidak normal.

Penyelesaian:

Gunakan kunci mutex Apabila cache gagal, mula-mula dapatkan kunci itu, kemudian minta pangkalan data Jika anda tidak mendapat kunci, tidur buat seketika dan cuba lagi;

1 Gunakan strategi kemas kini tak segerak, dan kembalikan terus tanpa mengira sama ada Kunci itu mempunyai nilai. Masa tamat cache dikekalkan dalam nilai Nilai Jika cache tamat tempoh, utas akan dimulakan secara tidak segerak untuk membaca pangkalan data dan mengemas kini cache Operasi pemanasan cache (memuatkan cache sebelum memulakan projek) diperlukan; 🎜>

2. Sediakan Mekanisme pemintasan yang boleh menentukan dengan cepat sama ada permintaan itu sah, seperti menggunakan penapis Bloom untuk mengekalkan secara dalaman siri Kunci yang sah dan sah dan dengan cepat menentukan sama ada Kunci yang dibawa dalam permintaan itu sah. dan sah jika tidak, ia akan dikembalikan terus.

2. Menangani runtuhan cache

Alanche cache, iaitu, kawasan besar kegagalan cache pada masa yang sama, kali ini sekali lagi Gelombang permintaan datang, dan akibatnya, semua permintaan dihantar ke pangkalan data, menyebabkan sambungan pangkalan data menjadi tidak normal.

Penyelesaian:

1 Tambah nilai rawak pada masa tamat cache untuk mengelakkan kegagalan kolektif; menurun;

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. Operasi prapemanasan cache dilakukan dengan sendirinya.

Kemudian bahagikan perkara berikut:

a. Baca pangkalan data dari cache A, dan kembalikan terus jika ada

b , terus Baca data daripada B, kembali terus, dan mulakan urutan kemas kini secara tidak segerak

c.

8 Bagaimana untuk menyelesaikan persaingan redis concurrency Masalah utama

Masalah ini kira-kira terdapat berbilang subsistem yang menetapkan Kunci pada masa yang sama. Dalam kes ini, berhati-hati harus diambil untuk menggunakan mekanisme transaksi Redis. Menurut hasil carian saya di Baidu terlebih dahulu, kebanyakan orang mengesyorkan kaedah ini. Tetapi saya tidak mengesyorkan menggunakan mekanisme transaksi Redis. Kami terutamanya menggunakan kluster Redis dalam persekitaran pengeluaran dan melakukan perkongsian data. Apabila anda melibatkan berbilang operasi Kunci dalam transaksi, Kunci ini tidak semestinya disimpan pada Pelayan Semula yang sama. Oleh itu, mekanisme transaksi Redis sangat tidak berguna. Penyelesaian adalah seperti berikut:

Jika susunan operasi Kunci ini tidak diperlukan

Dalam kes ini, sediakan kunci teragih untuk semua orang untuk mengambil Kunci, hanya lakukan operasi Set apabila anda mengambil kunci, yang agak mudah.

Jika urutan diperlukan untuk operasi Kunci ini

Andaikan terdapat Kunci1 Sistem A perlu menetapkan Kunci1 kepada NilaiA, sistem B perlu menetapkan Kunci1 kepada NilaiB dan sistem C perlu menetapkan Kunci1 kepada NilaiC. Diharapkan nilai Key1 akan berubah mengikut susunan ValueA→ValueB→ValueC. Pada masa ini, kita perlu menyimpan cap masa semasa menulis data ke pangkalan data. Anggapkan bahawa cap masa adalah seperti berikut:

1 Sistem A Kunci 1 {NilaiA 3:00}

2. Sistem B Kunci 1 {NilaiB 3:05}

3. Kunci Sistem C 1 {ValueC 3:10}

Jadi, andaikan sistem B mengambil kunci dahulu dan menetapkan Key1 kepada {ValueB 3:05}. Jika sistem A mengambil kunci dan mendapati bahawa cap masa ValueA lebih awal daripada cap masa dalam cache, operasi Set tidak akan dilakukan. Dan seterusnya.

Atas ialah kandungan terperinci Apakah perkara teknikal Redis?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!