Mengapa Redis begitu pantas menggunakan satu utas?

Mengapa Redis menggunakan satu utas?

Overhed multi-threading

Jika tiada reka bentuk sistem yang baik, menggunakan multi-threading biasanya akan membawa kepada keputusan yang ditunjukkan di sebelah kanan (perhatikan ordinat). Apabila anda mula-mula meningkatkan bilangan utas, kadar pemprosesan sistem akan meningkat Apabila anda meningkatkan lagi bilangan utas, kadar pemprosesan sistem akan meningkat secara perlahan atau malah berkurangan.

Hambatan utama ialah: Biasanya terdapat sumber dikongsi dalam sistem yang diakses oleh berbilang urutan pada masa yang sama Untuk memastikan ketepatan sumber dikongsi, tambahan mekanisme diperlukan untuk memastikan bahawa benang Keselamatan, seperti mengunci, disertakan dengan overhed tambahan.

Ambil jenis List yang paling biasa digunakan sebagai contoh. Andaikan Redis menggunakan reka bentuk berbilang benang Terdapat dua utas A dan B yang melakukan operasi List dan LPUSH pada LPUSH. masing-masing. Untuk membuat Setiap pelaksanaan mempunyai hasil yang sama, iaitu, [B thread mengeluarkan data yang diletakkan oleh A thread], jadi kedua-dua proses ini perlu dilaksanakan secara bersiri. Ini ialah masalah kawalan capaian serentak sumber kongsi yang dihadapi oleh model pengaturcaraan berbilang benang.

Kawalan akses concurrency sentiasa menjadi isu yang sukar dalam pembangunan berbilang benang: jika anda hanya menggunakan mutex, walaupun jika benang ditambah, kebanyakan utas akan Ia juga sedang menunggu untuk memperoleh kunci mutex, dan selari menjadi bersiri Kadar pemprosesan sistem tidak meningkat dengan pertambahan benang.

Pada masa yang sama, menambah kawalan akses serentak juga akan mengurangkan kebolehbacaan dan kebolehselenggaraan kod sistem, jadi Redis hanya menggunakan mod satu-benang.

Mengapa Redis begitu pantas menggunakan satu utas?

Sebab mengapa utas tunggal digunakan adalah hasil daripada pelbagai pertimbangan oleh pereka Redis.

• Kebanyakan operasi Redis diselesaikan dalam ingatan

• Menggunakan struktur data yang cekap seperti jadual cincang dan jadual langkau

Potensi titik penyekat rangkaian dan operasi IO

Dalam komunikasi rangkaian, untuk memproses permintaan Dapatkan, pelayan perlu mendengar permintaan klien (

) dan mewujudkan sambungan dengan klien (

), baca permintaan dari soket (

), huraikan permintaan yang dihantar oleh klien (

), dan akhirnya kembalikan hasilnya kepada klien (

).

bind/listenPelaksanaan berbenang tunggal yang paling asas ialah melaksanakan operasi di atas mengikut turutan. acceptrecvparsesend

Operasi terima dan recv yang ditandakan dengan warna merah di atas merupakan titik sekatan yang berpotensi:

Apabila Redis mengesan permintaan sambungan, Tetapi apabila sambungan tidak dapat diwujudkan dengan jayanya, ia akan disekat dalam fungsi

dan pelanggan lain tidak akan dapat mewujudkan sambungan dengan Redis pada masa ini

• Apabila Redis melepasi

  daripada Apabila pelanggan membaca data, jika data belum sampai, ia akan sentiasa disekataccept()

• Model IO berprestasi tinggi berdasarkan pemultipleksan

  recv()Untuk menyelesaikan masalah IO Untuk menyelesaikan masalah penyekatan, Redis menggunakan mekanisme pemultipleksan IO Linux, yang membolehkan berbilang soket pendengaran dan soket bersambung wujud serentak dalam kernel (

  ).

Inti akan sentiasa mendengar sambungan atau permintaan data pada soket ini. Redis akan memproses permintaan masuk, dengan itu mencapai kesan satu utas memproses berbilang aliran IO.

select/epoll

Pada masa ini, urutan Redis tidak akan disekat pada pemprosesan permintaan pelanggan tertentu, jadi ia boleh menyambung kepada berbilang pelanggan pada masa yang sama dan memproses permintaan.

Mekanisme panggilan balik

Setelah pilih/epoll mengesan bahawa permintaan tiba pada FD, ia akan mencetuskan acara yang sepadan dan memasukkannya ke dalam baris gilir panggilan balik berasaskan peristiwa dilaksanakan.

Sebagai contoh, Redis mendaftarkan

dan

fungsi panggil balik untuk acara Terima dan Baca. Apabila kernel Linux memantau permintaan sambungan atau permintaan baca data, ia akan mencetuskan acara Terima dan Baca Pada masa ini, kernel akan memanggil semula fungsi

dan

yang sepadan untuk diproses.

Kemacetan prestasi RedisacceptgetSelepas analisis di atas, walaupun berbilang permintaan pelanggan boleh dipantau pada masa yang sama melalui mekanisme pemultipleksan, Redis masih mempunyai beberapa kesesakan prestasi, itulah sebabnya kami A situasi yang perlu dielakkan dalam pengaturcaraan harian. accept

1. Operasi yang memakan masa

Jika sebarang permintaan mengambil masa yang lama dalam Redis, ia akan memberi kesan kepada prestasi keseluruhan pelayan. Permintaan seterusnya mesti menunggu permintaan yang memakan masa sebelumnya diproses sebelum ia boleh diproses.

Ini perlu dielakkan semasa mereka bentuk senario perniagaan; mekanisme lazy-free Redis juga meletakkan operasi pelepasan memori yang memakan masa dalam urutan tak segerak untuk pelaksanaan.

2. Senario konkurensi tinggi

Apabila jumlah konkurensi sangat besar, terdapat kesesakan prestasi dalam membaca dan menulis data IO pelanggan dengan satu utas walaupun mekanisme pemultipleksan IO digunakan , ia masih boleh hanya berbenang tunggal Membaca data klien dalam urutan tidak boleh menggunakan berbilang teras CPU.

Redis dalam 6.0 boleh menggunakan CPU multi-core dan multi-threading untuk membaca dan menulis data klien, tetapi hanya membaca dan menulis untuk klien adalah selari, dan operasi sebenar setiap arahan masih single-threaded .

Soalan menarik lain berkaitan Redis

Ambil peluang ini untuk juga bertanyakan beberapa soalan menarik berkaitan redis.

• Mengapa menggunakan Redis bukankah buruk untuk mengakses memori secara terus?

Ini sebenarnya tidak ditakrifkan dengan jelas untuk sesetengah data yang tidak kerap berubah, ia boleh diletakkan terus dalam memori Ia tidak perlu diletakkan diletakkan dalam ingatan. Mungkin terdapat masalah konsistensi semasa mengemas kini data, iaitu, data pada hanya satu pelayan boleh diubah suai, jadi data hanya wujud dalam memori tempatan. Mengakses pelayan Redis boleh menyelesaikan masalah konsistensi, menggunakan Redis.

• Apakah yang perlu saya lakukan jika terdapat terlalu banyak data yang tidak boleh disimpan dalam ingatan? Sebagai contoh, jika saya ingin cache 100G data, apakah yang perlu saya lakukan?

Terdapat juga iklan di sini Tair ialah sistem cache KV yang diedarkan oleh Taobao. Ia mewarisi operasi yang kaya dari Redis dan ketahanan. Skala dan kebolehpercayaan juga telah ditingkatkan

Atas ialah kandungan terperinci Mengapa Redis begitu pantas menggunakan satu utas?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!