-
Design Pattern
- Singleton Design Pattern
- Factory Design Pattern
- Factory Method Design Pattern
- Abstract Factory Design Pattern
- Builder Design Pattern
- Prototype Design Pattern
- Object Pool Design Pattern
- Chain of Responsibility Design Pattern
- Command Design Pattern
- Interpreter Design Pattern
- Iterator Design Pattern
- Mediator Design Pattern
- Memento Design Pattern
- Observer Design Pattern
- Observer Design Pattern - Xử Lý Exception
- Strategy Design Pattern
- Template Method Design Pattern
- Visitor Design Pattern
- Null Object Design Pattern
- Adapter Design Pattern
- Bridge Design Pattern
- Composite Design Pattern
- Decorator Design Pattern
- Flyweight Design Pattern
- Proxy Design Pattern
- S.O.L.I.D
- Clean code
- Lập trình socket
- Java Core
- Multi-Thread
- Spring
- Java Web
- Memory Caching
- Message Queue
- DevOps
- Xây dựng một nền tảng
- MongoDB
- MySQL timestamp
- Properties vs yaml
- Kotlin
- Lập Trình Machine Learning với PyTorch
- Mã Nguồn Mở
- Ezy HTTP
- Free Chat
- Một số kinh nghiệm với Git
- Review cho đồng nghiệp!
- Setup Dev Environment
- Hello World
- Create a Server Project
- Handle Client Requests
- Using ezyfox-server-csharp-client
- Using ezyfox-es6-client
- Client React.js Interaction
- Build And Deploy In Local

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:
- Phân hệ web cho phép người dùng tìm kiếm hàng hoá, và đặt hàng
- 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:
- 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
- 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
- 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
- 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
- Đả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:
-
Design Pattern
- Singleton Design Pattern
- Factory Design Pattern
- Factory Method Design Pattern
- Abstract Factory Design Pattern
- Builder Design Pattern
- Prototype Design Pattern
- Object Pool Design Pattern
- Chain of Responsibility Design Pattern
- Command Design Pattern
- Interpreter Design Pattern
- Iterator Design Pattern
- Mediator Design Pattern
- Memento Design Pattern
- Observer Design Pattern
- Observer Design Pattern - Xử Lý Exception
- Strategy Design Pattern
- Template Method Design Pattern
- Visitor Design Pattern
- Null Object Design Pattern
- Adapter Design Pattern
- Bridge Design Pattern
- Composite Design Pattern
- Decorator Design Pattern
- Flyweight Design Pattern
- Proxy Design Pattern
- S.O.L.I.D
- Clean code
- Lập trình socket
- Java Core
- Multi-Thread
- Spring
- Java Web
- Memory Caching
- Message Queue
- DevOps
- Xây dựng một nền tảng
- MongoDB
- MySQL timestamp
- Properties vs yaml
- Kotlin
- Lập Trình Machine Learning với PyTorch
- Mã Nguồn Mở
- Ezy HTTP
- Free Chat
- Một số kinh nghiệm với Git
- Review cho đồng nghiệp!
- Setup Dev Environment
- Hello World
- Create a Server Project
- Handle Client Requests
- Using ezyfox-server-csharp-client
- Using ezyfox-es6-client
- Client React.js Interaction
- Build And Deploy In Local