SQS và SNS: Tìm hiểu các dịch vụ nhắn tin của AWS

Amazon SNS là gì?

Amazon Simple Notification Service (SNS) là dịch vụ nhắn tin được quản lý hoàn toàn, hỗ trợ giao tiếp giữa ứng dụng với ứng dụng (A2A) và ứng dụng với người dùng (A2P). Dịch vụ này được thiết kế cho thông báo theo thời gian thực và phân phối tin nhắn đến ứng dụng và người dùng một cách có khả năng mở rộng và hiệu quả. 

Tương tự SQS, Amazon SNS hỗ trợ lưu giữ tin nhắn bằng cách cho phép người dùng tạo dead-letter queue để lưu các tin nhắn không thể xử lý. 

Amazon SNS sử dụng mô hình nhắn tin xuất bản/đăng ký (pub/sub) và gồm 3 phần:

• Publisher (bên xuất bản): Hệ thống tạo và gửi tin nhắn đến một chủ đề (topic) SNS.
• Topic (chủ đề): Điểm truy cập cho phép phân phối tin nhắn đến nhiều điểm cuối.
• Subscriber (bên đăng ký): Điểm cuối nhận tin nhắn từ chủ đề.

Sơ đồ kiến trúc mô hình nhắn tin SNS. Nguồn hình: AWS

SNS có hiệu năng cao và có thể gửi tin nhắn đến nhiều bên đăng ký đồng thời. Với giao tiếp A2A, SNS có thể chuyển tin nhắn đến AWS Lambda, Amazon Kinesis Firehose, và thậm chí Amazon SQS. Với giao tiếp A2P, SNS có thể gửi tin nhắn trực tiếp đến người dùng qua tin nhắn văn bản, email hoặc thông báo đẩy. 

Nếu bạn muốn làm chủ AWS và tích hợp nhiều dịch vụ của nó để tạo ra các giải pháp tối ưu, hãy cân nhắc học khóa AWS Cloud Technology and Services. 

Các tính năng như hệ thống cảnh báo, kiến trúc fan-out và thông báo thời gian thực góp phần tạo nên độ bền vững và độ tin cậy cao của Amazon SNS. Nhờ thông lượng tin nhắn lớn và khả năng hỗ trợ cả A2A lẫn A2P, SNS thường là thành phần không thể thiếu trong các kiến trúc hướng sự kiện.

Khác biệt cốt lõi giữa SQS và SNS

Việc lựa chọn giữa SQS và SNS đòi hỏi hiểu rõ sự khác nhau giữa hai dịch vụ nhắn tin này. Phần này nêu các tiêu chí chính phân biệt chúng. 

Đẩy (push) so với thăm dò (poll)

Amazon SQS dùng hệ thống thăm dò, trong đó các consumer định kỳ thăm dò hàng đợi để kiểm tra tin nhắn mới.

Amazon SNS, một hệ thống dựa trên đẩy, tự động đẩy tin nhắn đến các subscriber ngay khi chúng được xuất bản trên một topic.

Kiểu người nhận

Amazon SQS chỉ hỗ trợ giao tiếp A2A, cho phép gửi tin nhắn đến các dịch vụ AWS khác như AWS EC2, AWS Lambda, AWS RDS và AWS Redshift. 

Amazon SNS hỗ trợ cả A2A và A2P, gửi tin nhắn đến các dịch vụ AWS (ví dụ, AWS S3, AWS EC2) và liên hệ người dùng (ví dụ, SMS và email) với vai trò subscriber.

Lưu giữ tin nhắn

Amazon SQS có thể lưu tin nhắn tối đa 14 ngày, cho phép consumer có đủ thời gian xử lý. Ngược lại, Amazon SNS không lưu giữ tin nhắn, mà phân phối ngay khi chúng được xuất bản.

Mô hình phân phối tin nhắn

Amazon SQS sử dụng mô hình một-một, trong đó chỉ một consumer xử lý mỗi tin nhắn. Dù có nhiều consumer cùng lúc thăm dò hàng đợi, chỉ một consumer nhận được tin nhắn cụ thể. Khi consumer đó đang xử lý tin nhắn, SQS sử dụng tính năng visibility timeout để ẩn tin nhắn đó với các consumer khác. 

Amazon SNS hỗ trợ mẫu fan-out, trong đó cùng một tin nhắn trên một topic được gửi đến mọi subscriber đồng thời. Các subscriber này xử lý tin nhắn một cách độc lập.

Gom lô (batching)

Amazon SQS cho phép người dùng gom lô tin nhắn, tức là gửi tin nhắn đến consumer theo nhóm. Kích thước lô có thể cấu hình trong AWS. 

Amazon SNS không hỗ trợ gom lô, chỉ cho phép xử lý một tin nhắn tại một thời điểm. 

Bảng sau tóm tắt các khác biệt chính này:

Khi nào dùng SQS

SQS là lựa chọn ưu tiên cho kiến trúc đám mây khi hệ thống phân phối tin nhắn cần:

• Cơ chế thăm dò - consumer có thể chủ động chọn thời điểm thăm dò tin nhắn.
• Xử lý bất đồng bộ - các dịch vụ xử lý tin nhắn độc lập.
• Lưu giữ tin nhắn - tin nhắn có thể lưu tối đa 14 ngày.
• Đảm bảo giao tin nhắn - không có tin nhắn nào trong hàng đợi bị mất.
• Gom lô - dịch vụ xử lý tin nhắn theo nhóm.

Xem ví dụ thực tế sau: Một nền tảng thương mại điện tử muốn xử lý đơn đặt hàng của khách, bao gồm lưu dữ liệu liên quan đến đơn hàng vào cơ sở dữ liệu RDS. 

Sơ đồ kiến trúc hệ thống dùng Amazon SQS để xử lý dữ liệu—hình minh họa của Tác giả.

Trong luồng này, khách hàng gửi đơn hàng, đơn sẽ vào hàng đợi SQS. Hàm Lambda (tức consumer) thăm dò hàng đợi, nhận tin nhắn và ghi dữ liệu vào cơ sở dữ liệu RDS.

Có nhiều lợi ích khi dùng SQS cho trường hợp này. Vì SQS tách rời quy trình, khách vẫn có thể đặt hàng ngay cả khi cơ sở dữ liệu tạm thời không hoạt động. Do SQS cung cấp giao hàng ít nhất một lần, tất cả đơn hàng sẽ được xử lý mà không lo mất tin nhắn. Cuối cùng, SQS hỗ trợ gom lô, cho phép xử lý tin nhắn theo nhóm, từ đó cải thiện hiệu quả.

Amazon SNS không phù hợp ở đây vì không lưu giữ tin nhắn và sẽ đẩy ngay tin nhắn đến hàm Lambda bất kể trạng thái của cơ sở dữ liệu. Do đó, nếu cơ sở dữ liệu không khả dụng, tin nhắn có thể bị mất. Ngoài ra, vì SNS không hỗ trợ gom lô, nó sẽ xử lý từng tin nhắn một, kém tối ưu hơn. 

Khi nào dùng SNS

SNS là lựa chọn ưu tiên cho kiến trúc đám mây khi hệ thống phân phối tin nhắn cần:

• Thông báo thời gian thực - tin nhắn được đẩy ngay đến subscriber với độ trễ thấp.
• Phân phối fan-out - nhiều subscriber có thể nhận cùng một tin nhắn đồng thời.
• Nhiều kênh nhận thông báo - tin nhắn có thể gửi đến ứng dụng (ví dụ, AWS Lambda) và người dùng cuối (ví dụ, email).

Xem tình huống một nhà phát triển giám sát mức sử dụng CPU của phiên bản EC2 của họ. Để đảm bảo mức sử dụng luôn thấp, họ muốn theo dõi chỉ số sử dụng CPU trên CloudWatch và nhận thông báo bất cứ khi nào nó vượt ngưỡng.

Amazon SNS sẽ hỗ trợ đắc lực vì đẩy thông báo theo thời gian thực và hỗ trợ cả quy trình A2A lẫn A2P. Với mẫu fan-out, SNS có thể ngay lập tức gửi thông báo đến các hàm Lambda để xử lý sự cố và gửi email cho nhà phát triển để thông báo về cảnh báo đã kích hoạt. 

Sơ đồ kiến trúc hệ thống dùng Amazon SNS để giám sát—hình minh họa của Tác giả. 

Amazon SQS sẽ kém hiệu quả cho công việc này do cơ chế lưu giữ tin nhắn. Nếu nhà phát triển muốn phản hồi khi vượt ngưỡng, họ cần cảnh báo thời gian thực, điều này không thể nếu tin nhắn bị lưu trong hàng đợi. Hơn nữa, vì SQS dùng cơ chế thăm dò, tin nhắn chỉ được truy cập khi consumer thăm dò, làm tăng độ trễ. 

Kết hợp SQS và SNS: Tận dụng ưu điểm của cả hai

Amazon SQS và Amazon SNS có các đặc điểm riêng, nhưng người dùng AWS có thể tận dụng tốt nhất cả hai bằng cách kết hợp chúng để xây dựng hệ thống nhắn tin hiệu quả, có khả năng mở rộng và chịu lỗi tốt. 

Việc tích hợp hai dịch vụ khá dễ dàng vì hàng đợi SQS có thể đăng ký các topic SNS. Như vậy, SNS có thể gửi thông báo thời gian thực đến các hàng đợi SQS, sau đó SQS sẽ tách rời các quy trình đồng thời đảm bảo giao tin nhắn. 

Xem ví dụ sau: Một nhà phát triển AWS đang tạo hệ thống nộp tài liệu để trích xuất nội dung từ tài liệu do người dùng gửi. Hệ thống này cần thực hiện hai tác vụ cho mỗi tài liệu được gửi:

1. Xử lý tài liệu bằng ứng dụng xử lý văn bản.
2. Gửi email xác nhận cho người dùng cuối.

Nhà phát triển có thể kết hợp SQS và SNS để tạo giải pháp hiệu quả:

Sơ đồ kiến trúc hệ thống dùng SNS kết hợp SQS—hình minh họa của Tác giả.

Trong luồng này, khi người dùng nộp tài liệu, một tin nhắn được gửi đến topic SNS, từ đó ngay lập tức đẩy tin nhắn đến hàm Lambda và hàng đợi SQS. Hàm Lambda phụ trách gửi email xác nhận, còn hàng đợi SQS sẽ quản lý tin nhắn để máy chủ EC2 chạy ứng dụng xử lý văn bản thăm dò và xử lý. 

Kết luận

Amazon SQS và SNS là các dịch vụ cốt lõi trong hệ sinh thái AWS, mỗi dịch vụ có ưu điểm riêng. SNS cung cấp thông báo thời gian thực, trong khi SQS cung cấp xử lý tin nhắn đáng tin cậy. 

Giải pháp nhắn tin lý tưởng cho một bài toán có thể bao gồm SNS, SQS hoặc cả hai. Hiểu thấu đáo từng dịch vụ giúp nhà phát triển AWS xây dựng giải pháp nhắn tin phù hợp với nhu cầu kinh doanh riêng, đảm bảo hiệu quả, khả năng mở rộng và khả năng chống chịu.

Nếu bạn muốn nâng cao kiến thức AWS, hãy cân nhắc hai khóa học nâng cao sau:

• AWS Security and Cost Management
• Streaming Data with AWS Kinesis and Lambda

Hoặc chuẩn bị cho chứng chỉ AWS Cloud Practitioner với lộ trình kỹ năng của chúng tôi:

• AWS Cloud Practitioner (CLF-C02)