Rumah > Artikel > pangkalan data > Perkongsian soalan temuduga frekuensi tinggi Redis pada tahun 2023 (dengan analisis jawapan)
Artikel ini meringkaskan dan berkongsi dengan anda beberapa soalan temuduga berfrekuensi tinggi Redis Ia mempunyai nilai rujukan tertentu. Saya harap ia dapat membantu semua orang.
Dari perspektif penemuduga, tujuan soalan ini adalah untuk menguji pengetahuan anda tentang caching, dan Digabungkan dengan keupayaan caching untuk memproses perniagaan dan menambah baik seni bina. Soalan ini jelas membolehkan anda meluahkan perasaan anda secara bebas dan memberi anda peluang untuk memimpin penemuduga ke titik pengetahuan yang paling anda kenali, jadi anda harus merebut peluang ini sebanyak mungkin dan memberi kesan yang baik kepada penemuduga. Jika anda boleh bercakap tentang soalan ini dengan baik, anda boleh berkomunikasi secara mendalam selama beberapa jam Jika ia hanya satu sesi, anda boleh menyelesaikannya dengan mudah. [Cadangan berkaitan: Tutorial Video Redis]
Tetapi jangan bersembang dengan segera Kemudian pada dasarnya hanya kembali dan tunggu pemberitahuan. ...
Sebagai contoh, jawapan berikut:
Ramai orang akan mengatakan bahawa jawapan ini adalah betul! Betul, betul, tetapi sentiasa ada perasaan bahawa peluang yang diberikan kepada anda tidak berguna.
Pada masa ini, penemuduga memikirkan sesuatu seperti ini:
Jika anda tidak mahu menentang Lapan Belas Naga Menundukkan Palma penemuduga, anda harus mengambil inisiatif untuk membangkitkan minat penemuduga, dan memimpin dalam memperbaiki corak anda sendiri (keluasan dan kedalaman mendatar) , dan Beritahu sebanyak mungkin tentang perkara yang anda ketahui.
Contohnya, kaedah jawapan berikut:
Pemahaman saya tentang perkara ini lebih kurang seperti penemuduga ini! !
Prestasi tinggi: Kriteria besar untuk prestasi tinggi ialah masa tindak balas yang pantas. Redis adalah berdasarkan storan memori dan mempunyai kelajuan akses CPU yang pantas Selain itu, pengoptimuman melampau Redis bagi struktur data, model benang dalaman dan reka bentuk model I/O rangkaian menentukan bahawa Redis ialah pangkalan data storan berprestasi tinggi. Satu-satunya kelemahan ialah memori agak mahal dan sumber biasanya terhad Oleh itu, seni bina cache untuk data yang sangat besar harus direka dengan munasabah Kami biasanya tidak menyimpan data yang terlalu besar dalam Redis, kerana ini akan menyebabkan prestasi Redis berkurangan.
Konkurensi tinggi: Penunjuk biasa konkurensi tinggi termasuk masa tindak balas (Masa Tindak Balas), daya pemprosesan (Throughput), kadar pertanyaan sesaat QPS (Query Per Second) dan bilangan pengguna serentak Walaupun Redis ialah satu proses Tunggal -model berulir, tetapi Redis sememangnya alat yang berkuasa dalam senario perniagaan berkonkurensi tinggi Pada masa ini, QPS Redis boleh mencapai 100,000 atau bahkan 1 juta tahap Ini benar-benar tinggi.
Ketersediaan tinggi: Ketersediaan tinggi Redis ditunjukkan terutamanya dalam replikasi tuan-hamba, sentinel (mod sentinel) dan Kluster (mod kelompok)
Pemahaman saya tentang perkara ini lebih kurang seperti penemuduga ini! !
Urut tunggal Redis merujuk kepada penggunaan satu utas untuk melaksanakan operasi perintah Selepas keluaran Redis6:
Pemahaman saya tentang perkara ini lebih kurang seperti penemuduga ini! !
Redis mempunyai 5 jenis data asas: String, List, Hash, Set dan ZSet sebagai tambahan, terdapat tiga jenis data khas: Bitmaps, Geospatial dan HyperLogLog
数据类型 | 简单描述 | 使用场景 |
---|---|---|
String | string(字符串)是Redis最简单也是使用最广泛的数据结构,它的内部是一个字符数组。String(字符串)是动态字符串,允许修改;它在结构上的实现类似于Java中的ArrayList(默认构造一个大小为10的初始数组),这是冗余分配内存的思想,也称为预分配;这种思想可以减少扩容带来的性能消耗。当string(字符串)的大小达到扩容阈值时,将会对string(字符串)进行扩容,string(字符串)的扩容主要有三种情况:1.长度小于1MB,扩容后为原先的两倍; length = length * 2 2.长度大于1MB,扩容后增加1MB; length = length 1MB 3. 字符串的长度最大值为 512MB | 缓存、计数器、分布式锁等。 |
List | Redis的列表相当于Java语言中的LinkedList,它是一个双向链表数据结构(但是这个结构设计比较巧妙,后面会介绍),支持前后顺序遍历。链表结构插入和删除操作快,时间复杂度O(1),查询慢,时间复杂度O(n)。Redis的list(列表)不是一个简单。LinkedList,而是quicklist ——“快速列表”,quicklist是多个ziplist(压缩列表)组成的双向列表; | 链表、异步队列、微博关注人时间轴列表…… |
Hash | Redis的hash(字典)相当于Java语言中的HashMap,它是根据散列值分布的无序字典,内部的元素是通过键值对的方式存储。hash(字典)的实现与Java中的HashMap(JDK1.7)的结构也是一致的,它的数据结构也是数组 链表组成的二维结构,节点元素散列在数组上,如果发生hash碰撞则使用链表串联在数组节点上。Redis中的hash(字典)存储的value只能是字符串值,此外扩容与Java中的HashMap也不同。Java中的HashMap在扩容的时候是一次性完成的,而Redis考虑到其核心存取是单线程的性能问题,为了追求高性能,因而采取了渐进式rehash策略。渐进式rehash指的是并非一次性完成,它是多次完成的,因此需要保留旧的hash结构,所以Redis中的hash(字典)会存在新旧两个hash结构,在rehash结束后也就是旧hash的值全部搬迁到新hash之后,新的hash在功能上才会完全替代以前的hash。 | 用户信息、Hash 表…… |
Set | Redis的set(集合)相当于Java语言里的HashSet,它内部的键值对是无序的、唯一的。它的内部实现了一个所有value为null的特殊字典。集合中的最后一个元素被移除之后,数据结构被自动删除,内存被回收。 | 去重功能、赞、踩、共同好友…… |
ZSet | zset(有序集合)是Redis中最常问的数据结构。它类似于Java语言中的SortedSet和HashMap的结合体,它一方面通过set来保证内部value值的唯一性,另一方面通过value的score(权重)来进行排序。这个排序的功能是通过Skip List(跳跃列表)来实现的。zset(有序集合)的最后一个元素value被移除后,数据结构被自动删除,内存被回收。 | 粉丝列表、学生成绩排序、访问量排行榜、点击量排行榜…… |
Bitmaps | Bitmaps 称为位图,严格来说它不是一种数据类型。Bitmaps底层就是字符串(key-value)byte数组。我们可以使用普通的get/set直接获取和设值位图的内容,也可以通过Redis提供的位图操作getbit/setbit等将byte数组看成“位数组”来处理。Bitmaps 的“位数组”每个单元格只能存储0和1,数组的下标在Bitmaps中称为偏移量。Bitmaps设置时key不存在会自动生成一个新的字符串,如果设置的偏移量超出了现有内容的范围,就会自动将位数组进行零扩充 | 员工打卡…… |
Geospatial | Geospatial是Redis在3.2版本以后增加的地理位置GEO模块 | 微信附近的人,在线点餐“附近的餐馆”…… |
HyperLogLog | HyperLogLog是用来做基数统计的算法,它提供不精确的去重计数方案(这个不精确并不是非常不精确),标准误差是0.81%,对于UV这种统计来说这样的误差范围是被允许的。HyperLogLog的优点在于,输入元素的数量或者体积非常大时,基数计算的存储空间是固定的。在Redis中,每个HyperLogLog键只需要花费12KB内存,就可以计算接近2^64个不同的基数。但是HyperLogLog只能统计基数的大小(也就是数据集的大小,集合的个数),他不能存储元素的本身,不能向set集合那样存储元素本身,也就是说无法返回元素。 | 基数统计比如UV等 |
Pemahaman saya tentang perkara ini lebih kurang seperti penemuduga ini! !
Struktur data Redis boleh menetapkan masa tamat tempoh (TTL) kunci melalui EXPIRE saat kunci. Kami juga terbiasa berfikir bahawa kunci Redis akan dipadamkan secara automatik apabila ia tamat tempoh. Jelas sekali, idea ini tidak betul. Reka bentuk Redis mengambil kira faktor komprehensif seperti prestasi/ingatan dan mereka bentuk satu set strategi tamat tempoh.
Pemadaman aktif (pemadaman malas) merujuk pada masa kekunci diakses , semak dahulu sama ada kunci telah tamat tempoh, dan jika ia telah tamat tempoh, padamkannya secara aktif.
Pemadaman pasif (strategi berkala) merujuk kepada pelayan Redis menguji masa tamat tempoh kunci secara rawak Jika ia tamat tempoh, ia akan dipadamkan secara pasif. Kewujudan pemadaman pasif adalah penting kerana terdapat beberapa kunci yang telah tamat tempoh dan tidak akan pernah diakses Jika ia bergantung pada pemadaman aktif, ia akan menduduki memori secara kekal.
Untuk memastikan perkhidmatan berprestasi tinggi, Redis memadamkan kunci tamat tempoh secara pasif dan menggunakan strategi tamak/algoritma kebarangkalian, ia mengimbas setiap 10 saat:
1 Pilih 20 kunci secara rawak daripada kamus tamat tempoh (koleksi kunci dengan set masa tamat) dan semak sama ada ia telah tamat tempoh
2 kunci
Selain itu, apabila mereka bentuk seni bina cache Redis, pembangun mesti membayar. perhatian untuk mengelakkan sebanyak mungkin ( Dilarang) Menetapkan sejumlah besar kunci kepada masa tamat tempoh yang sama, kerana digabungkan dengan pemadaman pasif, apabila Redis secara pasif memadamkan kunci tamat tempoh, ia akan menyebabkan perkhidmatan tidak tersedia buat sementara waktu; bilangan kunci yang tamat tempoh pada masa yang sama, ini akan membawa kepada tiga langkah pemadaman pasif kunci berkali-kali akan menyebabkan perkhidmatan Redis membeku, yang tidak boleh diterima dalam projek trafik yang besar.
Oleh itu, untuk mengelakkan situasi ini, anda mesti menetapkan beberapa kunci yang masa tamatnya dibenarkan tidak perlu sangat tepat kepada masa tamat tempoh yang lebih rawak, supaya masa lag dapat dikurangkan.
Ini adalah pemahaman saya tentang penemuduga! !
Dalam senario yang diedarkan, penyelesaian kunci teragih biasa kami termasuk (jika anda tahu cara melakukannya, anda boleh membawa dua yang lain keluar ke sini, tetapi jika anda tidak melakukannya, jangan kacau diri anda sendiri! ):
Kunci teragih dilaksanakan berdasarkan mekanisme kunci pangkalan data
Kunci teragih dilaksanakan berdasarkan Zookeeper
Penyelesaian untuk Redis melaksanakan kunci teragih adalah seperti berikut.
Jika Redis berada dalam persekitaran yang berdiri sendiri, kita boleh melaksanakan kunci teragih melalui arahan atom yang disediakan oleh Redis
tetapkan nilai kunci [EX saat] [PX milisaat ] [NX |. Membuka kunci dibenarkan, tetapi Redis tidak menyediakan fungsi sedemikian. Kami hanya boleh mengendalikannya melalui skrip Lua, kerana skrip Lua boleh memastikan pelaksanaan atom berbilang arahan. Akhir sekali, kami perlu mempertimbangkan isu tamat masa kunci Jika pelanggan tidak pernah melepaskan kunci, ia pasti tidak akan berfungsi dilepaskan secara automatik selepas tamat masa. Situasi seperti ini adalah sukar. selang kunci sebanyak mungkin, sama seperti kunci JVM tunggal Sama seperti pengoptimuman disegerakkan dalam , kami boleh mempertimbangkan untuk mengoptimumkan julat kunci
RedLock menggunakan berbilang kejadian Redis Tidak ada hubungan induk-hamba antara setiap kejadian dan mereka bebas antara satu sama lain Apabila mengunci, pelanggan menghantar arahan penguncian kepada semua nod set berjaya, Kunci berjaya. Apabila melepaskan kunci, anda perlu menghantar arahan del ke semua nod untuk melepaskan kunci. Walaupun kunci merah menyelesaikan masalah penyegerakan tuan-hamba, ia membawa masalah kompleks baharu:
Oleh itu Dalam RedLock, adalah perlu untuk mengira tempoh sah minimum kunci yang diminta. Andaikan pelanggan memohon kunci dengan jayanya, masa apabila kunci pertama berjaya ditetapkan ialah TF, masa apabila kunci terakhir berjaya ditetapkan ialah TL, tamat masa kunci ialah TTL, dan perbezaan jam antara proses berbeza ialah CLOCK_DIFF, maka kesahan minimum kunci Tempohnya ialah:
MASA = TTL - (TF- TL) - CLOCK_DIFF
Menggunakan Redis untuk melaksanakan kunci teragih, ia tidak boleh dipisahkan daripada masa henti pelayan dan isu ketaksediaan lain , perkara yang sama berlaku untuk RedLock di sini Walaupun berbilang pelayan memohon kunci, kami juga mesti mempertimbangkan pemprosesan selepas pelayan terputus.
Walau bagaimanapun, kegigihan AOF hanya boleh dimulakan semula dan dipulihkan untuk arahan SHUTDOWN biasa Walau bagaimanapun, jika berlaku gangguan bekalan elektrik, data kunci dari kegigihan terakhir hingga gangguan kuasa mungkin hilang apabila pelayan dimulakan semula , ralat semantik kunci teragih mungkin berlaku. Oleh itu, untuk mengelakkan situasi ini, cadangan rasmi ialah selepas perkhidmatan Redis dimulakan semula, perkhidmatan Redis tidak akan tersedia dalam TTL pelanggan maksimum (tiada perkhidmatan aplikasi kunci disediakan, ini memang boleh menyelesaikan masalah, tetapi ia). jelas bahawa ini pasti akan menjejaskan prestasi pelayan Redis , dan apabila ini berlaku kepada kebanyakan nod, sistem akan menjadi tidak tersedia secara global.
Ini adalah pemahaman saya tentang penemuduga! !
Redis adalah sangat pantas sebabnya ialah data Redis disimpan dalam memori Memandangkan ia berada dalam ingatan, apabila pelayan mati atau dimatikan, data itu akan hilang. Semuanya hilang, jadi Redis menyediakan dua mekanisme untuk memastikan semua data Redis tidak akan hilang akibat kegagalan.
Redis mempunyai dua mekanisme kegigihan:
rdb (pangkalan data redis) merujuk kepada penulisan data yang ditetapkan dalam memori ke cakera dalam selang waktu yang ditentukan. bentuk kegigihan), setiap kali syot kilat dijana daripada Redis untuk menyandarkan data sepenuhnya.
Kelebihan:
Kelemahan:
Peraturan pencetus RDB terbahagi kepada dua kategori iaitu pencetus manual dan pencetus automatik:
Pencetusan automatik:
Peraturan pencetus konfigurasi
cetus penutupan
Pencetus manual:
simpan
bgsave
AOF (Add Only File) adalah untuk menyimpan semua arahan yang mengubah suai memori (operasi tulis ) adalah direkodkan dalam fail log bebas, dan data dipulihkan dengan melaksanakan arahan Redis dalam fail AOF semasa memulakan semula. AOF boleh menyelesaikan masalah kegigihan data masa nyata dan merupakan penyelesaian kegigihan arus perdana dalam mekanisme kegigihan Redis semasa (kita akan bercakap tentang kegigihan hibrid selepas 4.0 nanti).
Kelebihan:
Kelemahan:
appendfsync sentiasa
Setiap operasi tulis Redis ditulis pada log AOF Secara teorinya, sistem pengendalian Linux tidak dapat mengendalikan konfigurasi ini, kerana konkurensi Redis jauh melebihi frekuensi muat semula maksimum yang disediakan oleh sistem pengendalian Linux, walaupun terdapat sedikit. Operasi tulis Redis Dalam kes ini, konfigurasi ini juga sangat intensif prestasi kerana ia melibatkan operasi IO, jadi pada asasnya konfigurasi ini tidak akan digunakan ke dalam fail AOF fail serasi dengan kompromi antara prestasi dan integriti data Dengan konfigurasi ini, secara teorinya, data hilang dalam kira-kira satu saat
appendfsync no
Proses Redis tidak akan. secara aktif menyegarkan data dalam penimbal ke fail AOF, tetapi terus menyerahkannya kepada sistem pengendalian untuk pertimbangan Operasi ini tidak disyorkan.
Apabila saya menyebut kekurangan AOF tadi, saya mengatakan bahawa AOF ialah satu bentuk log append untuk menyimpan arahan tulis Redis Ini akan membawa kepada sejumlah besar penyimpanan arahan yang berlebihan, menjadikan fail log AOF sangat besar . Dalam kes ini, ia bukan sahaja menduduki memori, ia juga akan menyebabkan pemulihan menjadi sangat perlahan, jadi Redis menyediakan mekanisme penulisan semula untuk menyelesaikan masalah ini. Selepas mekanisme kegigihan AOF Redis melakukan penulisan semula, ia hanya menyimpan set arahan minimum untuk memulihkan data Jika kita ingin mencetuskannya secara manual, kita boleh menggunakan arahan berikut
Redis 4.0 menggunakan RDB untuk menulis semula Caranya. syot kilat dan arahan AOF disambungkan, kepala fail AOF ialah bentuk binari data syot kilat RDB, dan ekor ialah arahan untuk operasi tulis yang berlaku selepas syot kilat dijana. Memandangkan menulis semula fail AOF akan memberi impak tertentu pada prestasi Redis, penulisan semula automatik tidak boleh dilakukan secara sembarangan masa yang sama:bgrewriteaofauto-aof-rewrite-percentage 100: merujuk kepada apabila memori fail mencapai dua kali ganda memori asal auto-aof-write -saiz min 64mb: merujuk kepada saiz memori minimum untuk menulis semula fail
Selain itu, kebanyakan senario penggunaan selepas Redis 4.0 tidak akan Menggunakan RDB atau AOF sahaja sebagai mekanisme kegigihan, tetapi mengambil kira kelebihan kedua-duanya dan menggunakannya dalam kombinasi.
Akhir sekali, untuk meringkaskan kedua-duanya, yang mana lebih baik?
Adalah disyorkan untuk mendayakan kedua-duanya Jika data tidak sensitif, anda boleh memilih untuk menggunakan RDB sahajaRedis ialah pangkalan data nilai kunci berdasarkan storan memori. jadi kami akan menyediakan memori Maksimum Redis Apabila memori Redis mencapai ambang yang ditetapkan, kitar semula memori akan dicetuskan oleh banyak strategi penghapusan memori:
noeviction:
Apabila memori. had dicapai dan klien mencuba Ralat dikembalikan apabila melaksanakan perintah yang mungkin menyebabkan lebih banyak memori digunakan, operasi baca masih dibenarkan, tetapi menulis data baharu tidak dibenarkandibenarkan.
Dalam Redis 3.0 apabila maxmemory_samples ditetapkan kepada 10, algoritma LRU anggaran Redis adalah sangat hampir dengan algoritma LRU sebenar, tetapi jelas sekali menetapkan maxmemory_samples kepada 10 menggunakan lebih banyak masa pengkomputeran CPU daripada menetapkan maxmemory_samples kepada 5, kerana setiap sampel adalah Sebagai sampel data bertambah, masa pengiraan juga akan meningkat.
Algoritma LRU Redis3.0 adalah lebih tepat daripada algoritma LRU Redis2.8, kerana Redis3.0 menambah kumpulan penyingkiran dengan saiz yang sama dengan maxmemory_samples setiap kali kunci dihapuskan, Ia pertama kali dibandingkan dengan kunci yang menunggu untuk dihapuskan dalam kumpulan penyingkiran, dan akhirnya kunci tertua dihapuskan Malah, kunci yang dipilih untuk penyingkiran disatukan dan dibandingkan, dan yang tertua dihapuskan.
LRU mempunyai kelemahan yang jelas Ia tidak dapat mewakili kepopularan Kunci dengan betul Jika kunci tidak pernah diakses, ia hanya diakses oleh pengguna seketika sebelum penghapusan memori berlaku. ini Akan dianggap sebagai kunci panas. LFU (Kurang Kerap Digunakan) ialah algoritma penyingkiran yang diperkenalkan dalam Redis 4.0 Ia menghapuskan kunci dengan membandingkan kekerapan capaian kekunci Titik utama ialah Kerap Digunakan.
Perbezaan antara LRU dan LFU:
Dalam mod LFU, medan lru 24bit pengepala objek Redis dibahagikan kepada dua segmen untuk penyimpanan, storan 16bit tinggi ldt (Masa Penurunan Terakhir), dan logc Kedai 8bit rendah (Kaunter Logistik). 16 bit atas digunakan untuk merekod kali terakhir pembilang menurun Memandangkan hanya terdapat 8 bit, menyimpan modulo cap waktu Unix 2^16 Nilai maksimum yang boleh diwakili oleh 16 bit ialah 65535 (65535 /24/60≈ 45.5), ia akan berpatah balik dalam masa kira-kira 45.5 hari (berpatah balik bermakna nilai modulo bermula dari 0 semula).
8 bit yang lebih rendah digunakan untuk merekodkan kekerapan capaian Nilai maksimum yang boleh diwakili oleh 8 bit ialah 255. Logc pasti tidak akan dapat merekodkan jumlah sebenar capaian Rediskey dilihat dari nama bahawa ia menyimpan logaritma bilangan akses Nilai awal logc untuk setiap kunci yang baru ditambah ialah 5 (LFU_INITI_VAL), yang memastikan bahawa nilai yang baru ditambah tidak akan dipilih dan dihapuskan terlebih dahulu setiap kali kunci diakses sebagai tambahan, logc akan mereput dari semasa ke semasa.
Kaunter Logistik bukan sahaja akan berkembang, tetapi juga reput Peraturan pertumbuhan dan pereputan juga boleh dikonfigurasikan melalui redis.conf.
Ini adalah pemahaman saya tentang penemuduga! !
Pecahan cache:
Ini bermakna kunci tempat liputan yang sangat kerap diakses berada dalam situasi akses serentak tinggi terpusat apabila kunci ini tidak sah Dalam sekelip mata, sejumlah besar permintaan menembusi cache, meminta pangkalan data secara langsung, dan terus melalui Redis.
Penyelesaian:
Penembusan cache:
bermaksud data yang tidak wujud dalam cache atau pangkalan data diminta 't mengambil pertahanan yang baik, ia boleh membawa kepada pangkalan data dibunuh oleh permintaan. Contohnya, jika penggodam menggunakan ID negatif untuk menanyakan salah satu jadual anda, ID kami biasanya tidak ditetapkan kepada nombor negatif.
Penyelesaian:
Cache avalanche:
Cache avalanche berlaku apabila sejumlah besar cache gagal pada masa yang sama, menyebabkan pangkalan data ranap serta-merta (tinggi senario konkurensi), dan Dalam kes ini, jika cache tidak dipulihkan, pangkalan data akan menjadi sia-sia dan akan terus ranap.
Penyelesaian:
Diedarkan Semula—— Replikasi tuan-hamba, Sentinel dan pengelompokan difahami dengan teliti 》
Artikel ini diterbitkan semula daripada: https://juejin.cn/post/7019088999792934926 Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila lawati:Pengenalan kepada Pengaturcaraan! !
Atas ialah kandungan terperinci Perkongsian soalan temuduga frekuensi tinggi Redis pada tahun 2023 (dengan analisis jawapan). Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!