Bagaimana untuk menyelesaikan masalah menggunakan Pipelining untuk mempercepatkan pertanyaan dalam Redis

Protokol Permintaan/Respons dan RTT

Redis ialah perkhidmatan TCP mod client-server, juga dikenali sebagai pelaksanaan protokol Request/Response.

Ini bermakna biasanya penyempurnaan permintaan mengikut dua langkah berikut:

• Klien menghantar arahan operasi kepada Pelayan , Baca nilai tindak balas Pelayan daripada soket TCP Secara umumnya, ini ialah kaedah menyekat

• Pelayan melaksanakan perintah operasi dan kemudian mengembalikan nilai respons kepada Klien

  <.>

Contohnya

Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4

Pelanggan dan Pelayan disambungkan melalui rangkaian. Sambungan rangkaian boleh menjadi sangat pantas (seperti rangkaian gelung balik tempatan) atau sangat perlahan (seperti rangkaian yang merangkumi berbilang hos). Tidak kira apa rangkaian itu, ia mengambil masa tertentu untuk paket data pergi dari Pelanggan ke Pelayan, dan kemudian nilai yang sepadan dikembalikan dari Pelayan kepada Pelanggan.

Kali ini dipanggil RTT (Waktu Perjalanan Pergi Balik). Apabila Pelanggan perlu melaksanakan berbilang permintaan berturut-turut (seperti menambahkan banyak elemen pada senarai, atau mengosongkan banyak pasangan nilai kunci dalam Redis), bagaimanakah RTT mempengaruhi prestasi? Ini juga sangat mudah untuk dikira. Sebagai contoh, jika masa RTT ialah 250ms (dengan andaian sambungan Internet sangat perlahan), walaupun pelayan boleh mengendalikan 100k permintaan sesaat, ia hanya boleh menerima 4 permintaan sesaat sahaja.

Jika ia adalah rangkaian gelung balik, RTT akan menjadi sangat singkat (contohnya, 127.0.0.1 pengarang, masa tindak balas RTT ialah 44ms), tetapi ia juga merupakan perbelanjaan yang besar apabila melakukan beberapa operasi tulis berturut-turut .

Sebenarnya, kami ada cara lain untuk mengurangkan penggunaan dalam senario ini, adakah anda gembira? Kejutan?

Redis Pipelining

Terdapat ciri dalam perkhidmatan

: walaupun pelanggan tidak menerima nilai respons sebelumnya, ia boleh terus menghantar permintaan baharu. Ciri ini bermakna kita tidak perlu menunggu respons pelayan Kita boleh menghantar banyak arahan operasi ke pelayan terlebih dahulu, dan kemudian membaca semua nilai respons pelayan sekali gus. Request/Response

Kaedah ini dipanggil teknologi

, yang telah digunakan secara meluas dalam beberapa dekad kebelakangan ini. Sebagai contoh, pelaksanaan berbilang protokol POP3 menyokong ciri ini, yang sangat meningkatkan kelajuan memuat turun e-mel baharu daripada pelayan. Pipelining

Redis telah menyokong teknologi ini sangat awal, jadi tidak kira versi apa yang anda jalankan, anda boleh menggunakan teknologi

Contohnya, berikut adalah yang menggunakan alat netcat: pipelining

$ (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG

Sekarang kami tidak perlu membayar RTT untuk setiap permintaan, tetapi menghantar tiga arahan operasi sekaligus. Untuk memudahkan pemahaman intuitif, mari kita ambil penjelasan sebelum ini Urutan pelaksanaan menggunakan teknologi

adalah seperti berikut: pipelining

Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4

Serlahkan (ketuk pada papan hitam): Apabila pelanggan menggunakan

untuk. menghantar arahan operasi, bahagian pelayan Akan memaksa penggunaan memori untuk mengatur keputusan tindak balas. Oleh itu, apabila menggunakan pipelining untuk menghantar sejumlah besar arahan operasi, adalah lebih baik untuk menentukan bilangan perintah yang munasabah dan menghantarnya ke pelayan dalam kelompok Contohnya, hantar 10k arahan operasi, baca hasil tindak balas, dan kemudian hantar arahan Operasi 10k, dan seterusnya... Walaupun penggunaan masa hampir sama, penggunaan memori tambahan akan menjadi nilai maksimum yang diperlukan untuk hasil tindak balas susunan arahan operasi 10k ini. (Untuk mengelakkan keletihan ingatan, pilih nilai yang munasabah)pipelining

Ia bukan hanya soal RTT Membantu anda meningkatkan bilangan arahan yang dilaksanakan sesaat. Hakikatnya ialah: dari perspektif mengakses struktur data yang sepadan dan menjana hasil balasan, tidak menggunakan

adalah benar-benar murah tetapi dari perspektif soket I/O, ia adalah sebaliknya. Kerana ini melibatkan panggilan

dan

, anda perlu bertukar daripada mod pengguna kepada mod kernel. Penukaran konteks jenis ini akan memakan masa terutamanya. PipeliningpipeliningSetelah teknologi read() digunakan, banyak arahan operasi akan melaksanakan operasi baca daripada panggilan write() yang sama, dan sejumlah besar hasil balasan akan diedarkan kepada panggilan

yang sama untuk melaksanakan penulisan operasi. Berdasarkan ini, apabila panjang saluran paip meningkat, bilangan pertanyaan yang dilaksanakan sesaat pada mulanya meningkat hampir secara linear sehingga 10 kali ganda garis dasar tanpa menggunakan teknologi

, seperti ditunjukkan di bawah: pipeliningread()write()pipelining

Sesetengah contoh kod dunia sebenar

tidak diterjemahkan, yang pada asasnya bermakna menggunakan

meningkatkan prestasi sebanyak 5 kali ganda.

Pipelining VS Scripting

Redis Scripting(2.6+版本可用)，通过使用在Server端完成大量工作的脚本Scripting，可以更加高效的解决大量pipelining用例。使用脚本Scripting的最大好处就是在读和写的时候消耗更少的性能，使得像读、写、计算这样的操作更加快速。（当client需要写操作之前获取读操作的响应结果时，pepelining就显得相形见拙。） 有时候，应用可能需要在使用pipelining时，发送 EVAL 或者 EVALSHA 命令，这是可行的，并且Redis明确支持这么这种SCRIPT LOAD命令。（它保证可可以调用 EVALSHA 而不会有失败的风险）。

Appendix: Why are busy loops slow even on the loopback interface?

读完全文，你可能还会感到疑问：为什么如下的Redis测试基准 benchmark 会执行这么慢，甚至在Client和Server在一个物理机上也是如此：

FOR-ONE-SECOND:
    Redis.SET("foo","bar")
END

毕竟Redis进程和测试基准benchmark在相同的机器上运行，并且这是没有任何实际的延迟和真实的网络参与，不就是消息通过内存从一个地方拷贝到另一个地方么？ 原因是进程在操作系统中并不是一直运行。真实的情景是系统内核调度，调度到进程运行，它才会运行。比如测试基准benchmark被允许运行，从Redis Server中读取响应内容（与最后一次执行的命令相关），并且写了一个新的命令。这时命令将在回环网络的套接字中，但是为了被Redis Server读取，系统内核需要调度Redis Server进程（当前正在系统中挂起），周而复始。所以由于系统内核调度的机制，就算是在回环网络中，仍然会涉及到网络延迟。 简言之，在网络服务器中衡量性能时，使用回环网络测试并不是一个明智的方式。应该避免使用此种方式来测试基准。

Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan masalah menggunakan Pipelining untuk mempercepatkan pertanyaan dalam Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!