String: redis tidak secara langsung menggunakan perwakilan rentetan tradisional bahasa C, tetapi melaksanakan jenis abstrak SDS rentetan dinamik ringkasnya sendiri . Rentetan dalam bahasa C tidak merekodkan maklumat panjangnya sendiri, tetapi SDS menyimpan maklumat panjang, yang mengurangkan masa untuk mendapatkan panjang rentetan daripada O(N) kepada O(1), sambil mengelakkan limpahan penimbal dan mengurangkan keperluan untuk mengubah suai aksara . Bilangan pengagihan semula memori yang diperlukan untuk panjang rentetan.
Senarai terpaut: Senarai terpaut redis ialah struktur senarai terpaut dua hala terdiri daripada Diwakili oleh struktur listNode, setiap nod mempunyai penunjuk ke nod sebelumnya dan nod berikutnya, dan pada masa yang sama, nod sebelumnya dan seterusnya nod pengepala menghala ke NULL.
Hashtable kamus: struktur data abstrak yang digunakan untuk menyimpan pasangan nilai kunci. Redis menggunakan jadual cincang sebagai pelaksanaan asas Setiap kamus mempunyai dua jadual cincang untuk kegunaan harian dan jadual cincang menggunakan kaedah alamat rantaian untuk menyelesaikan konflik utama dan ditetapkan kepada berbilang pasangan nilai kunci pada kedudukan indeks yang sama senarai terpaut -way akan terbentuk Apabila jadual cincang dikembangkan atau dikurangkan, demi ketersediaan perkhidmatan, proses pencincangan tidak selesai sekaligus, tetapi secara beransur-ansur.
Langkau senarai: Langkau senarai ialah salah satu pelaksanaan asas bagi set tertib digunakan dalam redis untuk melaksanakan kunci set tertib dan struktur dalaman nod kelompok. Jadual langkau redis terdiri daripada zskiplist dan zskiplistNode digunakan untuk menyimpan maklumat jadual langkau (pengepala, nod ekor, panjang, dsb. zskiplistNode digunakan untuk mewakili nod langkau jadual hingga 32. Nombor, dalam jadual lompat yang sama, berbilang nod boleh mengandungi skor yang sama, tetapi objek ahli setiap nod mestilah unik Nod disusun mengikut saiz skor diisih mengikut saiz objek ahli.
Integer set integer: Struktur data abstrak koleksi yang digunakan untuk menyimpan nilai integer Tidak akan ada unsur pendua Pelaksanaan asas ialah tatasusunan.
Senarai zip senarai termampat: Senarai termampat ialah struktur data berjujukan yang dibangunkan untuk menyimpan memori Ia boleh mengandungi berbilang nod dan setiap nod boleh menyimpan tatasusunan bait atau nilai integer.
Berdasarkan struktur data asas ini, redis merangkum sistem objeknya sendiri, termasuk rentetan objek rentetan, senarai objek senarai, hash objek hash, set objek koleksi dan zset objek koleksi tersusun, setiap satu objek menggunakan sekurang-kurangnya satu struktur data asas.
Redis menetapkan bentuk pengekodan objek melalui atribut pengekodan untuk meningkatkan fleksibiliti dan kecekapan secara automatik Redis akan membuat pengoptimuman berdasarkan senario yang berbeza. Pengekodan objek berbeza adalah seperti berikut:
Rentetan objek rentetan: integer integer, rentetan dinamik ringkas yang dikodkan oleh embstr, rentetan dinamik ringkas mentah
Senarai senarai objek: ziplist, senarai terpaut
Hash objek hash: ziplist, hashtable
Set objek koleksi: intset, jadual hash
Zset objek koleksi dipesan: senarai zip, senarai langkau
Redis sangat pantas Satu redis boleh menyokong berpuluh-puluh ribu mata wang sesaat Berbanding dengan mysql, prestasinya berpuluh-puluh kali ganda daripada mysql. Sebab utama kelajuan pantas ialah:
Sepenuhnya berdasarkan operasi memori
Pelaksanaan bahasa C, struktur data yang dioptimumkan, berdasarkan beberapa struktur data asas, redis telah melakukan banyak pengoptimuman dan prestasinya sangat tinggi
Menggunakan urutan tunggal, tiada kos penukaran konteks
Berdasarkan mekanisme pemultipleksan IO tanpa Menyekat
redis tidak menggunakan berbilang -threading Sekiranya kita meninggalkan sepenuhnya satu threading? Redis masih menggunakan model satu thread untuk memproses permintaan klien Ia hanya menggunakan multi-threading untuk mengendalikan pembacaan dan penulisan data dan penghuraian protokol.
Tujuan ini adalah kerana kesesakan prestasi redis adalah IO rangkaian dan bukannya CPU Menggunakan multi-threading boleh meningkatkan kecekapan membaca dan menulis IO, dengan itu meningkatkan prestasi keseluruhan redis.
Apa yang dipanggil masalah kunci panas ialah tiba-tiba terdapat ratusan ribu permintaan untuk mengakses kunci tertentu pada redis Ini akan menyebabkan trafik menjadi terlalu tertumpu dan mencapai had atas kad rangkaian fizikal, sekali gus menyebabkan redis kepada pelayan ranap menyebabkan runtuhan salji.
Penyelesaian untuk kekunci panas:
Edarkan kunci panas kepada pelayan yang berbeza terlebih dahulu untuk mengurangkan tekanan
Tambahkan tahap kedua cache dan muatkan data kunci panas ke dalam memori lebih awal Jika redis tidak berfungsi, gunakan pertanyaan memori
Konsep pecahan cache ialah akses serentak satu kunci adalah terlalu tinggi Apabila ia tamat tempoh, semua permintaan akan dipukul terus ke db ini adalah serupa dengan masalah kekunci panas , tetapi maksudnya ialah tamat tempoh menyebabkan semua permintaan dipukul ke DB.
Penyelesaian:
Kunci kemas kini, sebagai contoh, minta pertanyaan A dan mendapati ia tiada dalam cache, kunci kekunci A dan pada masa yang sama pergi ke pangkalan data untuk menanyakan data dan tulis Cache, dan kemudian kembalikan kepada pengguna, supaya permintaan seterusnya boleh mendapatkan data daripada cache.
Tulis gabungan masa tamat tempoh dalam nilai, dan sentiasa segarkan masa tamat tempoh secara tak segerak untuk mengelakkan fenomena jenis ini.
Penembusan cache bermaksud pertanyaan data yang tidak wujud dalam cache Setiap permintaan akan memukul DB, seolah-olah cache tidak wujud.
Untuk menangani masalah ini, tambahkan lapisan penapis Bloom. Langkah operasi penapis Bloom adalah untuk memetakan data ke titik K dalam tatasusunan bit melalui fungsi cincang, dan menetapkan titik ini kepada 1 untuk menyimpan data.
Dengan cara ini, apabila pengguna bertanya kepada A sekali lagi, dan nilai penapis Bloom A ialah 0, ia akan dikembalikan secara langsung dan tiada permintaan pecahan akan dijana dan memukul DB.
Jelas sekali, akan ada masalah selepas menggunakan penapis Bloom, iaitu salah menilai Kerana ia adalah tatasusunan itu sendiri, mungkin terdapat beberapa nilai yang jatuh ke dalam kedudukan yang sama panjang tatasusunan kami Jika ia cukup panjang, kebarangkalian salah penilaian akan lebih rendah Masalah seperti ini harus ditangani berdasarkan situasi sebenar.
Apabila kegagalan cache berskala besar berlaku pada masa tertentu, sebagai contoh, perkhidmatan cache anda tidak berfungsi, sejumlah besar permintaan akan masuk dan memukul DB secara langsung, yang boleh membawa kepada keruntuhan keseluruhan sistem dipanggil runtuhan salji. Tidak seperti masalah pecahan dan kunci panas, masalah runtuhan salji merujuk kepada tamat tempoh serentak cache berskala besar.
Beberapa penyelesaian untuk runtuhan salji:
Tetapkan masa tamat tempoh yang berbeza untuk kunci yang berbeza untuk mengelakkan tamat tempoh serentak
Strim Terhad, jika redis tidak berfungsi, strim boleh dihadkan untuk mengelakkan sejumlah besar permintaan pada masa yang sama daripada ranap DB
cache peringkat kedua dan penyelesaian kunci panas yang sama.
Redis terutamanya mempunyai 2 strategi pemadaman tamat tempoh
Pemadaman malas bermakna kunci dikesan hanya apabila ia ditanya dan jika ia telah tamat tempoh, ia adalah padam. Jika kunci tamat tempoh ini tidak diakses, kelemahan yang jelas ialah ia akan terus menduduki memori dan tidak boleh dipadamkan.
Dalam Redis, pemadaman berkala adalah untuk menyemak pasangan nilai kunci dalam pangkalan data pada masa tertentu dan memadamkan pasangan nilai kunci tamat tempoh. Redis tidak boleh melakukan pengundian untuk semua kunci semasa memadamkan operasi, jadi beberapa kunci dipilih secara rawak untuk pemeriksaan dan pemadaman.
Dengan mengandaikan bahawa redis tidak memadamkan kunci setiap kali ia menanyakan kunci secara rawak dengan kerap, dan kunci ini tidak disoal, ia akan menyebabkan kunci ini disimpan dalam redis dan tidak boleh dipadamkan, dan kemudian ia akan hilang Kepada mekanisme penghapusan ingatan redis.
volatile-lru: Keluarkan kunci yang paling kurang digunakan baru-baru ini daripada kekunci dengan masa tamat tempoh ditetapkan untuk penyingkiran
volatile-ttl: Dari Antara kunci dengan set masa tamat tempoh, keluarkan kunci yang hampir tamat tempoh
rawak meruap: pilih kekunci secara rawak daripada kekunci dengan masa tamat tempoh ditetapkan untuk menghapuskan
allkeys-lru: Pilih kekunci yang paling kurang digunakan baru-baru ini daripada kekunci untuk penyingkiran
allkeys-random: Pilih secara rawak kekunci daripada kekunci untuk penyingkiran
noeviction: Apabila memori mencapai ambang, ralat dilaporkan untuk operasi tulis baharu
Penyelesaian kegigihan Redis terbahagi kepada dua jenis: RDB dan AOF.
Kegigihan RDB boleh dilaksanakan secara manual atau berkala mengikut konfigurasi Fungsinya adalah untuk menyimpan status pangkalan data pada masa tertentu ke fail RDB ialah a dimampatkan Fail binari yang melaluinya keadaan pangkalan data pada masa tertentu boleh dipulihkan. Memandangkan fail RDB disimpan pada cakera keras, walaupun redis ranap atau keluar, selagi fail RDB wujud, ia boleh digunakan untuk memulihkan keadaan pangkalan data.
Fail RDB boleh dijana melalui SAVE atau BGSAVE.
Arahan SAVE akan menyekat proses redis sehingga fail RDB dijana Semasa tempoh penyekatan proses, redis tidak boleh memproses sebarang permintaan arahan, yang jelas tidak sesuai.
BGSAVE akan menghentikan proses anak, dan kemudian proses anak akan bertanggungjawab untuk menjana fail RDB Proses induk boleh terus memproses permintaan arahan tanpa menyekat proses tersebut.
AOF berbeza daripada RDB merekodkan status pangkalan data dengan menyimpan arahan tulis yang dilaksanakan oleh pelayan redis.
AOF melaksanakan mekanisme kegigihan melalui tiga langkah: tambah, tulis dan segerakkan.
Apabila kegigihan AOF diaktifkan dan pelayan melaksanakan arahan tulis, arahan tulis akan dilampirkan pada penghujung penimbal aof_buf
Sebelum setiap gelung acara berakhir dalam pelayan, fungsi flushAppendOnlyFile akan dipanggil untuk menentukan sama ada untuk menyimpan kandungan aof_buf ke fail AOF Ini boleh ditentukan dengan mengkonfigurasi appendfsync.
always ##aof_buf内容写入并同步到AOF文件 everysec ##将aof_buf中内容写入到AOF文件,如果上次同步AOF文件时间距离现在超过1秒,则再次对AOF文件进行同步 no ##将aof_buf内容写入AOF文件,但是并不对AOF文件进行同步,同步时间由操作系统决定
Jika tidak ditetapkan, pilihan lalai ialah everysec, kerana walaupun sentiasa adalah yang paling selamat (hanya satu arahan tulis gelung peristiwa akan hilang), prestasinya lemah, dan setiap saat mod mungkin hanya kehilangan 1 saat data, manakala kecekapan mod tiada adalah serupa dengan setiap detik, tetapi semua data arahan tulis selepas penyegerakan terakhir fail AOF akan hilang.
Untuk mencapai ketersediaan tinggi, satu mesin pastinya tidak mencukupi Untuk memastikan ketersediaan tinggi, redis mempunyai dua pilihan.
Mod tuan-hamba ialah penyelesaian paling mudah untuk mencapai ketersediaan tinggi, dan terasnya ialah penyegerakan tuan-hamba. Prinsip penyegerakan tuan-hamba adalah seperti berikut:
hamba menghantar arahan penyegerakan kepada tuan
Selepas tuan menerima penyegerakan, ia melaksanakan bgsave dan menjana fail RDB penuh. kepada hamba, dan hamba melaksanakan
Tuan menghantar perintah tulis dalam cache kepada hamba, dan hamba melaksanakan
The arahan yang saya tulis di sini ialah penyegerakan, tetapi ia telah digunakan selepas versi redis2.8 psync telah digunakan untuk menggantikan penyegerakan Sebabnya ialah arahan penyegerakan menggunakan sumber sistem, dan psync lebih cekap.
Kekurangan skema tuan-hamba masih jelas Jika tuan turun, data tidak boleh ditulis, maka hamba akan kehilangan fungsinya, dan keseluruhan seni bina akan menjadi tidak tersedia, melainkan anda menukar secara manual, sebab utama adalah kerana tiada mekanisme failover automatik. Fungsi sentinel jauh lebih komprehensif daripada seni bina tuan-hamba yang mudah Ia mempunyai fungsi seperti failover automatik, pemantauan kelompok, dan pemberitahuan mesej.
Memulakan kamus induk dan maklumat pelayan, maklumat pelayan Terutamanya simpan ip:port, dan rekod alamat dan ID kejadian
Buat dua sambungan dengan induk, sambungan arahan dan sambungan langganan, dan langgan saluran sentinel:hello
Hantar arahan info kepada tuan setiap 10 saat untuk mendapatkan maklumat semasa tuan dan semua hamba di bawahnya
Apabila ia ditemui bahawa tuan mempunyai hamba baharu, sentinel dan Hamba baharu juga mewujudkan dua sambungan dan menghantar arahan info setiap 10 saat untuk mengemas kini maklumat tuan
sentinel menghantar arahan ping ke semua pelayan setiap 1 saat. Jika pelayan secara berterusan mengembalikan balasan tidak sah dalam masa respons yang dikonfigurasikan akan ditandakan sebagai luar talian
Untuk memilih pengawal terkemuka, pengawal utama memerlukan persetujuan lebih daripada separuh daripada sentinel
Sentinel terkemuka memilih satu hamba daripada tuan luar talian dan menukarnya kepada tuan
Biar semua hamba menyalin data daripada tuan baharu
Tetapkan tuan asal sebagai pelayan hamba tuan baharu Apabila tuan asal membalas sambungan semula, ia menjadi pelayan hamba tuan baharu
<.>Redis menyimpan data dalam bentuk serpihan kluster Seluruh pangkalan data kluster dibahagikan kepada 16384 slot Setiap nod dalam kluster boleh memproses 0-16384 slot apabila semua 16384 slot dalam pangkalan data diproses oleh nod berada dalam status Dalam talian, jika tidak selagi satu slot tidak diproses, status luar talian akan diproses. Gunakan arahan cluster addslots untuk menetapkan slot pada nod yang sepadan untuk diproses.
slot ialah tatasusunan sedikit, panjang tatasusunan ialah 16384/8=2048, dan setiap bit tatasusunan diwakili oleh 1 untuk diproses oleh nod, dan 0 mewakili tidak diproses. ia bermakna nod A memproses slot 0-7.
Apabila klien menghantar arahan kepada nod, jika ia berlaku untuk mendapati bahawa slot adalah kepunyaan nod semasa, nod akan melaksanakan perintah tersebut Jika tidak, arahan MOVED akan dikembalikan kepada klien untuk membimbing klien ke nod yang betul. (Proses MOVED adalah automatik)
Jika anda menambah atau mengalih keluar nod, ia juga sangat mudah untuk mengagihkan semula slot Redis menyediakan alat untuk membantu merealisasikan migrasi slot Keseluruhan proses adalah dalam talian sepenuhnya dan tidak perlu dihentikan perkhidmatan itu.
Jika nod A menghantar mesej ping ke nod B, dan nod B tidak bertindak balas kepada pong dalam masa yang ditentukan, maka nod A akan menandakan nod B sebagai pfail disyaki keadaan luar talian, dan pada masa yang sama Hantar status B ke nod lain dalam bentuk mesej Jika lebih separuh daripada nod menandakan B sebagai status pfail, B akan ditandakan sebagai gagal di luar talian akan diberikan kepada replikasi data daripada Berbilang nod hamba pilih satu untuk menjadi nod induk dan mengambil alih slot nod luar talian Keseluruhan proses adalah sangat serupa dengan sentinel, yang kedua-duanya adalah berdasarkan protokol Raft untuk pemilihan .
redis melaksanakan mekanisme urus niaga melalui perintah MULTI, EXEC, WATCH dan lain-lain Proses pelaksanaan transaksi melaksanakan satu siri berbilang perintah dalam urutan pada satu masa, dan semasa pelaksanaan, transaksi tidak akan. terganggu, atau Permintaan lain daripada klien tidak akan dilaksanakan sehingga semua arahan dilaksanakan. Proses pelaksanaan transaksi adalah seperti berikut:
Pelayan menerima permintaan pelanggan, dan transaksi bermula dengan MULTI
Jika pelanggan berada dalam keadaan urus niaga, maka Transaksi akan dimasukkan ke dalam baris gilir dan dikembalikan kepada klien DIGITALKAN Jika tidak, arahan ini akan dilaksanakan terus
Apabila menerima arahan EXEC pelanggan, Arahan WATCH memantau sama ada kunci dalam keseluruhan transaksi wujud diubah suai, jika ya, balasan kosong dikembalikan kepada pelanggan untuk menunjukkan kegagalan, jika tidak redis akan melintasi keseluruhan baris gilir transaksi, melaksanakan semua arahan yang disimpan dalam baris gilir, dan akhirnya mengembalikan keputusan kepada pelanggan
TONTON Mekanisme itu sendiri ialah mekanisme CAS Kunci yang dipantau akan disimpan dalam senarai terpaut Jika kunci diubah suai, bendera REDIS_DIRTY_CAS akan dihidupkan. dan pelayan akan menolak untuk melaksanakan transaksi.
Atas ialah kandungan terperinci Apakah soalan dan jawapan wawancara Redis?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!