Panduan pengoptimuman Redis: rangkaian, memori, cakera, titik penyekat

Memandangkan Redis ialah operasi berasaskan memori, CPU bukanlah halangan prestasinya. Sebaliknya, penggunaan memori pelayan, rangkaian IO, dan cakera membaca dan menulis memainkan peranan penting dalam prestasi Redis.

Oleh itu, kami akan memberi tumpuan kepada pengoptimuman dari aspek seperti rangkaian, memori, cakera dan titik sekatan. Jika mana-mana istilah yang tidak jelas, adalah disyorkan untuk merujuk kepada kandungan redis dalam isu terdahulu atau merujuk maklumat yang berkaitan.

Pengoptimuman Rangkaian

Jika pelanggan meminta pelayan, iaitu, dalam mod "request-response", gunakan pemprosesan batch sebanyak mungkin untuk mengurangkan overhed IO rangkaian.

Teknologi pemprosesan kelompok: arahan pemprosesan kumpulan m atom, teknologi saluran paip, redis, transaksi, skrip lua.

Pemprosesan kelompok mengurangkan overhed IO rangkaian

Arahan pemprosesan batch atom m: jenis rentetan, disyorkan untuk menggunakan mget/mset daripada jenis get/set, disyorkan untuk menggunakan hmget/hmset dan bukannya hget/hset.

Teknologi saluran paip: Teknologi saluran paip boleh digunakan apabila terdapat operasi kelompok apabila menggunakan senarai, set dan zset.

Transaksi Redis: Disyorkan apabila keperluan perniagaan khas memerlukan berbilang arahan.

Skrip

lua: Adalah disyorkan untuk menggunakan skrip lua apabila anda perlu memastikan keatoman berbilang arahan Contoh khusus termasuk buka kunci teragih, jualan kilat dan pengurangan inventori.

Pengoptimuman rangkaian antara nod

Bina kluster dalam LAN yang sama;

Kawal bilangan nod dalam kluster berpecah, slot cincang yang diperuntukkan pada tika redis perlu dipindahkan antara tika yang berbeza dan apabila tika pengimbangan hutang dipadamkan, data akan dipindahkan antara tika yang berbeza. Tetapi maklumat slot cincang tidak besar, dan pemindahan data secara beransur-ansur, tetapi ia bukan masalah utama;

Pengoptimuman memori

Kawal panjang kunci: Adalah disyorkan untuk menentukan spesifikasi sebelum pembangunan untuk memastikan kunci itu mudah dan jelas, dan singkatkan kunci mengikut perniagaan sebanyak mungkin.

Elak kunci besar: Saiz jenis rentetan yang disyorkan adalah dalam lingkungan 20KB. Adalah disyorkan untuk mengawal ambang cincang, senarai, set dan zset, dan disyorkan untuk mengawalnya dalam 5000.

Tetapan kunci tamat tempoh: Gunakan memori sepenuhnya.

Pilih struktur data yang betul

Jenis rentetan, adalah disyorkan untuk menggunakan jenis integer Pengekodan asasnya akan memilih pengekodan integer, yang mempunyai overhed memori yang rendah

Jenis hash, adalah disyorkan untuk mengawal ambang elemen Apabila terdapat sedikit elemen, lapisan bawah akan menggunakan struktur data senarai termampat, yang mempunyai overhed memori yang rendah, adalah disyorkan untuk mengawal ambang elemen adalah beberapa elemen, lapisan bawah akan menggunakan struktur data senarai termampat, yang mempunyai overhed memori yang rendah, adalah disyorkan untuk menyimpan jenis Integer, pengekodan asasnya akan memilih pengekodan integer, dan overhed memori adalah kecil

Jenis set, adalah disyorkan untuk mengawal ambang elemen Apabila terdapat sedikit elemen, lapisan bawah akan menggunakan struktur data senarai termampat, yang mempunyai overhed memori yang rendah

Mampatan data: Pelanggan boleh menggunakan algoritma pemampatan seperti snappy dan gzip untuk memampatkan data sebelum menulis kepada redis untuk mengurangkan penggunaan memori Walau bagaimanapun, pelanggan perlu menyahmampat data selepas membaca data, yang akan menggunakan lebih banyak CPU.

Dayakan strategi penghapusan ingatan

Tamatkan strategi penyingkiran ingatan lalai Sila pilih strategi penyingkiran yang sesuai berdasarkan perniagaan sebenar anda untuk meningkatkan penggunaan memori.

LRU: Fokus pada bilangan lawatan, hapuskan kunci yang paling kurang digunakan baru-baru ini, dan mempunyai pelbagai senario penggunaan. LRU Redis menggunakan algoritma yang serupa dengan LRU, menambah medan tambahan dengan panjang 24 bit pada kunci, yang merupakan cap waktu akses terakhir. Gunakan cara malas untuk memproses: apabila melakukan operasi tulis, jika memori maksimum melebihi, algoritma penghapusan LRU dilaksanakan sekali, 5 (nombor boleh ditetapkan) kekunci diambil secara rawak, dan kunci tertua dihapuskan ingatan maksimum masih melebihi selepas penyingkiran, penyingkiran akan diteruskan.

LFU: Fokus pada kekerapan akses, disyorkan apabila menangani pencemaran cache.

Masalah pengoptimuman pemecahan memori

Sebab: Satu disebabkan oleh strategi peruntukan pengalokasi memori Pengalokasi memori memperuntukkan mengikut saiz tetap, bukannya mengikut saiz sebenar yang diminta Contohnya, jika bait yang diminta berada dalam bait yang diminta, 32 bait adalah sebenarnya diperuntukkan; yang lain disebabkan oleh redis Selepas pasangan nilai kunci dipadamkan, pemecahan memori yang disebabkan oleh sebahagian daripada ruang akan dikeluarkan.

Kedudukan: Perhatikan penunjuk men_fragmentation_ratio melalui arahan INFO memori; diproses;

Penyelesaian: Mulakan semula instance redis;

Dayakan fungsi pembersihan pemecahan memori automatik redis.

Pengoptimuman Cakera

Bina secara fizikal perkhidmatan redis: Apabila berterusan, redis menggunakan kaedah mencipta proses anak (yang akan memanggil sistem garpu sistem pengendalian), dan persekitaran mesin maya mengambil masa lebih lama untuk melaksanakan garpu daripada mesin fizikal.

Mekanisme pengoptimuman kegigihan

Jangan dayakan kegigihan: redis hanya digunakan untuk caching, jadi tidak perlu mendayakan kegigihan untuk mengurangkan overhed cakera

Pengoptimuman AOF: proses AOF di latar belakang, konfigurasikan apenfsync everyec untuk meletakkan operasi berus ketekunan data ke dalam utas latar belakang untuk dilaksanakan, dan cuba mengurangkan kesan penulisan redis ke cakera pada prestasi

Jangan membina kegigihan AOF frekuensi tinggi Kekerapan lalai kegigihan AOF adalah sekali sesaat. Ia sudah boleh menjamin bahawa data akan hilang sehingga 1 saat

Dayakan kegigihan hibrid, redis4.0 menyokong kegigihan hibrid RDB + AOF tambahan;

Dayakan konfigurasi berbilang benang Sebelum redis 6.0, kegigihan dikendalikan melalui proses anak garpu utas, tetapi garpu disekat secara serentak, pelbagai proses disokong untuk mengendalikan operasi kegigihan

Pengoptimuman kluster

Slave melakukan pengoptimuman kegigihan: master tidak melakukan kegigihan dan berkongsi tekanan cakera induk IO sebanyak mungkin: mod incremental, kaedah penyegerakan master-slave ditetapkan sebagai mod incremental, dan mod RDB penuh; tidak akan dipilih. Mod penuh adalah One sangat memakan prestasi;

Untuk masalah ini, redis menyokong penyegerakan lata, iaitu master hanya menyegerakkan data ke satu salve, dan kemudian data salve lain disegerakkan dari salve ini untuk melegakan tekanan pada master.

Saiz sebenar disyorkan tidak melebihi 6G. Jika instance terlalu besar, penyegerakan tuan-hamba akan tersekat, dan dalam kes yang serius ia akan menjatuhkan tuan.

AOF akan dimainkan semula semasa mula semula yang tidak normal Jika kejadian terlalu besar, pemulihan data akan menjadi lambat secara luar biasa.

Pengoptimuman titik tercekik

Analisis: Memandangkan Redis adalah satu benang semasa memproses permintaan dan arahan, kesesakan prestasinya ialah masalah penyekatan penyegerakan.

masalah besar

Bahaya: Membaca dan menulis kunci besar boleh menyebabkan tamat masa, dan menyiarkan semula data dalam satu urutan, yang mungkin menyekat keseluruhan perkhidmatan redis secara serius. Selain itu, kunci hanya akan dibahagikan kepada satu nod, jadi tekanan lakaran tidak boleh dikongsi. Pengesanan Bigkey: disertakan dengan arahan bredis-cli-bigkeys. Redis datang dengan arahan yang hanya boleh mencari kunci terbesar antara lima jenis data, yang tidak begitu berguna dan tidak sangat disyorkan. skrip pengimbasan python. Ia boleh mencari kunci tertentu, tetapi ketepatannya tidak tinggi dan tidak disyorkan.

alat rdb_bigkeys. Alat yang ditulis dalam Go, ia adalah pantas dan sangat tepat. Ia juga boleh dieksport terus ke fail csv untuk tontonan dan cadangan yang mudah.

Pengoptimuman: Untuk kunci besar jenis bukan rentetan, set elemen boleh dibahagikan kepada gandaan Contohnya, jika kunci besar dibahagikan kepada 1000 kekunci, akhiran kekunci akan dicincang modulo 1000.

Gunakan cache setempat, contohnya, simpan ID perniagaan + nombor versi dalam redis, letakkan kandungan khusus dalam cache setempat, semak cache redis dahulu untuk setiap pertanyaan, kemudian semak nombor versi dengan cache setempat.

Mengoptimumkan kunci besar secara amnya susah payah. Adalah disyorkan untuk menentukan spesifikasi semasa pembangunan untuk mengelakkan masalah kunci besar.

Dasar Tamat Tempoh

Pemadaman berjadual: Setiap kunci yang telah tamat tempoh diberikan tugas berjadual, dan ia dipadamkan terus apabila ia tamat tempoh. Ia mempunyai penggunaan memori yang tinggi dan penggunaan CPU yang tinggi. Pemadaman malas: Apabila kunci disoal, ia dinilai sama ada kunci itu telah tamat tempoh, ia akan dipadamkan Ini mengakibatkan penggunaan CPU yang rendah dan penggunaan memori yang tinggi. Pemadaman berkala: imbas sekali-sekala, kunci tamat tempoh dipadamkan terus, dan penggunaan CPU dan memori adalah purata.

1. Strategi tamak. Redis akan menetapkan kunci tamat tempoh dalam kamus berasingan.

2. Pilih 20 kekunci daripada kamus tamat tempoh dan padamkan kekunci tamat tempoh di antara 20 kekunci. Jika bahagian kunci yang dipadam melebihi 1/4, ulangi langkah 1.

Berdasarkan logik di atas, untuk menyelesaikan masalah tersangkut benang yang disebabkan oleh gelung yang berlebihan, mekanisme tamat masa ditambah pada algoritma Masa lalai ialah 25ms.

3 Kekerapan imbasan: redis lalai kepada 10 imbasan tamat tempoh sesaat.

Redis mendayakan pemadaman malas + pemadaman biasa secara lalai.

Pengoptimuman: Hidupkan tanpa malas dan operasi pelepasan memori yang memakan masa akan dilaksanakan dalam urutan latar belakang, disokong oleh redis4.0+.

Dayakan mod berbilang benang Sebelum redis 6.0, dasar tamat tempoh adalah operasi segerak bagi utas utama Selepas 6.0, berbilang benang digunakan untuk pemprosesan.

Arahan kerumitan tinggi

Adalah disyorkan untuk menggunakan imbasan untuk membuat pertanyaan dalam kelompok dan jangan gunakan kekunci. Tidak berkenaan dengan operasi pengagregatan: redis menggunakan model berbenang tunggal untuk memproses permintaan Apabila melaksanakan perintah yang terlalu kompleks (mengambil lebih banyak sumber CPU), permintaan berikutnya akan dibariskan dan menyebabkan kelewatan, seperti SINTER, SINTERSTORW, ZUNIONSTORE, ZINTERSTORE, dan lain-lain. Adalah disyorkan untuk menggunakan imbasan untuk mengetahui elemen dalam koleksi dalam kelompok dan melakukan pengiraan pengagregatan pada klien.

Pengendalian data jenis kontena: Apabila terdapat terlalu banyak elemen jenis kontena, pertanyaan langsung akan menyebabkan kelewatan disebabkan oleh rangkaian.

Apabila terdapat terlalu banyak elemen bekas, pemadaman kekunci secara langsung boleh menyebabkan redis menjadi beku. Adalah disyorkan untuk memadamkannya secara berkelompok.

Atas ialah kandungan terperinci Panduan pengoptimuman Redis: rangkaian, memori, cakera, titik penyekat. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!