Apakah penyelesaian masalah dan penyelesaian untuk BigKey dalam Redis?-Redis-php.cn

Ringkasan

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.

Pengenalan kepada isu Kunci Besar

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.

Penyelesaian Masalah Utama Besar

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:

Gunakan arahan BIGKEYS

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

adalah seperti berikut:

$ redis-cli --bigkeys

Salin selepas log masuk

Contoh pulangan adalah seperti berikut:

# 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 &#39;a&#39; with 3 bytes
[05.14%] Biggest list   found so far &#39;b&#39; with 100004 items
[35.77%] Biggest string found so far &#39;c&#39; with 6 bytes
[73.91%] Biggest hash   found so far &#39;d&#39; with 3 fields

-------- summary -------

Sampled 506 keys in the keyspace!
Total key length in bytes is 3452 (avg len 6.82)

Biggest string found &#39;c&#39; has 6 bytes
Biggest   list found &#39;b&#39; has 100004 items
Biggest   hash found &#39;d&#39; 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)

Salin selepas log masuk

Perlu diingatkan bahawa sejak perintah

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 .

Objek Nyahpepijat

Jika kami menemui Kunci Besar, kami perlu menganalisisnya dengan lebih lanjut. Kita boleh menggunakan arahan

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

Apabila kekunci wujud, arahan Objek Nyahpepijat memberikan maklumat tentang kunci dan merupakan arahan nyahpepijat. Apabila kunci tidak wujud, ralat dikembalikan.

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

Salin selepas log masuk

panjang bersiri mewakili bilangan bait selepas penyirian nilai yang sepadan dengan kunci

penggunaan memori

Sebelum Redis 4.0, memori kunci hanya boleh dianggarkan melalui DEBUG Perintah OBJECT Use (field serializedlength), tetapi perintah DEBUG OBJECT tidak betul.

Untuk versi 4.0 dan ke atas, kita boleh menggunakan arahan usag memori.

Arahan penggunaan memori adalah sangat mudah untuk digunakan, hanya tekan nama kunci penggunaan memori jika kekunci semasa wujud, anggaran penggunaan memori sebenar bagi nilai kunci dikembalikan, jika kunci itu tidak wujud; dikembalikan.

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)

Salin selepas log masuk

Untuk jenis selain daripada jenis String, arahan penggunaan memori menggunakan pensampelan Secara lalai, 5 elemen dijadikan sampel, jadi pengiraan adalah nilai anggaran.

Contoh perihalan: Hasilkan kunci cincang sebanyak 1 juta medan: hkey Panjang nilai setiap medan ialah nilai rawak dari 1 hingga 1024 bait.

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

Salin selepas log masuk

Untuk mendapatkan nilai memori kunci yang lebih tepat, nyatakan nombor pensampelan yang lebih besar. Walau bagaimanapun, lebih banyak bilangan sampel, lebih banyak masa CPU diduduki.

redis-rdb-tools

redis-rdb-tools ialah alat python untuk menghurai fail rdb Apabila menganalisis memori, kami terutamanya menggunakannya untuk menjana syot kilat memori. Anda boleh menukar fail snapshot rdb ke dalam fail CSV atau JSON dan mengimportnya ke MySQL untuk menjana laporan untuk analisis.

Gunakan pemasangan PYPI

pip install rdbtools

Salin selepas log masuk

Jana gambar memori

rdb -c memory dump.rdb > memory.csv

Salin selepas log masuk

Dalam fail CSV yang dijana terdapat lajur berikut:

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`)
 );

Salin selepas log masuk

例子：查询内存占用最高的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)

Salin selepas log masuk

Big Key问题解决思路

当发现存在大key问题时，我们需要及时采取措施来解决这个问题。下面列出几种可行的解决思路：

分割大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!