Dengan contoh dan kode semu yang Anda berikan, bayangkan bahwa:
recipient.user1menerima 60 pesan per menit- dan
perform_task()metode ini membutuhkan waktu 2 detik untuk dieksekusi.
Apa yang akan terjadi di sini sudah jelas:latensi antara pesan baru yang masuk dan diproses hanya akan bertambah seiring waktu, semakin menjauh dari "pemrosesan waktu nyata".
system throughput = 30 messages/minute
Untuk menyiasatinya, Anda mungkin ingin membuat grup konsumen untuk user1 . Di sini Anda dapat menjalankan 4 proses python berbeda secara paralel dengan keempatnya bergabung dalam grup yang sama untuk user1 . Sekarang ketika sebuah pesan masuk untuk user1 salah satu dari 4 pekerja akan mengambilnya dan perform_task() .
system throughput = 120 message/minute
Dalam contoh Anda, message.acknowledge() sebenarnya tidak ada, karena pembaca aliran Anda sendiri (perintah XREAD).
Jika itu adalah grup, pengakuan pesan menjadi penting, begitulah cara redis mengetahui bahwa salah satu anggota grup memang menangani pesan itu, sehingga mungkin "bergerak" (mungkin melupakan fakta bahwa pesan itu menunggu pengakuan) . Saat Anda menggunakan grup, ada sedikit logika sisi server untuk memastikan bahwa setiap pesan dikirim ke salah satu pekerja grup konsumen sekali (perintah XGROUPREAD). Ketika klien selesai, itu mengeluarkan pengakuan pesan itu (perintah XACK) sehingga sisi server "buffer grup konsumen" dapat menghapusnya dan melanjutkan.
Bayangkan jika seorang pekerja meninggal dan tidak pernah menerima pesan tersebut. Dengan grup konsumen, Anda dapat mewaspadai situasi ini (menggunakan perintah XPENDING) dan menindaklanjutinya, misalnya mencoba memproses pesan yang sama di konsumen lain.
Saat Anda tidak menggunakan grup, server redis tidak perlu "move on", "pengakuan" menjadi logika bisnis/sisi klien 100%.
