Claim check pattern trong azure

Thế nào là claim check pattern

Claim check pattern

Nếu bạn gửi 1 lượng lớn tin nhắn, mẫu thiết kế này nó tách những tin nhắn đó làm 2 phần : claim check và payload.Gửi claim check trên nền tảng gửi tin và lưu payload ở 1 dịch vụ nào đó bên ngoài. -> mục đích : Cho phép 1 lượng lớn tin nhắn được gửi theo tiến trình mà vẫn bảo vệ được quả message bus(cái này xem google) và client ko bị chậm (choáng ngợp). Đồng thời giá tiền, phí lưu trữ rẻ hơn so với nền tảng gửi tin nhắn thông thường.

Context ;

Kiến trúc gửi tin nhắn cơ bản trong 1 số trường hợp bắt buộc có thể gửi, nhận, và vận dụng 1 lượng lớn tin nhắn (Bọn này làm được hết mọi thử, gửi ảnh, files âm thanh, text,...) Gửi 1 lượng lớn tin nhắn theo kiến trúc message bus này là đel nên, vì nó cần 1 lượng tài nguyên và băng thông. Nó cũng gây chậm toàn bộ, (Bởi vì thằng message bus này vốn đc tin chỉnh xử lý đoạn tin nhắn nhỏ). Mà hầu hết mọi nền tảng gửi tin nhắn đều giới hạn kích thước tin nhắn mình gửi.

Solution (Cách bọn này nó thiết kế)

Đơn giản là nó tách tin nhắn ra làm 2 phần, phần payload thì lưu cmn ở 1 kho bên ngoài (có thể là MySQL,...) Phần claim check thì được gửi chính.Và thằng cu claim check này có tham chiếu đến thằng payload. Tham chiếu này giúp truy xuất thông tin.

Cân nhắc khi sử dụng

Cân nhắc xóa tin nhắn sau khi tiêu thụ, nếu m ko muốn lưu nó.Nếu lưu trữ blob( là cái data store ấy) nó rẻ nhưng mà nhiều và lâu dài thì đắt.Việc xóa thư có 2 cách : đồng bộ bởi bên nhận hoặc c2 ko đồng bộ = 1 quy trình riêng biệt (loại bỏ k đồng bộ ko ảnh hưởng đến hiệu suất)
Việc lưu trữ và truy xuất thường gây độ trễ và tri phí cao.Trường hợp tin nhắn nhỏ nên bỏ qua mẫu thiết kế này.

Khi nào nên dùng

• Nên dùng khi tin nhắn méo phù hợp hỗ trợ về giới hạn của công nghệ message bus đã lựa chọn. (Nói thẳng ra là nó to vcl, đel gửi đc)
  
• Thứ 2 là thằng dịch vụ data store trên phải được bảo mật (nó phải được xác thực, chỉ thằng đầu ra và đầu nhận được truy cập)(vì data lưu hết bên ngoài).