Khi một người đăng ký (người tiêu dùng) chết, danh sách của bạn sẽ tiếp tục phát triển cho đến khi khách hàng quay trở lại. Nhà sản xuất của bạn có thể cắt danh sách (từ một trong hai bên) khi nó đạt đến một giới hạn cụ thể, nhưng đó là điều bạn cần xử lý ở cấp ứng dụng. Nếu bạn bao gồm dấu thời gian trong mỗi tin nhắn, thì người tiêu dùng của bạn có thể hành động dựa trên độ tuổi của tin nhắn, giả sử bạn có logic ứng dụng mà bạn muốn thực thi về độ tuổi của tin nhắn.
Tôi không chắc làm thế nào một thông báo không đúng định dạng sẽ xâm nhập vào hệ thống, vì kết nối tới Redis thường là TCP với các đảm bảo về tính toàn vẹn của nó. Nhưng nếu điều này xảy ra, có lẽ do lỗi mã hóa thông báo ở lớp nhà sản xuất, bạn có thể cung cấp cơ chế chung để xử lý lỗi bằng cách giữ một hàng đợi cho mỗi nhà sản xuất đã nhận được thông báo ngoại lệ của người tiêu dùng.
Chính sách thử lại sẽ phụ thuộc rất nhiều vào nhu cầu ứng dụng của bạn. Nếu bạn cần đảm bảo 100% rằng một tin nhắn đã được nhận và xử lý, thì bạn nên cân nhắc sử dụng các giao dịch Redis (MULTI / EXEC) để kết thúc công việc do người tiêu dùng thực hiện, vì vậy bạn có thể đảm bảo rằng khách hàng không xóa tin nhắn trừ khi nó đã hoàn thành công việc của nó. Nếu bạn cần xác nhận rõ ràng, thì bạn có thể sử dụng thông báo ACK rõ ràng trên hàng đợi dành riêng cho (các) quy trình sản xuất.
Nếu không biết thêm về nhu cầu ứng dụng của bạn, thật khó để biết cách lựa chọn một cách khôn ngoan. Nói chung, nếu thư của bạn yêu cầu bảo vệ ACID đầy đủ, thì bạn có thể cũng cần sử dụng các giao dịch redis. Nếu thông điệp của bạn chỉ có ý nghĩa khi chúng đến kịp thời, thì có thể không cần đến các giao dịch. Nghe có vẻ như bạn không thể chịu đựng được những tin nhắn bị bỏ qua, vì vậy, cách tiếp cận của bạn là sử dụng danh sách là tốt. Nếu bạn cần triển khai hàng đợi ưu tiên cho các tin nhắn của mình, bạn có thể sử dụng tập hợp đã sắp xếp (các lệnh Z) để lưu trữ các tin nhắn của mình, sử dụng mức độ ưu tiên của chúng làm giá trị điểm, cùng với một người tiêu dùng đang thăm dò ý kiến.
