Rumah > Artikel > pangkalan data > Analisis terperinci tentang cara mengoptimumkan Redis apabila memori penuh
Artikel ini membawakan anda pengetahuan yang berkaitan tentang Redis Ia terutamanya memperkenalkan isu berkaitan cara mengoptimumkan redis apabila memori penuh Ia juga termasuk mekanisme penyingkiran, algoritma LRU dan penyingkiran data , saya harap ia akan membantu semua orang.
Pembelajaran yang disyorkan: Tutorial pembelajaran Redis
Apabila saiz set data memori redis meningkat. kepada saiz tertentu, ia akan Melaksanakan strategi penghapusan data.
Memori.
Jika had atas yang ditetapkan dicapai, arahan tulis Redis akan mengembalikan mesej ralat (tetapi arahan baca masih boleh kembali seperti biasa.) Atau anda boleh mengkonfigurasi mekanisme penghapusan memori, dan apabila Redis mencapai memori atas had, kandungan lama akan disiram .
Apakah strategi penghapusan untuk cache Redis?
Terdapat 7 strategi untuk penyingkiran Kita boleh membahagikannya lagi kepada dua kategori mengikut skop set data calon penyingkiran:
策略 | 规则 |
---|---|
volatile-ttl | 在筛选时,会针对设置了过期时间的键值对,根据过期时间的先后进行删除,越早过期的越先被删除。 |
volatile-random | 在设置了过期时间的键值对中,进行随机删除。 |
volatile-lru | 使用 LRU 算法筛选设置了过期时间的键值对 |
volatile-lfu | 使用 LFU 算法选择设置了过期时间的键值对 |
策略 | 规则 |
---|---|
allkeys-random | 从所有键值对中随机选择并删除数据; |
allkeys-lru | 使用 LRU 算法在所有数据中进行筛选 |
vallkeys-lfu | 使用 LFU 算法在所有数据中进行筛选 |
adalah untuk menapis data mengikut prinsip yang paling kurang digunakan baru-baru ini Data yang paling jarang digunakan akan ditapis keluar, manakala data yang kerap digunakan baru-baru ini akan kekal dalam cache.
Bagaimana sebenarnya anda ditayangkan? LRU akan menyusun semua data ke dalam senarai terpaut Kepala dan ekor senarai terpaut masing-masing mewakili penghujung MRU dan penghujung LRU, mewakili data yang paling baru digunakan dan data yang paling jarang digunakan.
Idea di sebalik algoritma LRU adalah sangat mudah: ia percaya bahawa data yang baru diakses pasti akan diakses semula, jadi ia diletakkan di sebelah MRU data yang belum diakses untuk masa yang lama pasti tidak akan diakses lagi, jadi biarkan ia beransur-ansur kembali ke bahagian LRU Apabila cache penuh, padamkannya terlebih dahulu.
Masalah: Dalam pelaksanaan sebenar, algoritma LRU perlu menggunakan senarai terpaut untuk mengurus semua data cache, yang akan membawa ruang tambahan di atas kepala. Selain itu, apabila data diakses, data perlu dialihkan ke MRU pada senarai terpaut Jika sejumlah besar data diakses, banyak operasi pemindahan senarai terpaut akan berlaku, yang akan memakan masa yang lama dan mengurangkan prestasi cache Redis. .
Penyelesaian:
Dalam Redis, algoritma LRU telah dipermudahkan untuk mengurangkan kesan pengalihan data pada prestasi cache. Khususnya, Redis merekodkan cap waktu akses terkini bagi setiap data secara lalai (dirakam oleh medan lru dalam struktur data pasangan nilai kunci RedisObject). Kemudian, apabila Redis menentukan data untuk dihapuskan, ia akan memilih N keping data secara rawak untuk kali pertama dan menggunakannya sebagai set calon. Seterusnya, Redis akan membandingkan medan lru bagi data N ini dan menghapuskan data dengan nilai medan lru terkecil daripada cache.
Apabila data perlu dihapuskan semula, Redis perlu memilih data ke dalam set calon yang dibuat semasa penyingkiran pertama. Kriteria pemilihan di sini ialah: nilai medan lru bagi data yang boleh memasuki set calon mestilah kurang daripada nilai lru terkecil dalam set calon. Apabila data baharu memasuki set data calon, jika bilangan data dalam set data calon mencapai sampel memori maksimum, Redis akan menghapuskan data dengan nilai medan lru terkecil dalam set data calon.
Cadangan penggunaan:
Setelah data yang dihapuskan dipilih, jika data adalah data bersih, maka kami akan memadamkannya secara langsung jika data itu adalah data kotor, kami perlu menulisnya semula ke pangkalan data.
Kemudian bagaimana untuk menilai sama ada sekeping data itu bersih atau kotor?
Walaupun data yang dihapuskan adalah data kotor, Redis tidak akan menulisnya kembali ke pangkalan data. Oleh itu, apabila kita menggunakan cache Redis, jika data diubah suai, ia perlu ditulis semula ke pangkalan data apabila data diubah suai. Jika tidak, apabila data kotor dihapuskan, ia akan dipadamkan oleh Redis, dan tidak akan ada data terkini dalam pangkalan data.
1. Kawal bilangan kunci: Apabila menggunakan Redis untuk menyimpan sejumlah besar data, biasanya terdapat sejumlah besar kunci, dan terlalu banyak kunci juga akan menggunakan banyak memori. Redis pada asasnya ialah pelayan struktur data, yang memberikan kami pelbagai struktur data, seperti cincang, senarai, set, zset dan struktur lain. Jangan berlaku salah faham apabila menggunakan Redis Gunakan API seperti dapatkan/set secara meluas dan gunakan Redis sebagai Memcached. Untuk menyimpan kandungan data yang sama, menggunakan struktur data Redis untuk mengurangkan bilangan kunci luar juga boleh menjimatkan banyak memori.
2. Kurangkan objek nilai kunci Cara paling langsung untuk mengurangkan penggunaan memori Redis ialah mengurangkan panjang kunci dan nilai.
3. Redis menyediakan jenis luaran seperti rentetan, senarai, cincang, set, zet, dll., tetapi Redis secara dalaman mempunyai konsep pengekodan untuk jenis yang berbeza Pengekodan yang dipanggil merujuk kepada struktur data asas khusus yang digunakan untuk pelaksanaan. Pengekodan yang berbeza secara langsung akan menjejaskan penggunaan memori dan kecekapan membaca dan menulis data.
medan jenis:
Gunakan data jenis pengumpulan , kerana biasanya banyak Nilai-Kekunci kecil boleh disimpan bersama dengan cara yang lebih padat. Gunakan cincangan sebanyak mungkin. Contohnya, jika anda mempunyai objek pengguna dalam sistem web anda, jangan tetapkan kunci berasingan untuk nama pengguna, nama keluarga, e-mel dan kata laluan, sebaliknya, simpan semua maklumat pengguna dalam jadual cincang.
medan pengekodan:
Terdapat perbezaan jelas dalam penggunaan memori menggunakan pengekodan yang berbeza
medan lru:
medan pengiraan semula:Apabila objek ialah integer dan julatnya ialah [0-9999], Redis boleh menggunakan objek kongsi untuk menyimpan memori.
:Petua pembangunan: Dalam senario penulisan serentak tinggi, adalah disyorkan agar panjang rentetan dikawal dalam 39 bait jika keadaan membenarkan , mengurangkan bilangan peruntukan memori untuk mencipta redisObject dan meningkatkan prestasi.
Algoritma LRU perlu mendapatkan masa akses terakhir objek untuk menghapuskan data terpanjang tidak diakses, setiap Masa capaian terakhir objek disimpan dalam medan lru objek redisObject. Perkongsian objek bermakna berbilang rujukan berkongsi redisObject yang sama Pada masa ini, medan lru juga akan dikongsi, menjadikannya mustahil untuk mendapatkan masa akses terakhir setiap objek. Jika maxmemory tidak ditetapkan, Redis tidak akan mencetuskan kitar semula memori sehingga memori habis, jadi kumpulan objek kongsi boleh berfungsi seperti biasa. Ringkasnya, kumpulan objek kongsi bercanggah dengan strategi maxmemory LRU, jadi anda perlu memberi perhatian apabila menggunakannya.
Pertama sekali, kumpulan objek integer mempunyai kebarangkalian tertinggi untuk digunakan semula. Kedua, operasi utama perkongsian objek adalah untuk menilai kesamaan Sebab mengapa Redis hanya mempunyai kumpulan objek integer adalah kerana kerumitan masa algoritma perbandingan integer ialah O(1). Jika kesamaan rentetan dinilai, kerumitan masa menjadi O(n), terutamanya rentetan panjang menggunakan lebih banyak prestasi (nombor titik terapung disimpan secara dalaman dalam Redis menggunakan rentetan). Untuk struktur data yang lebih kompleks seperti cincang, senarai, dsb., pertimbangan kesamaan memerlukan O(n2). Untuk Redis satu benang, overhed sedemikian jelas tidak munasabah, jadi Redis hanya mengekalkan kumpulan objek kongsi integer.
:
Ciri:: Pembinaan semula rentetan: Kaedah pengekodan kedua berdasarkan jenis cincang. Apabila Redis kehabisan memori, pertimbangan pertama adalah untuk tidak menambah mesin untuk pengembangan mendatar Anda harus cuba mengoptimumkan memori terlebih dahulu. Apabila anda menghadapi kesesakan, pertimbangkan pengembangan mendatar. Malah untuk penyelesaian pengelompokan, pengoptimuman tahap menegak adalah sama penting untuk mengelakkan pembaziran sumber dan kos pengurusan yang tidak perlu selepas pengelompokan. Pembelajaran yang disyorkan: Tutorial Redis
Panjang ID yang digunakan dalam kaedah pengekodan sekunder adalah khusus.
Ia melibatkan masalah – apabila struktur asas jenis Hash kurang daripada nilai yang ditetapkan, senarai termampat digunakan dan apabila lebih besar daripada nilai yang ditetapkan, jadual cincang digunakan.
Setelah ditukar daripada senarai dimampatkan kepada jadual cincang, jenis Cincang akan sentiasa disimpan dalam jadual cincang dan tidak akan ditukar kembali kepada senarai dimampatkan.
Dari segi penjimatan ruang memori, jadual cincang tidak secekap senarai termampat. Untuk menggunakan sepenuhnya susun atur memori padat senarai dimampatkan, secara amnya adalah perlu untuk mengawal bilangan elemen yang disimpan dalam Hash.
Jenis cincang yang dikodkan oleh senarai zip masih menyimpan banyak memori daripada set yang dikodkan oleh jadual cincang.
Petua Pembangunan: Selepas menggunakan cincang senarai zip untuk mengoptimumkan kunci, jika anda ingin menggunakan pemadaman tamat masa fungsi, pembangun boleh Menyimpan masa menulis setiap objek, dan kemudian menggunakan arahan hscan untuk mengimbas data melalui tugas yang dijadualkan untuk mencari item data tamat masa dalam cincang dan memadamnya.
Atas ialah kandungan terperinci Analisis terperinci tentang cara mengoptimumkan Redis apabila memori penuh. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!