Giới thiệu

Đã bao giờ bạn thử hình dung các hệ thống siêu to của các tập đoàn như #Facebook, #Google hoạt động thế nào chưa? Mình cũng chưa có cơ hội tiếp cận được đến bản thiết kế hệ thống của Google hay Facebook, nhưng trải qua nhiều hệ thống lớn nhỏ khác nhà từ công ty nhỏ, công ty to, đến tập đoàn lớn mình đoán Facebook hay Google cũng sẽ không khác. Bản chất của một hệ thống đó là mạng nội bộ với rất nhiều máy tính kết nối với nhau thông qua rất nhiều giao thức, tất cả cơ bản đều dựa trên #TCP và #UDP, câu hỏi đặt ra là phải làm thế nào để các máy tính kết nối với nhau một cách hiệu quả. Hãy tưởng tượng bạn đang cần phát triển hệ thống thương mại điện tử, hệ thống này bao gồm 2 thành phần:

  1. Phân hệ web cho phép người dùng tìm kiếm hàng hoá, và đặt hàng
  2. Phân hệ quản lý đơn hàng, cho phép kiểm duyệt, quản lý và thanh toán đơn hàng

Vậy có những cách nào để kết nối 2 phân hệ này với nhau? Cách 1: Xây dựng 2 hệ thống cho 2 phân hệ và gọi đến nhau thông quan REST Api

Ưu điểm:
  • Tách biệt được 2 hệ thống, phân hệ này bị tèo không ảnh hưởng đến phân hệ kia
  • Cài đặt đơn giản, không đòi hỏi nhiều kiến thức
Nhược điểm:
  • Việc sử dụng HTTP là tương đối nặng nề và chậm, đòi hỏi phần cứng phải có cấu hình cao
  • Khi phân hệ quản lý đơn hàng bị tèo thì chỉ có cách là thông báo "hệ thống đang có lỗi" cho người dùng điều này làm ảnh hưởng nghiêm trọng đến trải nghiệm người dùng

Vậy có cách nào để khắc phục được 2 nhược điểm kể trên? Đó chính là lúc chúng ta cần đến Message Queue

Mục tiêu ra đời

MQ ra đời với các mục tiêu sau:

  1. Tạo ra một dịch vụ có khả năng lưu trữ được các #Message (các message này có thể là request, hay bất kì loại data nào) để trong trường hợp một server xử lý bị lỗi thì Message vẫn tồn tại và không bị mất đi, để khi server xử lý được khôi phục, hệ thống lại tiếp tục trở lại bình thường
  2. Tạo ra một giao thức cho phép xác nhận được một message đã được gửi nhận thành công hay chưa để tối ưu bài toán Two Generals' Problem
  3. Tạo ra một service có khả năng điều phối message từ đó có thể thay thế được các service cân tải như nginx hay các #loadbalancer khác
  4. Tổ chức message thành cách #channel từ đó có thể chuyên muôn hoá việc xử lý các message và thuận tiện cho người sử dụng
  5. Đảm bảo các message nhận được theo thứ tự, từ đó giải quyết bài toán #concurrent # Vậy với MQ thì chúng ta sẽ có cách 2 cho bài toán thương mại điện tử. Cách 2: Xây dựng thành một hệ thống kết nối 2 thành phần với nhau thông qua Message Queue Broker
    • Ưu điểm:
    • Tách biệt được 2 hệ thống, phân hệ này bị tèo không ảnh hưởng đến phân hệ kia
    • Cài đặt đơn giản, không đòi hỏi nhiều kiến thức
    • Tốc độ gửi nhận nhah hơn so với HTTP
    • Khi phân hệ quản lý đơn hành bì tèo thì người dùng vẫn có thể đặt hàng thành công
    • Nhược điểm:
    • Trong các bài toán gọi #RPC MQ lại tương đối chậm, cái này mình sẽ nói ở bài khác nhé
    • Không dễ để triển khai, cái này mình cũng sẽ nói trong bài khác nhé

Kết luận

MQ thực sự là rất hay ho, là một giải pháp mạnh mẽ cho những ai muốn làm hệ thống lớn, những hệ thống siêu to khổng lồ. Nó phù hợp cho việc kết nối cách thành phần trong hệ thống với nhau, đảm bảo sự tách biệt các thành phần nghiệp vụ và nếu bạn đang làm những hệ thống đòi hỏi sự chuyên biệt như thương mại điện tử, hãy dùng MQ đi nhé, 🙂. Đây là 1 bài lý thuyết để mở ra cho loạt bài về #RabbitMQ, #ActiveMQ và #Kafka nhé mọi người, 🙂

Tham khảo:

  1. wiki
  2. Two Generals Problem