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.

Analisis Psikologi Penemuduga

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:

• Ia agak asas, dan dia tidak sepatutnya mempunyai pemahaman yang mendalam tentang Redis
• Saya rasa masalah itu tetap di permukaan, saya rasa saya tahu cara bekerja secara normal dan tidak memikirkan masalah itu

• Beri anda peluang untuk meluahkan perasaan anda dengan bebas. Jika anda tidak memahaminya, nampaknya saya masih perlu melakukannya sendiri , saya akan bertanya kepada anda beberapa soalan tentang pengedaran dan kegigihan untuk melihat sejauh mana tahap anda jika ia tidak berfungsi, biarkan sahaja bahawa. Terdapat ramai orang di belakang anda, dan mereka akan berhenti kerja nanti.

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:

Ringkasan soalan temuduga Redis

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:

• Model bukan penyekat pemultipleksan I/O digunakan untuk mengendalikan sambungan soket pelanggan, yang boleh mengoptimumkan kelajuan tindak balas dan kecekapan pelayan Redis berbilang saluran teknologi pemultipleksan tunggal cekap Mengendalikan permintaan sambungan berbilang untuk meminimumkan penggunaan masa IO rangkaian.
• Berdasarkan storan memori, mengurangkan IO cakera dan kelajuan membaca pantas

• Redis telah membuat pengoptimuman muktamad bagi struktur data dalaman, menjadikan struktur data Redis sangat cekap. Dan kaedah pengekodan yang berbeza digunakan untuk jumlah data dan kandungan storan yang berbeza, yang melibatkan penukaran pengekodan asas Redis. Contohnya, tiga kekunci senarai, cincang dan zset menggunakan pengekodan senarai mampatan ziplist ialah struktur data padat Apabila nilai kunci tertentu mengandungi lebih sedikit elemen, ia akan disimpan dalam senarai zip terlebih dahulu nombor melebihi nilai tertentu, senarai zip akan ditukar kepada struktur storan standard Sudah tentu, nilai ini boleh disesuaikan dalam redis.conf. Selain itu, pra-peruntukan memori SDS, pencincangan progresif dalam Rehash hasil Hash dan jujukan ZSet berdasarkan storan SkipList semuanya mengoptimumkan struktur data dan menjadikannya lebih pantas.
• Redis menggunakan satu utas untuk melaksanakan operasi arahan, tanpa mengambil kira reka bentuk kunci serentak dan penggunaan pensuisan konteks CPU yang disebabkan oleh berbilang benang, jadi pelaksanaan arahan lebih pantas

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)
• Pemadaman pasif (strategi berkala)

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

• 3 Jika bilangan kunci tamat tempoh yang dipadam lebih daripada 25%, ulangi langkah 1

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

• Diedarkan kunci berdasarkan pelaksanaan Redis

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

Lakukan lebih banyak ujian tekanan dan ujian simulasi dalam talian. senario sebenar untuk menganggarkan masa tamat kunci yang sesuai

• Bersedia untuk kaedah pemulihan data selepas tugas tamat masa kunci yang diedarkan Redis tidak selesai

• Jika sudah dalam persekitaran teragih,
akan meningkatkan Masalah baharu, seperti persekitaran satu tuan dan berbilang hamba sentinel, mungkin pelanggan memohon kunci pada nod induk, tetapi penyegerakan tidak selesai dan nod induk pada masa ini, kunci pada nod induk yang baru dipilih adalah tidak sah.
• Pengendalian situasi ini harus dipertimbangkan dengan cara ini Pertama sekali, penyegerakan tuan-hamba langsung Redis tidak dapat menyelesaikan masalah kehilangan data. Jadi kami mempertimbangkan untuk menukar aplikasi kunci daripada satu Redis kepada berbilang aplikasi kunci Redis yang berdiri sendiri Hanya kebanyakan aplikasi yang berjaya. Idea ini ialah RedLock.

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:

• Masalah pertama ialah clock drift
• Masalah kedua ialah masa yang diambil untuk pelanggan berjaya memohon kunci dengan pelayan Redis berbeza adalah berbeza

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:

• petikan memori RDB (Redis Data Base)
• AOF (Add Only File) log inkremental

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:

• Storan padat, menjimatkan ruang memori
• Kelajuan pemulihan sangat pantas

• Sesuai untuk senario sandaran penuh dan replikasi penuh, sering digunakan untuk pemulihan bencana (senario dengan keperluan yang agak rendah untuk integriti dan konsistensi data)

Kelemahan:

• Ia adalah mudah untuk kehilangan data, dan ia adalah mudah untuk kehilangan data yang berubah dalam pelayan Redis antara dua syot kilat.
• RDB menggunakan sub-proses garpu untuk menyandarkan petikan memori sepenuhnya Ia merupakan operasi yang berat dan kos pelaksanaan yang kerap adalah tinggi.

• Proses anak fork, walaupun memori dikongsi, jika memori diubah semasa sandaran, ia mungkin mengembang maksimum 2 kali ganda saiz.

Peraturan pencetus RDB terbahagi kepada dua kategori iaitu pencetus manual dan pencetus automatik:

Pencetusan automatik:

• Peraturan pencetus konfigurasi

• cetus penutupan

• cetus flushall

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:

• Sandaran data lebih lengkap dan kebarangkalian kehilangan data lebih rendah, sesuai untuk senario dengan keperluan integriti data yang tinggi
• Fail log boleh dibaca, AOF lebih mudah dikendalikan dan boleh dibaiki dengan mengendalikan fail log

Kelemahan:

• Log AOF direkodkan dalam Ia secara beransur-ansur membesar dalam saiz semasa operasi jangka panjang, dan pemulihan sangat memakan masa log AOF perlu dikurangkan secara berkala (terperinci kemudian)
• Memulihkan kelajuan sandaran adalah perlahan

<.>

Tulisan segerak Operasi yang kerap akan membawa tekanan prestasi

Log AOF wujud dalam bentuk fail Apabila atur cara menulis ke fail log AOF, kandungan sebenarnya ditulis ke deskriptor fail yang diperuntukkan oleh kernel Dalam penimbal memori, kernel kemudiannya akan menyiram data dalam penimbal ke cakera secara tidak segerak. Jika pelayan ranap sebelum data dalam penimbal mempunyai masa untuk dibuang kembali ke cakera, data akan hilang.

Oleh itu, Redis memanggil fsync(int fid) yang disediakan oleh glibc sistem pengendalian Linux untuk memaksa kandungan fail yang ditentukan daripada penimbal kernel kembali ke cakera untuk memastikan bahawa data dalam penimbal tidak akan hilang. Walau bagaimanapun, ini adalah operasi IO, yang sangat perlahan berbanding dengan prestasi Redis, jadi ia tidak boleh dilaksanakan dengan kerap.

Terdapat tiga konfigurasi untuk membuang penimbal dalam fail konfigurasi Redis:

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:

bgrewriteaof

auto-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 sahaja

• Ia tidak disyorkan untuk menggunakan AOF sahaja. Kerana pepijat mungkin berlaku
• Jika anda hanya melakukan cache memori tulen, anda tidak perlu melakukannya.

• Pemahaman saya lebih kurang seperti Penemuduga ini! !

Redis 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 dibenarkan

dibenarkan.

• allkeys-lru: Hapuskan semua kunci melalui algoritma lru (Paling Kurang Digunakan - Paling Kurang Digunakan)
• allkeys-random : Alih keluar secara rawak daripada semua kekunci

meruap-lru:

Daripada semua kunci dengan masa tamat tempoh ditetapkan, gunakan algoritma lru (Paling Kurang Digunakan - Paling Kurang Digunakan Baru-baru Ini) untuk penyingkiran, yang memastikan bahawa data yang tidak mempunyai masa tamat tempoh dan perlu diteruskan tidak akan dipilih untuk dihapuskan
• rawak meruap: ditetapkan daripada Antara semua kunci dengan masa tamat tempoh, ia disingkirkan secara rawak

volatile-ttl:

Daripada semua kunci dengan masa tamat tempoh ditetapkan, dengan membandingkan nilai baki masa tamat tempoh TTL kunci, semakin kecil TTL Lebih cepat ia dihapuskan
• volatile-lfu: Gunakan algoritma penghapusan LFU untuk kunci dengan masa tamat tempoh

allkeys-lfu:

Gunakan algoritma penghapusan LFU untuk semua kunci
• Antara strategi ini, terdapat dua algoritma penting ialah LRU, yang menghapuskan kunci yang paling kurang digunakan baru-baru ini. Walau bagaimanapun, Redis menggunakan anggaran algoritma LRU, yang tidak tepat sepenuhnya dalam menghapuskan kunci yang paling kurang kerap digunakan baru-baru ini, tetapi ketepatan keseluruhan boleh dijamin.
• Anggaran algoritma LRU adalah sangat mudah Dalam objek kunci Redis, 24 bit ditambah untuk menyimpan cap masa sistem bagi akses terkini Apabila pelanggan menghantar permintaan berkaitan penulisan kunci kepada pelayan Redis memori ditemui Apabila maxmemory dicapai, pemadaman malas dicetuskan; perkhidmatan Redis memilih 5 kekunci yang memenuhi syarat melalui pensampelan rawak (perhatikan bahawa pensampelan rawak allkeys-lru secara rawak daripada semua kekunci,
volatile- lru

diambil secara rawak daripada semua kekunci dengan set masa tamat), dan dibandingkan dengan cap waktu akses terkini yang direkodkan dalam objek utama, dan kunci tertua antara lima kekunci itu dihapuskan jika ingatan masih kekal tidak cukup, teruskan Ulangi langkah ini.

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:

• LRU -> Digunakan Baru-baru ini, berdasarkan masa lawatan terkini
• LFU -> ; Kerap Digunakan, berbanding mengikut kekerapan akses kekunci

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.

• lfu-log-factor digunakan untuk melaraskan kadar pertumbuhan Kaunter Logistik Semakin besar nilai lfu-log-factor, semakin perlahan kadar pertumbuhan Kaunter Logistik.
• lfu-decay-time digunakan untuk melaraskan kelajuan pereputan Kaunter Logistik Ia adalah nilai dalam minit Nilai lalai ialah 1. Semakin besar nilai lfu-decay-time, semakin perlahan pereputan.

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:

• Jika data cache agak tetap, anda boleh cuba menetapkan data tempat liputan agar tidak tamat tempoh.
• Jika data yang dicache tidak dikemas kini dengan kerap dan keseluruhan proses penyegaran cache mengambil sedikit masa, anda boleh menggunakan kunci mutex yang diedarkan berdasarkan perisian tengah yang diedarkan seperti Redis dan zookeeper, atau kunci mutex setempat untuk memastikan bahawa hanya sebilangan kecil permintaan boleh meminta pangkalan data dan membina semula cache, dan benang yang tinggal boleh mengakses cache baharu selepas kunci dilepaskan.

• Jika data cache dikemas kini dengan kerap atau proses penyegaran cache mengambil masa yang lama, anda boleh menggunakan urutan pemasaan untuk membina semula cache secara aktif atau menangguhkan cache sebelum tamat tempoh cache masa untuk memastikan bahawa semua permintaan sentiasa boleh mengakses cache yang sepadan.

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:

• Jika pangkalan data tidak disoal, tetapkan nilai nol dalam cache Kaedah ini tidak dapat menyelesaikan masalah penggunaan yang berbeza ID negatif.
• Gunakan penapis Bloom untuk memetakan semua data dalam pangkalan data ke penapis Bloom Sebelum membuat permintaan, gunakan penapis Bloom untuk menentukan sama ada ia wujud, hanya kembalikannya .

---

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:

• Reka bentuk seni bina cache: Reka bentuk Redis, master-slave sentinel yang sangat tersedia, kelompok Redis
• Pelayan projek: gunakan cache tempatan dan pemprosesan degradasi perkhidmatan untuk meminimumkan permintaan kepada MySQL

Di akhir jawapan, wajah penemuduga menunjukkan senyuman yang telah lama hilang Kami hanya perlu mengambil helah ini, dan temuduga ini akan berjaya.

• Sudah tentu, perkara pengetahuan ini tidak dapat dijelaskan dengan jelas dalam beberapa ayat, jadi saya cadangkan anda membaca artikel ini dan anda boleh berpegang padanya dengan mudah

《

Diedarkan Semula—— Replikasi tuan-hamba, Sentinel dan pengelompokan difahami dengan teliti 》

Artikel ini diterbitkan semula daripada: https://juejin.cn/post/7019088999792934926

Pengarang: Li Zi捌

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!