Trong bối cảnh các hệ thống phân tán ngày nay, môi giới tin nhắn (Message Broker) giữ vai trò rất quan trọng trong việc truyền tải dữ liệu giữa các thành phần của ứng dụng. Tuy nhiên, việc đảm bảo tính nhất quán và độ tin cậy trong những hệ thống này luôn là thách thức lớn. Trong bài viết này, chúng ta sẽ cùng khám phá những vấn đề cơ bản và những giải pháp khả thi để nâng cao tính ổn định và hiệu suất của hệ thống môi giới tin nhắn.
1. Tính Nhất Quán trong Hệ Thống Message Broker
Hệ thống môi giới tin nhắn cần đảm bảo tính nhất quán dữ liệu, giúp cho tất cả các thành phần trong hệ thống có cái nhìn đồng bộ và chính xác về dữ liệu.
1.1 Đảm Bảo Số Lượng Tin Nhắn Nhất Quán
Một trong những mối quan tâm chính là việc giao và nhận tin nhắn một cách đồng đều. Ảnh hưởng từ lỗi mạng hoặc sự cố hệ thống có thể dẫn đến việc mất hoặc trùng lặp tin nhắn. Để khắc phục vấn đề này, nhiều hệ thống tiền nhiệm đã hiện thực hóa các tính năng như:
- Xác Nhận (ACKs): Người nhận phải gửi lại xác nhận sau khi nhận được tin nhắn để đảm bảo tin nhắn đã được tiếp nhận thành công.
- Tái Thử: Cung cấp cơ chế tự động gửi lại những tin nhắn chưa gửi hoặc đã mất.
1.2 Đảm Bảo Tính Nhất Quán Dữ Liệu
Tính nhất quán dữ liệu giữa nhiều broker trong các môi trường phân tán có thể gặp khó khăn, đặc biệt trong những tình huống đồng thời cao. Một số kỹ thuật đã được sử dụng để đạt được mục tiêu này, bao gồm:
- Sao Chép Dữ Liệu: Tạo nhiều bản sao dữ liệu trên các broker khác nhau, giúp đảm bảo rằng nếu một broker gặp lỗi, dữ liệu vẫn có thể lấy từ broker khác.
- Giao Thức Đồng Thuận: Sử dụng các giao thức như Paxos hay Raft để chắc chắn rằng tất cả broker đều đồng nhất về trạng thái hệ thống.
2. Độ Tin Cậy trong Hệ Thống Message Broker
Độ tin cậy của một hệ thống môi giới tin nhắn phản ánh khả năng của nó trong việc duy trì hoạt động bình thường ngay cả khi có sự cố xảy ra. Một số yếu tố quyết định độ tin cậy bao gồm:
2.1 Khả Năng Tự Phục Hồi
Hệ thống đáng tin cậy cần có khả năng phục hồi sau khi gặp lỗi. Một số giải pháp để nâng cao khả năng tự phục hồi gồm:
- Cơ Chế Chuyển Đổi Lỗi (Failover): Tự động chuyển sang một broker phụ nếu broker chính gặp vấn đề.
- Kiểm Tra Sức Khỏe: Theo dõi trạng thái của broker nhằm phát hiện sớm và xử lý các vấn đề trước khi chúng gây ảnh hưởng nghiêm trọng đến hệ thống.
2.2 Tính Mở Rộng
Để đáp ứng nhu cầu gia tăng mà không làm giảm độ tin cậy, hệ thống cần được thiết kế với tính mở rộng. Các giải pháp có thể bao gồm:
- Mở Rộng Ngang: Thêm nhiều broker vào hệ thống để phân phối tải và cải thiện hiệu suất.
- Cân Bằng Tải: Phân phối các tin nhắn đều giữa các broker nhằm tránh tình trạng quá tải.
3. Vấn Đề Tin Nhắn Lặp Lại trong Hệ Thống Message Broker
3.1 Bối Cảnh
Xem xét hệ thống Google Pub/Sub, cấu hình như sau:
gcloud pubsub topics create $TOPIC_ID --project=$PROJECT_ID
gcloud alpha pubsub subscriptions create $SUBSCRIPTION_ID --topic=$TOPIC_ID --project=$PROJECT_ID \
--dead-letter-topic=$DEAD_LETTER_TOPIC_ID \
--dead-letter-topic-project=$PROJECT_ID \
--max-delivery-attempts=5 \
--ack-deadline=90 \
--message-retention-duration="7d" \
--min-retry-delay="10s" \
--max-retry-delay="20s" \
--expiration-period="never"Và một subscriber có cấu hình như sau:
java
public Subscriber.Builder configSubscriberBuilder(Subscriber.Builder builder){
FlowControlSettings flowControlSettings =
FlowControlSettings.newBuilder()
.setMaxOutstandingElementCount(500L)
.setMaxOutstandingRequestBytes(50L * 1024L * 1024L)
.build();
int cores = Runtime.getRuntime().availableProcessors();
int pullCount = 1;
int cpuUsed = cores/pullCount;
ExecutorProvider executorProvider =
InstantiatingExecutorProvider.newBuilder().setExecutorThreadCount(cpuUsed).build();
builder.setFlowControlSettings(flowControlSettings);
builder.setParallelPullCount(pullCount);
builder.setMaxAckExtensionPeriod(Duration.ofSeconds(30));
builder.setExecutorProvider(executorProvider);
return builder;
}Các tham số trên có ý nghĩa như sau:
- Sử dụng số lượng luồng tương ứng với số lượng luồng vật lý để xử lý tin nhắn.
- Số lượng tin nhắn được kéo sẽ được xác định bởi một trong hai điều kiện: (A) Tối đa 500 tin nhắn kéo; (B) Tổng kích thước của tất cả các tin nhắn nhỏ hơn 50MB.
ack-deadline=90có nghĩa là thời gian tối đa cho phép một tin nhắn được xác nhận là 90 giây. Khi một tin nhắn được gửi đến một Topic, nó sẽ được lấy và lưu trữ bởi các Subscription. Khi một ứng dụng kết nối với một Subscription, nó sẽ lấy các tin nhắn dựa trên cấu hình của Subscription và Subscriber, và giữ chúng trong một Message Container để xử lý dần dần.
Quá trình xử lý của dịch vụ B sẽ diễn ra như sau: Các tin nhắn sẽ được xử lý thông qua các cuộc gọi đến dịch vụ D, E và F. Khi quá trình hoàn tất, dịch vụ B sẽ gửi một xác nhận (ACK) đến đăng ký, chỉ ra rằng tin nhắn đã được xử lý thành công. Tuy nhiên, nếu tất cả các tin nhắn không thể được xử lý trong vòng 90 giây, 150 tin nhắn còn lại sẽ được thử lại trên dịch vụ B.
3.2 Lý Do
Nếu thời gian xử lý vượt quá 90 giây, những tin nhắn không được xác nhận sẽ được đưa trở lại để xử lý lại ít nhất một lần.
3.3 Một Số Giải Pháp
Để cải thiện hiệu suất và đảm bảo tính nhất quán:
- Kiểm thử tải: Duy trì tài nguyên bằng cách thực hiện kiểm thử tải trên các hàm xử lý tin nhắn nhằm định lượng thông lượng tối đa và cấu hình người đăng ký cho phù hợp.
- Đảm bảo tính idempotent: Triển khai cơ chế kiểm tra sự tồn tại của bản ghi trong các hàm được gọi bởi dịch vụ D, E và F, nhằm đảm bảo mỗi hành động chỉ thực thi một lần cho mỗi yêu cầu, ngay cả khi yêu cầu đó được gửi lại nhiều lần.
4. Kết Luận
Tính nhất quán và độ tin cậy là yếu tố then chốt để nâng cao hiệu suất và tính ổn định cho một hệ thống môi giới tin nhắn. Khi hiểu rõ và giải quyết những thách thức này, bạn sẽ có thể xây dựng các hệ thống phân tán mạnh mẽ, đáp ứng được yêu cầu của ứng dụng hiện đại. Đừng quên triển khai các thực tiễn và kỹ thuật tốt nhất để hệ thống hoạt động một cách hiệu quả và ổn định trong suốt thời gian dài. Nếu bạn có câu hỏi hoặc đóng góp nào, hãy để lại phản hồi dưới đây. Cảm ơn bạn đã đọc bài viết này và chúng tôi rất mong được kết nối thêm với bạn!
source: viblo
