Với ví dụ và mã giả mà bạn đã cung cấp, hãy tưởng tượng rằng:
-
recipient.user1nhận được 60 tin nhắn mỗi phút - và
perform_task()phương thức mất 2 giây để thực thi.
Điều gì sẽ xảy ra ở đây là hiển nhiên:độ trễ giữa một tin nhắn mới đến và việc nó được xử lý sẽ chỉ tăng lên theo thời gian, ngày càng xa hơn so với "xử lý thời gian thực".
system throughput = 30 messages/minute
Để giải quyết vấn đề này, bạn có thể muốn tạo một nhóm khách hàng cho user1 . Ở đây, bạn có thể có 4 quy trình python riêng biệt chạy song song với cả 4 quy trình được tham gia trong cùng một nhóm cho user1 . Bây giờ khi một thông báo đến cho user1 một trong 4 công nhân sẽ nhận nó và perform_task() .
system throughput = 120 message/minute
Trong ví dụ của bạn, message.acknowledge() không thực sự tồn tại, vì trình đọc luồng của bạn chỉ có một mình (lệnh XREAD).
Nếu đó là một nhóm, việc xác nhận thông báo trở nên cần thiết, đó là cách redis biết rằng một trong các thành viên nhóm đã xử lý thông báo đó trên thực tế, vì vậy nó có thể "tiếp tục" (có thể quên thực tế rằng thông báo đó đang chờ xác nhận) . Khi bạn đang sử dụng nhóm, có một chút logic phía máy chủ để đảm bảo rằng mọi thông báo đều được gửi đến một trong các nhóm người tiêu dùng, công nhân một lần (Các lệnh XGROUPREAD). Khi máy khách hoàn tất, nó đưa ra xác nhận thông báo đó (lệnh XACK) để phía máy chủ "bộ đệm nhóm người tiêu dùng" có thể xóa nó và tiếp tục.
Hãy tưởng tượng nếu một công nhân chết và không bao giờ thừa nhận thông điệp. Với một nhóm người tiêu dùng, bạn có thể đề phòng trường hợp này (sử dụng lệnh XPENDING) và xử lý chúng bằng cách thử lại để xử lý cùng một thông báo trong một người tiêu dùng khác.
Khi bạn không sử dụng nhóm, máy chủ redis không cần "tiếp tục", "xác nhận" sẽ trở thành 100% phía máy khách / logic nghiệp vụ.
