Apakah yang akan berlaku jika memori Redis terlalu besar?

1 Pangkalan data utama tidak berfungsi

Mula-mula mari kita lihat proses pemulihan bencana terputus pangkalan data utama: seperti ditunjukkan di bawah

Apabila pangkalan data utama rosak, strategi pemulihan bencana kami yang paling biasa ialah "memotong pangkalan data utama". Secara khusus, ia memilih perpustakaan hamba daripada perpustakaan hamba yang tinggal dalam kelompok dan menaik tarafnya kepada perpustakaan induk Selepas perpustakaan hamba dinaik taraf kepada perpustakaan induk, perpustakaan hamba yang tinggal dipasang di bawahnya untuk menjadi perpustakaan hambanya, dan akhirnya. keseluruhan pangkalan data tuan-hamba dipulihkan.

Di atas ialah proses pemulihan bencana yang lengkap, dan proses yang paling mahal ialah pemasangan semula perpustakaan hamba, bukan penukaran perpustakaan induk.

Ini kerana redis tidak boleh terus menyegerakkan data daripada pangkalan data utama baharu selepas pangkalan data utama berubah berdasarkan titik penyegerakan seperti mysql dan mongodb. Setelah pangkalan data hamba menukar induk dalam gugusan redis, pendekatan redis adalah untuk mengosongkan pangkalan data hamba daripada pangkalan data induk yang diganti dan kemudian menyegerakkan sepenuhnya salinan data daripada pangkalan data induk baharu sebelum meneruskan pemindahan.

Seluruh proses buat semula pangkalan data hamba adalah seperti berikut:

1. Pangkalan data utama bgmenyimpan datanya sendiri ke cakera

2. pangkalan data utama menghantar fail rdb ke perpustakaan hamba

3. Mula memuatkan dari perpustakaan

4. Selepas pemuatan selesai, muat naik bermula dan perkhidmatan bermula pada masa yang sama

Jelas sekali, semakin besar saiz memori redis semasa proses ini, semakin lama setiap langkah akan diambil. Data ujian sebenar adalah seperti berikut (kami percaya bahawa mesin kami prestasi lebih baik):

Anda boleh melihat bahawa apabila data mencapai 20G, masa pemulihan pangkalan data hamba telah dilanjutkan kepada hampir 20 minit jika terdapat 10 hamba pangkalan data, memerlukan sejumlah 10 pangkalan data hamba untuk memulihkannya satu per satu 200 minit, dan jika perpustakaan hamba bertanggungjawab untuk sejumlah besar permintaan baca pada masa ini, bolehkah anda bertolak ansur dengan masa pemulihan yang begitu lama? >

Melihat ini, anda pasti akan bertanya: Mengapa semua perpustakaan hamba tidak boleh dibuat semula pada masa yang sama Ini kerana jika semua perpustakaan hamba meminta fail RDB dari perpustakaan utama pada masa yang sama, kad rangkaian perpustakaan utama akan serta-merta menjadi penuh dan memasuki keadaan di mana perkhidmatan tidak dapat disediakan seperti biasa Pada masa ini, perpustakaan utama mati lagi, yang hanya menambah penghinaan kepada kecederaan.

Sudah tentu, kita boleh memulihkan pangkalan data hamba secara berkelompok, contohnya, dalam kumpulan dua, maka masa pemulihan semua pangkalan data hamba hanya dikurangkan dari 200 minit kepada 100 minit. Bukankah ini lima puluh -langkah penyelesaian kepada seratus langkah?

Satu lagi isu penting terletak pada kedudukan merah di titik keempat Pemindahan resume boleh difahami sebagai oplog mongodb yang dipermudahkan Ia adalah ruang memori dengan volum tetap, yang kami panggil "penampan penyegerakan".

Kendalian tulis perpustakaan utama redis akan disimpan di kawasan ini dan kemudian dihantar ke pustaka hamba Jika langkah 1, 2, dan 3 di atas mengambil masa terlalu lama, kemungkinan penimbal penyegerakan akan. jadi Tulis Semula, apakah yang akan dilakukan jika perpustakaan hamba tidak dapat mencari lokasi penyambungan semula yang sepadan Jawapannya adalah untuk membuat semula langkah 1, 2, dan 3!

Tetapi kerana kita tidak dapat menyelesaikan langkah 1, 2 yang memakan masa? , dan 3 Oleh itu, perpustakaan hamba akan selama-lamanya memasuki kitaran ganas: ia akan sentiasa meminta data lengkap daripada perpustakaan utama, yang akan memberi kesan serius pada kad rangkaian perpustakaan utama.

2 Masalah pembesaran kapasiti

Banyak kali akan berlaku peningkatan trafik secara mendadak Biasanya, sebelum puncanya ditemui, tindak balas kecemasan kami adalah untuk mengembangkan kapasiti.

Menurut jadual dalam Senario 1, ia mengambil masa hampir 20 minit untuk mengembangkan pangkalan data hamba redis 20G Bolehkah perniagaan selama 20 minit ini boleh diterima pada saat kritikal ini.

3 Rangkaian yang lemah membawa kepada membuat semula pangkalan data hamba dan akhirnya mencetuskan longsor

Masalah terbesar dalam senario ini ialah penyegerakan antara pangkalan data induk dan hamba pangkalan data terganggu. Kemungkinan pustaka hamba masih menerima permintaan tulis, jadi penimbal penyegerakan mungkin akan ditimpa apabila masa gangguan terlalu lama. Pada masa ini, kedudukan penyegerakan terakhir perpustakaan hamba telah hilang Selepas rangkaian dipulihkan, walaupun perpustakaan induk tidak berubah, kerana kedudukan penyegerakan perpustakaan hamba hilang, perpustakaan hamba mesti dibuat semula, iaitu. 1, 2, dan 3 dalam soalan 1. 4 langkah. Jika saiz memori perpustakaan utama terlalu besar pada masa ini, kelajuan buat semula perpustakaan hamba akan menjadi sangat perlahan, dan permintaan baca yang dihantar ke perpustakaan hamba akan terjejas dengan serius, kerana saiznya fail RDB yang dipindahkan adalah terlalu besar, kad rangkaian perpustakaan utama akan Ia akan terjejas teruk untuk masa yang lama.

4 Semakin besar memori, semakin lama operasi yang mencetuskan kegigihan menyekat utas utama

Redis ialah pangkalan data dalam memori berbenang tunggal dan memakan masa operasi perlu dilakukan dalam redis Semasa operasi, proses baharu akan bercabang, seperti bgsave dan bgrewriteaof. Apabila membuat forking proses baru, walaupun kandungan data boleh kongsi tidak perlu disalin, jadual halaman memori ruang proses sebelumnya akan disalin ini dilakukan oleh utas utama dan akan menyekat semua operasi baca dan tulis penggunaan memori meningkat, Semakin lama masa yang diperlukan. Contohnya: untuk redis dengan memori 20G, bgsave mengambil masa kira-kira 750ms untuk menyalin jadual halaman memori, dan utas utama redis juga akan disekat selama 750ms.

Penyelesaian

Penyelesaian sudah tentu untuk mengurangkan penggunaan memori sebanyak mungkin Dalam keadaan biasa, inilah yang kami lakukan:

1 Tetapkan masa tamat tempoh

Tetapkan masa tamat tempoh untuk kunci sensitif masa Redis sendiri strategi pembersihan kunci tamat tempoh boleh digunakan untuk mengurangkan penggunaan memori bagi kunci tamat tempoh masalah perniagaan. Ia perlu dibersihkan dengan kerap

2 Jangan simpan sampah dalam redis

Ini hanya omong kosong, tetapi adakah sesiapa yang berkongsi masalah yang sama dengan kami?

3 Bersihkan data yang tidak berguna tepat pada masanya

Sebagai contoh, redis membawa 3 data perniagaan, dua perniagaan akan pergi ke luar talian selepas satu tempoh masa, maka anda harus membersihkan data yang berkaitan bagi kedua-dua perniagaan ini

4 Cuba untuk memampatkan data sebanyak mungkin

Sebagai contoh, untuk sesetengah data teks yang panjang, pemampatan boleh mengurangkan penggunaan memori dengan ketara

5 Beri perhatian kepada pertumbuhan memori dan cari kekunci berkapasiti besar

Sama ada DBA atau pembangun, Apabila anda menggunakan redis, anda mesti memberi perhatian kepada ingatan, jika tidak, anda sebenarnya tidak cekap Di sini anda boleh menganalisis kekunci dalam contoh redis yang agak besar untuk membantu perniagaan mencari dengan cepat kunci tidak normal (pertumbuhan kunci yang tidak dijangka sering menjadi punca masalah)

6 pika

Jika anda benar-benar tidak mahu terlalu letih, maka berhijrahlah perniagaan kepada pika sumber terbuka yang baru, supaya anda tidak perlu memberi terlalu banyak perhatian kepada ingatan, ingatan redis terlalu Masalah yang disebabkan olehnya tidak lagi menjadi masalah.

Atas ialah kandungan terperinci Apakah yang akan berlaku jika memori Redis terlalu besar?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!