Redis ialah pangkalan data dalam memori yang berkuasa, tetapi semasa penggunaan, kita mungkin menghadapi masalah Big Key Masalah ini adalah kunci tertentu dalam Redis Nilainya terlalu besar , jadi Masalah Kunci Besar pada asasnya ialah masalah Nilai Besar, mengakibatkan kemerosotan atau ranap prestasi Redis.
Dalam Redis, setiap kunci mempunyai nilai yang sepadan Jika nilai kunci terlalu besar, ia akan menyebabkan prestasi Redis menurun atau ranap metafizik, kerana Redis perlu memuatkan semua kunci besar ke dalam memori, yang akan menduduki banyak ruang memori dan mengurangkan kelajuan tindak balas Redis Masalah ini dipanggil masalah Kunci Besar . Jangan memandang rendah masalah ini, ia boleh menukar Redis anda menjadi "penyu" dengan serta-merta Disebabkan sifat benang tunggal Redis, mengendalikan Big Key biasanya memakan masa, yang bermaksud kemungkinan menyekat Redis adalah lebih besar, yang mana ia adalah lebih besar. akan menyebabkan Pelanggan disekat atau menyebabkan failover, yang boleh membawa kepada "pertanyaan perlahan".
Secara umumnya, dua situasi berikut dipanggil kekunci besar:
Nilai yang sepadan dengan kekunci jenis Rentetan melebihi 10 MB.
Senaraikan, set, cincang, zset dan jenis koleksi lain, bilangan elemen koleksi melebihi 5000.
Kriteria di atas untuk menilai Big Key bukanlah satu-satunya, hanya standard yang kasar. Ia perlu dinilai mengikut senario aplikasi khusus sama ada ia merupakan Kunci Besar dalam pembangunan perniagaan sebenar. Jika pengendalian kunci tertentu menyebabkan masa respons permintaan menjadi perlahan, kunci itu boleh ditentukan sebagai Kunci Besar.
Dalam Redis, kekunci besar biasanya disebabkan oleh sebab berikut :
Saiz objek selepas bersiri terlalu besar Besar
Bekas yang menyimpan sejumlah besar data, seperti set, senarai, dll.
Struktur data besar, seperti bitmap, hyperloglog , dsb.
Jika kekunci besar ini tidak diproses dalam masa, ia akan memakan sumber memori pelayan Redis secara beransur-ansur dan akhirnya menyebabkan Redis ranap.
Apabila prestasi Redis menurun secara mendadak, kemungkinan besar ia disebabkan oleh kewujudan kunci yang besar. Apabila menyelesaikan masalah utama yang besar, anda boleh mempertimbangkan kaedah berikut:
Arahan BIGKEYS yang disertakan dengan Redis boleh menanyakan maklumat semua kunci dalam Redis semasa dan membuat pertanyaan keseluruhan pangkalan data Lakukan analisis statistik pada saiz pasangan nilai kunci, contohnya, kira bilangan pasangan nilai kunci dan saiz purata bagi setiap jenis data. Di samping itu, selepas arahan ini dilaksanakan, maklumat kunci besar terbesar dalam setiap jenis data akan menjadi output Untuk jenis String, panjang bait kunci besar terbesar akan dikeluarkan untuk jenis koleksi bigkey terbesar akan dikeluarkan Perintah 🎜>
akan mengimbas keseluruhan pangkalan data Arahan ini sendiri akan menyekat Redis, mencari semua kunci besar dan mengembalikannya kepada klien dalam bentuk senarai. Format arahan BIGKEYS
$ redis-cli --bigkeys
# Scanning the entire keyspace to find biggest keys as well as # average sizes per key type. You can use -i 0.1 to sleep 0.1 sec # per 100 SCAN commands (not usually needed). [00.00%] Biggest string found so far 'a' with 3 bytes [05.14%] Biggest list found so far 'b' with 100004 items [35.77%] Biggest string found so far 'c' with 6 bytes [73.91%] Biggest hash found so far 'd' with 3 fields -------- summary ------- Sampled 506 keys in the keyspace! Total key length in bytes is 3452 (avg len 6.82) Biggest string found 'c' has 6 bytes Biggest list found 'b' has 100004 items Biggest hash found 'd' has 3 fields 504 strings with 1403 bytes (99.60% of keys, avg size 2.78) 1 lists with 100004 items (00.20% of keys, avg size 100004.00) 0 sets with 0 members (00.00% of keys, avg size 0.00) 1 hashs with 3 fields (00.20% of keys, avg size 3.00) 0 zsets with 0 members (00.00% of keys, avg size 0.00)
perlu mengimbas keseluruhan pangkalan data, ia boleh menjejaskan contoh Redis menyebabkan beban tertentu. BIGKEYSSebelum melaksanakan perintah ini, sila pastikan tika Redis anda mempunyai sumber yang mencukupi untuk mengendalikannya. Adalah disyorkan untuk melaksanakannya pada nod hamba .
untuk melihat maklumat terperinci kunci, termasuk saiz nilai kunci, dsb. Pada masa ini, anda boleh "mengintip" di dalam Redis untuk melihat kekunci yang terlalu besar. debug object key
redis 127.0.0.1:6379> DEBUG OBJECT key Value at:0xb6838d20 refcount:1 encoding:raw serializedlength:9 lru:283790 lru_seconds_idle:150 redis 127.0.0.1:6379> DEBUG OBJECT key (error) ERR no such key
127.0.0.1:6379> set k1 value1 OK 127.0.0.1:6379> memory usage k1 //这里k1 value占用57字节内存 (integer) 57 127.0.0.1:6379> memory usage aaa // aaa键不存在，返回nil. (nil)
127.0.0.1:6379> hlen hkey // hkey有100w个字段，每个字段的value长度介于1~1024个字节 (integer) 1000000 127.0.0.1:6379> MEMORY usage hkey //默认SAMPLES为5，分析hkey键内存占用521588753字节 (integer) 521588753 127.0.0.1:6379> MEMORY usage hkey SAMPLES 1000 //指定SAMPLES为1000，分析hkey键内存占用617977753字节 (integer) 617977753 127.0.0.1:6379> MEMORY usage hkey SAMPLES 10000 //指定SAMPLES为10000，分析hkey键内存占用624950853字节 (integer) 624950853
pip install rdbtools
rdb -c memory dump.rdb > memory.csv
database key在Redis的db
type key类型
key key值
size_in_bytes key的内存大小
encoding value的存储编码形式
num_elements key中的value的个数
len_largest_element key中的value的长度
可以在MySQL中新建表然后导入进行分析，然后可以直接通过SQL语句进行查询分析。
CREATE TABLE `memory` (
`database` int(128) DEFAULT NULL,
`type` varchar(128) DEFAULT NULL,
`KEY` varchar(128),
`size_in_bytes` bigint(20) DEFAULT NULL,
`encoding` varchar(128) DEFAULT NULL,
`num_elements` bigint(20) DEFAULT NULL,
`len_largest_element` varchar(128) DEFAULT NULL,
PRIMARY KEY (`KEY`)
);例子：查询内存占用最高的3个 key
mysql> SELECT * FROM memory ORDER BY size_in_bytes DESC LIMIT 3; +----------+------+-----+---------------+-----------+--------------+---------------------+ | database | type | key | size_in_bytes | encoding | num_elements | len_largest_element | +----------+------+-----+---------------+-----------+--------------+---------------------+ | 0 | set | k1 | 624550 | hashtable | 50000 | 10 | | 0 | set | k2 | 420191 | hashtable | 46000 | 10 | | 0 | set | k3 | 325465 | hashtable | 38000 | 10 | +----------+------+-----+---------------+-----------+--------------+---------------------+ 3 rows in set (0.12 sec)
当发现存在大key问题时，我们需要及时采取措施来解决这个问题。下面列出几种可行的解决思路：
将Big Key拆分成多个小的key。这个方法比较简单，但是需要修改应用程序的代码。虽然有些费力，但将一个大蛋糕切成小蛋糕可以解决问题。
或者尝试将Big Key转换成Redis的数据结构。例如，可以使用哈希表、列表或集合等数据结构将“Big Key”进行转换。
若大key的大小源于对象序列化后的体积巨大，我们可思考运用压缩算法来缩小对象的尺寸。Redis自身支持多种压缩算法，例如LZF、Snappy等。
如果你所用的Redis版本是4.0或更高版本，你可以使用unlink命令进行异步删除。4.0以下的版本 可以考虑使用 scan ,分批次删除。
无论采用哪种方法，都需要注意以下几点：
避免使用过大的value。如果需要存储大量的数据，可以将其拆分成多个小的value。就像是吃饭一样，一口一口的吃，不要贪多嚼不烂。
避免使用不必要的数据结构。如果只需要保存一个字符串，应该避免使用像Hash或List这样的数据结构。
定期清理过期的key。当Redis中存在大量过期的key时，会导致Redis性能下降。就像是家里的垃圾，需要定期清理。
对象压缩
Atas ialah kandungan terperinci Apakah penyelesaian masalah dan penyelesaian untuk BigKey dalam 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)
