Bagaimanakah Redis melaksanakan baris gilir mesej dan baris gilir mesej tertunda? Artikel berikut akan memperkenalkan kepada anda kaedah pelaksanaan baris gilir mesej dan baris gilir mesej tertunda dalam Redis Saya harap ia akan membantu anda!
Apabila menyebut tentang redis, lebih ramai orang mungkin menganggap penggunaannya sebagai cache Malah, redis juga boleh melaksanakan beberapa baris gilir mesej yang mudah Kami boleh menggunakan data senarai struktur untuk melaksanakan baris gilir. [Cadangan berkaitan: Tutorial video Redis]
lpush (tolak kiri)
dengan baris gilir
rpush (tolak kanan)
disimpan dari sebelah kanan baris gilir
lpop (pop kiri)
dibawa keluar dari sebelah kiri baris gilir
rpop (pop kanan)
Keluarkan dari sebelah kanan baris gilir
Empat perintah di atas boleh membenarkan senarai membantu kami melaksanakan ciri gilir atau tindanan baris gilir maju Mula-mula keluar, ciri tindanan ialah masuk dahulu, keluar terakhir,
jadi baris gilir boleh dilaksanakan menggunakan lpush rpop atau rpush lpop, dan
tindanan boleh dilaksanakan menggunakan lpush lpop atau rpush rpop.
Pengeluar menerbitkan mesej
Mula-mula kami menggunakan rpush untuk menambah lima elemen pada baris gilir yang dipanggil notify-queue, iaitu 1 2 3 4 5, iaitu untuk menerbitkan mesej sebagai pengeluar
Berita penggunaan pengguna
Memandangkan pengeluar menggunakan rpush, pengguna mesti menggunakan lpop Anda boleh melihat gambar di bawah Kami terus memberitahu -beratur menggunakan mesej, dari 1 hingga 5, dan membacanya mengikut urutan Akhirnya, tiada mesej dalam baris gilir, dan pop timbul sentiasa kosong
Apabila menggunakan lpop untuk menggunakan mesej di atas, anda dapat melihat bahawa selepas mesej itu digunakan, setiap kali kita pergi ke pop semula, apa yang kita baca adalah mesej kosong,
Di atas adalah pelaksanaan manual arahan, tetapi jika program kod bertulis terus muncul data (menarik data), ia akan menyebabkan pengundian kosong (bacaan tidak berguna),
kedua-duanya akan menarik tinggi Ia meningkatkan penggunaan CPU klien, meningkatkan QPS redis , dan masih merupakan operasi yang tidak berguna ini boleh menyebabkan pelanggan lain mengakses redis menjadi kurang responsif.
Penyelesaian A (hibernasi)
Memandangkan pengundian kosong akan menyebabkan penggunaan sumber yang lebih tinggi pada kedua-dua pelanggan dan redis, maka Kami boleh membiarkan pelanggan tidur selama 1 saat apabila menerima data kosong, dan kemudian tarik data selepas 1 saat, yang boleh mengurangkan penggunaan
Thread.sleep(1000)
Penyelesaian ini juga mempunyai kelemahan Ya, iaitu kelewatan dalam penggunaan mesej telah meningkat Jika terdapat hanya satu pengguna, kelewatan adalah 1s, iaitu, selepas pengundian kosong, ia berlaku untuk tidur, tetapi pada masa ini, mesej akan datang, dan ia masih perlu menunggu sehingga 1s. untuk bangun sebelum penggunaan ,
Jika terdapat berbilang pengguna, memandangkan masa tidur setiap pengguna berperingkat, beberapa kependaman akan dikurangkan, tetapi adakah terdapat cara yang lebih baik untuk mencapai hampir 0 kependaman?
Penyelesaian B (menyekat bacaan)
Sebenarnya terdapat dua arahan dalam redis tentang pengambilan data baris gilir, iaitu menyekat bacaan,
blpop (menyekat pop kiri)
brpop (menyekat pop kanan)
Menyekat bacaan akan memasuki keadaan tidak aktif apabila tiada data dalam baris gilir Sebaik sahaja mesej datang, Kemudian bertindak balas dengan segera dan baca data, jadi menggunakan blpop/brpop untuk menggantikan lpop/rpop boleh menyelesaikan masalah kelewatan mesej
Teruskan menambah 3 atribut pada baris gilir, 6, 7, 8
<.>
Gunakan blpop untuk membaca baris gilir Parameter terakhir ialah masa menunggu untuk menyekat bacaan operasi blpop.Masalah pemotongan automatik sambungan melahu untuk menyekat bacaan
Apabila pelanggan menggunakan menyekat bacaan, jika masa menyekat terlalu lama, Perkhidmatan ini secara amnya akan menganggapnya sebagai sambungan melahu dan memutuskannya secara aktif untuk mengurangkan sumber yang diduduki oleh sambungan yang tidak berguna Pada masa ini, pelanggan akan membuang pengecualian, Jadi sila ambil perhatian bahawa apabila pelanggan menggunakan bacaan menyekat, Ia adalah perlu untuk menangkap pengecualian dan mengendalikannya dengan sewajarnya, seperti mencuba semula.pelanggan java melaksanakan baris gilir mesej
Ideanya adalah sama seperti di atas, kecuali klien baris arahan redis-cli ditukar kepada java bahasa. Satu utas atau beberapa utas melaksanakan penerbitan rpush,Satu lagi atau lebih utas melakukan penggunaan blpop Kod yang lengkap ialah di: https://github.com/qiaomengnan16/redis-demo/tree/main/redis-queue
Penerbit <. .> Gilir kelewatan bermaksud bahawa mesej itu dimakan oleh pengguna selepas tempoh masa selepas ia dihantar, bukannya dibaca oleh pengguna sebaik sahaja ia dihantar. lakukan ini. Mula-mula, zset boleh diisih mengikut skor, dan skor boleh menyimpan cap masa Jadi setiap kali kami menerbitkan mesej, kami menggunakan cap masa semasa ditambah dengan cap masa tertunda,
Apabila pengguna kemudiannya mendapatkan semula mesej itu. , ia memintas data zset dan memperoleh mesej yang telah memenuhi masa semasa (iaitu, data dengan skor kurang daripada atau sama dengan cap masa semasa diperolehi. Skor kurang daripada atau sama dengan cap masa semasa bermakna mesej itu sudah sampai masanya jika lebih besar bermakna anda perlu menunggu sebentar sebelum dimakan).
Arahan utama zadd (penerbit), zrangebyscore (pelanggan), zrem (pelanggan memadam selepas menggunakan data)Pelaksanaan arahan
Jika anda boleh sahaja menggunakan satu keping data pada satu masa, anda boleh menambah syarat sekatan had, anda boleh melihat Rajah di bawah mengeluarkan data pertama yang boleh digunakan, redis
Pada pada masa yang sama, ambil perhatian bahawa ia berbeza daripada lpop/ dan blpop of list (mereka akan memadamkan data secara automatik dalam baris gilir asal apabila ia muncul) data),
Walaupun data diperoleh, jika anda melakukannya jangan gunakan zrem untuk memadamnya, data ini akan tetap dibaca oleh orang lain, kerana ia masih wujud dalam zset, tetapi zrem Mungkin berlaku bahawa ia telah dipadam (dimakan) oleh orang lain dahulu, jadi kod itu juga perlu menilai sama ada nilai pulangan zrem lebih besar daripada 0 untuk menentukan sama ada kita telah berjaya mendahului mesej ini, dan kemudian menggunakannya dengan betul selepas berjaya.Pelaksanaan Kod
Penerbit
Pelanggan
Uji kesan kelewatan
Alamat kod penuh: https ://github.com/qiaomengnan16/redis-demo/tree/main/redis-delayed-queue
Pengoptimuman, menggunakan lua untuk melaksanakan
Terdapat masalah dalam delay queue yang dilaksanakan di atas Apabila menggunakan zrem untuk menentukan sama ada data telah direbut, kemungkinan besar ia tidak direbut Jika anda terus membaca seperti ini, anda mungkin tidak dapat ambilnya untuk beberapa pusingan, dan sumber terbuang Oleh itu, pengoptimuman boleh dilakukan melalui skrip Lua
Biarkan zrangebyscore dan zrem menjadi operasi atom, yang boleh mengelakkan perbalahan berbilang benang dan pembaziran sumber yang tidak boleh. direbut.Kesimpulan
Sesetengah perisian tengah gilir profesional akan menjadi lebih rumit untuk digunakan dan Meningkatkan operasi dan kos penyelenggaraan, seperti RabbitMQ Sebelum menghantar mesej, anda perlu membuat suis Pertukaran dan kemudian membuat Baris Beratur Kemudian Pertukaran dan Baris perlu terikat Apabila menghantar mesej, anda mesti menentukan kekunci penghalaan padankan Pertukaran dan akhirnya mencapai Baris Gilir Jika senarionya mudah, anda boleh menggunakan redis untuk melaksanakan baris gilir, tetapi perlu diperhatikan bahawa redis tidak mempunyai ciri baris gilir profesional, dan terdapat tiada jaminan ack, yang bermaksud bahawa mesej itu tidak boleh dipercayai Selepas penggunaan gagal, ia akan hilang Jika anda memerlukan kebolehpercayaan 100%, anda masih perlu menggunakan perisian tengah gilir profesional dan mekanisme lain seperti ack sebagai jaminan.
Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila lawati:
Pengenalan kepada Pengaturcaraan! !
Atas ialah kandungan terperinci Perbincangan ringkas mengenai kaedah pelaksanaan baris gilir mesej dan baris gilir mesej tertunda dalam Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!