Messege Queue – Bộ phận không thể thiếu trong các hệ thống lớn và Microservice Architecture

Bài viết được cho phép bởi tác giả Phạm Huy Hoàng

Hôm nay, chúng ta cùng tìm hiểu về Message Queue. Đây là một thành phần cực kì quan trọng, không thể thiếu trong các hệ thống lớn (mình cá là Facebook, Google lẫn LinkedIn đều có nó trong hệ thống), trong kiến trúc microservice.

Tuy vậy, nếu không gặp các dự án lớn hoặc dự án đặc thù, các bạn sẽ không hề biết tới thứ này. Vậy Message Queue là gì, nó có gì hay ho mà được sử dụng nhiều như vậy?

Đọc xong bài này bạn sẽ biết ngay nhé!

Messege Queue là cái chi chi?

Nói một cách huề vốn, Message Queue tức là một cái Queue (hàng đợi), chứa nhiều Message.

Đùa thế thôi, các bạn có thể hiểu message queue là một hộp thư, cho phép các thành phần/service trong một hệ thống (hoặc nhiều hệ thống), gửi thông tin cho nhau.

Sở dĩ gọi nó là queue (hàng đợi) vì nó thực hiện việc lấy message theo cơ chế FIFO – First In First Out, tức đút vào trước thì rút ra trước.

Một hệ thống sử dụng Message Queue thường có những thành phần sau đây:

• Message: Thông tin được gửi đi (có thể là text, binary hoặc JSON)
• Message Queue: Nơi chứa những message này, cho phép producer và consumer có thể trao đổi với nhau
• Producer: Chương trình/service tạo ra thông tin, đưa thông tin vào message queue
• Consumer: Chương trình/service nhận message từ message queue và xử lý
• Một chương trình/service có thể vừa là producer, vừa là consumer 

Message Queue được sử dụng ra sao trong thực tế?

Trong các hệ thống dùng kiến trúc microservice, ta sử dụng message queue để giúp các service liên hệ với nhau một cách bất đồng bộ. Service A làm xong việc có thể gửi message queue để service B biết mà xử lý, không cần phải chờ service B làm xong.

Giả sử, mình có một trang web cho phép người dùng tải link từ mu*vl, nhầm, từ Youtube, mình sẽ có các bộ phận sau:

• Web service: Là 1 producer. Nhận thông tin (url Youtube) từ phía người dùng, đưa thông tin này vào message queue
• Processing Service: Vừa là consumer vừa là producer. Service này đọc url Youtube từ message queue, bắt đầu tải file về và encode lại, lưu vào server. Sau khi encode xong, nó đưa url của file đã encode vào message queue
• Uploading Service:  Khi nhận được message từ processing server, nó sẽ upload các video đó lên Google Drive v…v

Trong thực tế, message queue giải quyết được khá nhiều vấn đề hóc búa trong hệ thống:

• Đảm bảo duration/recovery: Do message đã được lưu trong queue, khi 1 service đang xử lý nhưng bị crash hoặc lỗi, ta không lo bị mất dữ liệu; vì có thể lấy message từ trong queue ra và chạy lại. Trong 1 hệ thống có nhiều consumer, nếu 1, 2 consume bị crash cũng không làm sụp toàn hệ thống
• Phân tách hệ thống: Giúp phân tách hệ thống thành nhiều service nhỏ hơn, mỗi service chỉ xử lý 1 chức năng nhất định (Ưu nhược điểm thì các bạn xem lại bài về microservice nhé)
• Hộ trợ rate limit, batching: Trong nhiều trường hợp, năng lực xử lý hệ thống có hạn (chỉ có thể xử lý 300 đơn hàng/s). Với message queue, ta có thể dần dần lấy đơn hàng trong queue ra xử lý, không sợ thất lại. Hoặc thay vì mỗi lần gửi email mất thời gian lâu, ta có thể đợi message queue có yêu cầu gửi 200 email rồi gửi luôn 1 lượt.
• Dễ scaling hệ thống: Vào giờ cao điểm, nhiều truy vấn, ta có thể tăng số lượng consumer lên để xử lý được nhiều messege hơn. Khi không cần ta có thể giảm lại.

 

Xem thêm các việc làm MySQL hấp dẫn trên TopDev

Một số điểm cần lưu ý

Tất nhiên, không có công nghệ nào là vạn năng. Khi sử dụng bất cứ công nghệ nào, ta cũng cần biết những điều cần lưu ý:

• Khó xử lý đồng bộ: Không phải hệ thống nào cũng cần tới message queue. Nếu như service A gọi service B, theo cơ chế đồng bộ, cần kết quả xử lý ngay, ta nên dùng Rest hoặc gRPC sẽ tốt hơn.
• Làm hệ thống phức tạp hơn: Thêm message queue sẽ tăng tính phức tạp của hệ thống.  Ta cần phải biết rõ message nào gửi vào queue nào, ai gửi ai nhận. Lúc debug ở local cũng sẽ khó khăn hơn
• Cần đảm bảo message format: Để gửi/nhận, 2 phía producer và consumer phải thống nhất format với nhau. Nếu không cẩn thận lỡ 1 bên thay đổi sẽ làm bên kia không đọc được dữ liệu.
• Cần Monitoring Queue: Cần có các biện phát theo dõi (monitor), để đảm bảo lượng message queue không quá nhiều, làm đầy queue. Queue tốt nhất là queue luôn rỗng, hoặc số lượng message trong queue không tăng lên (message gửi vào queue đều bị consume hết)

Một số message queue hay được dùng hiện này bao gồm:

• RabbitMQ
• Kafka (Kafka còn làm được lắm trò hay ho hơn message queue nữa cơ)
• Amazon SQS
• MSMQ (Microsoft Message Queuing)
• RocketMQ
• ZeroMQ

 

Tạm kết

Đấy, trong bài này mình đã chia sẻ về message queue, một bộ phận không thể thiếu trong các hệ thống lớn, các hệ thống sử dụng kiến trúc microservice.

Khi các bạn ở tầm senior, tầm software architect, trong quá trình làm việc/phỏng vấn chắc chắn sẽ đụng phải thứ này đấy! Nếu bạn có kinh nghiệm gì muốn chia sẻ thêm thì cứ đăng trong phần comment nhé!

Bài viết gốc được đăng tải tại toidicodedao

Có thể bạn quan tâm:

• System Design Cơ Bản: Message Broker
• Kết nối AMQP Client với RabbitMQ Server
• Hiện thực WebSocket với Spring framework

Xem thêm Việc làm Developer hấp dẫn trên TopDev