Nếu Kafka mất tin nhắn hãy tập trung 3 giai đoạn này - Vũ khí backend năm tới

Nội dung bài viết

Video học lập trình mỗi ngày

Bài viết được vào Series: Vũ khí của một backend 2025

Khi tìm hiểu công nghệ, chúng ta nên chú ý nắm bắt bản chất, tính bất biến và khả năng tái sử dụng của công nghệ. Phương pháp không hề thay đổi, nhưng mục đích tại mõi thời điềm thì sẽ thay đổi.

Tôi nghĩ chúng ta nên có một bài viết vào mỗi năm để tổng kết lại những task công nghệ nào nên focus cho từng năm thì có lẽ tuyệt hơn. Mỗi năm sẽ review lại thêm bớt những công nghệ nhằmtránh bình cũ rượu mới..

Tôi mới tìm hiểu MessageQueue thì tìm hiểu ở đâu?

Bạn mới bắt đầu tìm hiểu về backend architecture ? Bạn mới tìm hiểu về message queue hoặc hệ thống của tôi nên thay đổi về phân tán thì bạn có thể tham khảo tại đây.

Kịch bản nào sử dụng rabbitMQ or Kafka

Một bài viết đủ hiểu về kafka cho người bắt đầu

Một bài viết đủ hiểu về RabbitMQ cho người bắt đầu

Đó thực sự là những bài giúp bạn nhanh chóng hiểu vê kiến trúc Message Queue là gì?

Kafka dùng để làm gì?

Ngày xưa kafka sinh ra ban đầu được thiết kế với mục đích để xử lý số lượng lớn log (nhật ký). Ví dụ

function getUserData({userId = 0}){
    try{
        log.info("Params:", userId); // Log...
        TopicPartition topicPartition = new TopicPartition(record.topic(), record.partition());
    }catch(e){

    }finally{

    }
}

Cũng trong ngày xưa, để đạt hiệu suất cao nhất thì những đại ca sẽ hy sinh nhiều tính năng trong thiết kế kiến trúc, vi dụ: độ tin cậy (reliability) không được đảm bảo, messages có thể bị mất, clusters lúc đó không được support. Vì vậy lúc đó việc sử dụng cho log có thể là phù hợp ngay tại thời điểm đó.

Rồi bây giờ sao? Bây giờ hầu như đã có những phần bù đắp cho những thiếu sót, nhưng trong tâm trí của những Lập trình viên đi trước thì đến giờ nó cũng phù hợp cho việc distributed logs, ngoài ra còn có sử dụng vào những việc như đồng bộ data, nhưng hiện tượng mất message, or bị duplicate message vẫn xảy ra.

Ba trường hợp sử dụng Message Queue đúng nhất và đúng bản chất

Kafka bị mất message khi nào?

Thật ra chỉ có những hệ thống nào đã sử dụng kafka hay rabbitMQ mới có thể đúc kết được những trường hợp nào bị mất. Tôi có thể tóm tắt như sau, chứ thực tế lần mò nó rât phức tạp.

  • Phản hồi từ khách hàng or system: Tại sao hôm nay tôi không nhận được email thông báo đơn hàng
  • Giám sát(monitoring): Sự bất thường của Cluster, Broker tự dưng ngưng hoạt động lúc 3h15 đến 3h20...

Vì vậy, cố găng làm quen với các giai đoạn của một message từ producer to consumer, không thể thiếu một hệ thống giám sát như prometheus vs grafana nếu bạn chưa tìm hiều về giám sát CPU, Mysql thì có thể để ý rằng, có những link đính kèm bạn có thể tham quan nó.

Thực tế tôi thấy nếu bạn áp dụng kiến trúc Kafka, chủ yếu 3 phần: Producer, Broker, Consumer. Thì từ producer đến consumer có thể chia ra ba giai đoạn, đó là

  • new message()
  • message.save()
  • message.done()

Cụ thể hơn thì tôi cũng đã từng triển khai về những trường hợp này, và tôi nói qua đây cho anh chị nắm lại

  • Giai đoạn tạo message: Trong giai đoạn này, thông qua đường truyền mạng (network) thì message từ Producer và Consumer sẽ vận chuyển qua đây.
  • Giai đoạn Store : Trong giai đoạn này, message được lưu trữ ở phía Producer. Nếu là cụm, message sẽ được sao chép sang các bản sao khác trong giai đoạn này.
  • Giai đoạn Consumer : Trong giai đoạn này, Consumer lấy message từ Producer và gửi chúng đến Consumer thông qua đường truyền mạng(network).

Làm thế nào để đảm bảo message không bị mất sau này chủ yếu được phân tích từ ba giai đoạn này, hãy chú ý nó một cách cẩn thận. Chỉ khi nào bạn thực sự sử dụng nó thì mới thấy 3 giai đoạn này là vô cùng quan trọng.

Nhận thức

Không có gì là tuyệt đối, mọi trường hợp về rủi ro đếu có thể xảy ra trong cuộc sống lần phần mềm. Và chỉ có nhận thức ảnh hưởng đến thái độ và thái độ quyết định mọi thứ.

Từ lập trình đến cuộc sống bạn có thể theo dõi tại đây: Con đường đến với kỹ sư phần mềm

Có thể bạn đã bị missing