Bối cảnh và vấn đề nghiên cứu

Sự bùng nổ của thương mại điện tử tại Việt Nam và trên thế giới, đặc biệt là giai đoạn chuyển dịch thói quen mua sắm trực tuyến sau đại dịch Covid-19, đã thúc đẩy sự tăng trưởng nhanh chóng của dịch vụ vận chuyển hàng hóa logistics. Trong hệ thống chuỗi cung ứng, việc theo dõi trạng thái và vị trí đơn hàng theo thời gian thực đóng vai trò trọng yếu đối với cả người nhận hàng, cửa hàng gửi hàng và đơn vị vận chuyển. Thông tin chính xác giúp tối ưu hóa tuyến đường, giảm thiểu thời gian giao hàng, hạn chế tỷ lệ thất lạc, hư hỏng và nâng cao chất lượng dịch vụ.

Các doanh nghiệp logistics lớn như Giao hàng tiết kiệm (GHTK), GHN, J&T Express thường cung cấp giao diện lập trình ứng dụng công khai (Public API) để khách hàng và đối tác truy vấn thông tin đơn hàng. Phương thức triển khai phổ biến hiện nay là API polling, trong đó phía đối tác chủ động gửi yêu cầu (HTTP request) liên tục lên máy chủ để kiểm tra trạng thái đơn hàng. Tuy nhiên, tác giả chỉ ra các hạn chế cố hữu của phương pháp này:

  • Lãng phí tài nguyên hệ thống và băng thông mạng khi thực hiện các yêu cầu lặp lại trong khi đơn hàng chưa phát sinh thay đổi trạng thái.
  • Không đáp ứng tính tức thời (real-time) nếu khoảng thời gian giữa các lần thăm dò quá dài, hoặc gây nghẽn hệ thống nếu tần suất gửi yêu cầu quá cao.
  • Không phù hợp với các đơn vị vận chuyển có quy mô lớn với hàng triệu khách hàng và đối tác cùng truy vấn đồng thời.

Để khắc phục hạn chế trên, giải pháp kỹ thuật được đặt ra là chuyển dịch từ mô hình kéo dữ liệu (API polling) sang mô hình đẩy dữ liệu tự động theo thời gian thực thông qua Webhook (Reverse API/Push API). Khi có sự kiện thay đổi dữ liệu đơn hàng, máy chủ sẽ tự động gửi HTTP POST request đến endpoint URL do đối tác đăng ký trước. Việc triển khai hệ thống Webhook chịu tải cao trong thực tế gặp phải ba bài toán kỹ thuật lớn:

  1. Cơ chế phát hiện dữ liệu thay đổi ở tầng cơ sở dữ liệu: Nếu can thiệp bằng cách chèn hàm gọi Webhook trực tiếp vào các hàm thay đổi dữ liệu của tầng ứng dụng (như Service xử lý đơn hàng), hệ thống sẽ gặp các nhược điểm nghiêm trọng: dễ phát sinh lỗi khi cập nhật logic, mã nguồn lặp lại gây khó bảo trì, tiêu tốn tài nguyên và hạn chế khả năng mở rộng.
  2. Đảm bảo độ tin cậy và thứ tự gửi thông điệp: Hệ thống đối tác có thể gặp sự cố gián đoạn (downtime), dẫn đến mất mát thông điệp nếu không có cơ chế lưu trữ đệm và gửi lại (retry). Đồng thời, thông tin trạng thái phải tuyệt đối bảo toàn thứ tự thời gian (ví dụ: không thể gửi trạng thái "Đã giao hàng" trước trạng thái "Đang giao hàng").
  3. Đáp ứng thông lượng xử lý cao (high throughput): Hệ thống phải giữ trạng thái sẵn sàng cao, xử lý hàng loạt tác vụ mạng I/O-bound đồng thời mà không làm nghẽn CPU hoặc gây chậm trễ cho các dịch vụ nghiệp vụ nội bộ.

Mục tiêu của khóa luận là xây dựng một hệ thống theo dõi đơn hàng tự động hoàn toàn bằng Webhook, cập nhật dữ liệu thời gian thực, có khả năng chịu tải cao và đáp ứng lượng thông lượng lớn. Chỉ tiêu thông lượng mục tiêu đặt ra là tối thiểu 250 request/giây, tương đương xấp xỉ 3.600.000 request/ngày gửi đến các đối tác.

Đối tượng nghiên cứu của khóa luận là quy trình vận chuyển, vòng đời trạng thái đơn hàng trong logistics và các công nghệ xử lý dữ liệu phân tán. Phạm vi nghiên cứu tập trung vào luồng dữ liệu từ cơ sở dữ liệu nguồn của đơn vị vận chuyển (lấy mô hình nghiệp vụ thực tế của công ty Giao hàng tiết kiệm) đến các đối tác thương mại điện tử (như sàn Shopee và các cửa hàng kinh doanh).

Cơ sở lý thuyết và phương pháp

Khóa luận thiết lập nền tảng nghiên cứu dựa trên các khái niệm, công nghệ và khung lý thuyết kỹ thuật phần mềm phân tán:

  • Công nghệ Webhook: Mô hình giao tiếp HTTP bất đồng bộ giữa máy chủ và máy trạm theo kiến trúc hướng sự kiện, thay thế cơ chế API polling truyền thống.
  • Message Broker và Apache Kafka: Khảo sát hai mô hình điều hướng thông điệp gồm Point-to-point (điểm-điểm) và Publish/Subscribe (phát hành/đăng ký). Tác giả so sánh hai nhóm Message Broker chính: nhóm hướng thông điệp (Message-based như RabbitMQ, ActiveMQ) và nhóm đường ống dữ liệu (Data pipeline như Apache Kafka).
Tiêu chí Message Base (RabbitMQ, ActiveMQ) Data Pipeline (Apache Kafka)
Lưu trữ sau khi tiêu thụ Thông điệp bị xóa khỏi hàng đợi sau khi consumer nhận Thông điệp vẫn được lưu lại trên đĩa trong nhiều ngày (mặc định 7 ngày)
Quản lý trạng thái Consumer Lưu trạng thái của consumer để đảm bảo nhận thông điệp Không lưu trạng thái consumer trên hàng đợi; consumer tự quản lý vị trí đọc qua offset
Cơ chế đọc dữ liệu Consumer chỉ nhận được một thông điệp mới nhất khi đẩy vào Consumer có thể lấy thông điệp tùy ý theo batch, đọc lại thông điệp cũ hoặc mới

Khóa luận chọn Apache Kafka làm nền tảng xử lý dữ liệu phân tán nhờ khả năng chịu lỗi, lưu trữ bền vững trên cụm broker, cơ chế phân vùng (partition) song song, công cụ Kafka Connect và quản lý bản sao (replication factor).

  • Kỹ thuật Change Data Capture (CDC): Phân tích ba phương pháp bắt biến động dữ liệu từ cơ sở dữ liệu nguồn sang hệ thống phân tích/xử lý: Trigger-based (dùng trigger ghi log DML, gây giảm hiệu năng DB), Timestamps-based (dựa vào cột thời gian sửa đổi, thiếu chính xác và không nhận biết bản ghi bị xóa), và Log-based (đọc trực tiếp transaction log/binlog của hệ quản trị cơ sở dữ liệu, không tiêu tốn tài nguyên xử lý câu lệnh SQL). Tác giả chọn Log-based CDC thông qua công cụ Debezium.
  • Lý thuyết Concurrency cho tác vụ I/O-bound: Phân biệt chương trình CPU-bound và I/O-bound. Tác vụ gửi Webhook qua mạng là I/O-bound điển hình; do đó, các kỹ thuật xử lý đồng thời như Asynchronous I/O, Multithreading và Parallel processing được áp dụng để CPU không bị rảnh rỗi trong lúc chờ phản hồi mạng (network latency).
  • Hạ tầng đóng gói và quan sát: Ảo hóa container bằng Docker và Docker-compose; ngăn xếp ELK (Elasticsearch, Logstash, Kibana) phục vụ tập trung và phân tích response log; bộ công cụ giám sát thời gian thực gồm Prometheus, Grafana và Exporter.

Phương pháp nghiên cứu kết hợp giữa phân tích kiến trúc lý thuyết, thiết kế hệ thống phần mềm hướng module hóa và phương pháp thực nghiệm đo kiểm hiệu năng (benchmarking) trên môi trường ảo hóa container.

Thiết kế và triển khai

Hệ thống được thiết kế thành một kiến trúc phân tán gồm hai phân hệ chính kết nối thông qua cụm trung gian Apache Kafka:

  1. Phân hệ nắm bắt sự thay đổi dữ liệu (CDC System):
    • Tận dụng file binlog của hệ quản trị cơ sở dữ liệu MySQL.
    • Triển khai Debezium Source Connector hoạt động trên nền tảng Kafka Connect để theo dõi liên tục các giao dịch INSERT, UPDATE trên cơ sở dữ liệu nghiệp vụ đơn hàng.
    • Debezium tự động chuẩn hóa dữ liệu thay đổi thành thông điệp định dạng JSON chứa cấu trúc metadata (thông tin trước và sau khi thay đổi) rồi gửi vào các topic của Kafka.
  2. Phân hệ xử lý Webhook (Webhook Processing System):
    • Xây dựng các worker chạy dưới dạng Consumer Group đọc thông điệp từ các partition của Kafka topic.
    • Xử lý nghiệp vụ: bóc tách dữ liệu JSON, lọc các trường thông tin tương ứng với cấu hình đăng ký của từng đối tác cụ thể.
    • Áp dụng các thư viện xử lý đồng thời (concurrency) để gửi các HTTP POST request đồng thời tới endpoint của đối tác và tiếp nhận response trả về.

Lược đồ cơ sở dữ liệu quan hệ được thiết kế gồm 6 bảng thực thể nghiệp vụ phục vụ quản lý logistics:

  • packages: Lưu trữ thông tin chi tiết bưu kiện, mã đơn hàng, trạng thái hiện tại, trọng lượng, kích thước.
  • shops: Quản lý thông tin tài khoản của các cửa hàng, đối tác gửi hàng và endpoint webhook đăng ký.
  • stations: Thông tin các kho, trạm bưu cục trung chuyển trong mạng lưới giao nhận.
  • customers: Thông tin người nhận hàng (họ tên, số điện thoại liên hệ).
  • addresses: Dữ liệu địa chỉ chi tiết của người gửi và người nhận.
  • cods: Thông tin về tiền thu hộ, phí bảo hiểm và đối soát công nợ.

Để giải quyết bài toán thông lượng và tính toàn vẹn dữ liệu, các cơ chế kỹ thuật cụ thể đã được cài đặt:

  • Bảo toàn thứ tự thông điệp: Định danh mã đơn hàng làm message key khi ghi vào Kafka. Cơ chế băm (hash algorithm) của Kafka đảm bảo mọi sự kiện thay đổi của cùng một đơn hàng luôn được định tuyến vào đúng một partition duy nhất, triệt tiêu nguy cơ xáo trộn thứ tự cập nhật trạng thái.
  • Chính sách phân loại ưu tiên thông điệp (Priority Queue): Phân chia thông điệp thành các topic với mức độ ưu tiên khác nhau dựa trên mã trạng thái nghiệp vụ (các trạng thái quan trọng như hủy đơn, giao thành công được định tuyến vào luồng ưu tiên). Ứng dụng Redis làm bộ nhớ đệm (caching) để giảm tải các phép tính toán lặp lại và kiểm tra trạng thái thông điệp.
  • Đảm bảo tính sẵn sàng và tin cậy: Cấu hình mức độ xác nhận acks=1 hoặc acks=all, thiết lập replication.factor = 3 trên cụm Kafka brokers để tránh mất mát dữ liệu khi có node gặp sự cố. Cài đặt luồng Dead Letter Queue và cơ chế retry có kiểm soát đối với các request gửi sang đối tác bị lỗi 5xx hoặc timeout, đảm bảo không bỏ sót thông tin sau khi đối tác phục hồi.

Toàn bộ hệ thống gồm MySQL, Kafka, Zookeeper, Kafka Connect (Debezium), Redis, Webhook Workers, ELK Stack và Prometheus/Grafana được triển khai độc lập và liên kết thông qua Docker Network.

Nội dung chính theo từng chương

Chương 1: Giới thiệu

Chương 1 thiết lập bài toán nghiên cứu dựa trên bối cảnh logistics trong thời kỳ bùng nổ thương mại điện tử. Tác giả phân tích cơ chế và nhược điểm của kỹ thuật API polling truyền thống, so sánh với mô hình Webhook. Chương này xác định rõ các yêu cầu phi chức năng của hệ thống gồm: khả năng chịu tải cao, đảm bảo thứ tự dữ liệu, bảo toàn thông điệp khi đối tác gặp sự cố, và mục tiêu thông lượng tối thiểu 250 request/giây (tương đương 3,6 triệu request/ngày). Cuối chương trình bày phạm vi nghiên cứu và bố cục tổng thể của khóa luận.

Chương 2: Cơ sở lý thuyết

Chương 2 trình bày chi tiết các cơ sở lý thuyết công nghệ được tích hợp trong hệ thống:

  • Bản chất stateless và cơ chế push của Webhook.
  • Kiến trúc Apache Kafka: phân biệt Point-to-point và Publish/Subscribe; chi tiết cấu trúc Topic, Broker, Cluster, Partition, Offset; các chính sách xác nhận gửi tin (acks=0, acks=1, acks=all); cơ chế mở rộng thông lượng bằng Consumer Group và quá trình cân bằng tải (rebalance); các chiến lược commit offset (At most once, At least once, Exactly once); cơ chế sao lưu dữ liệu với Leader/Follower replica và vai trò điều phối của Zookeeper; thành phần kết nối Kafka Connect (Connector, Task, Worker).
  • Cơ chế Change Data Capture (CDC): vai trò của CDC trong quy trình ETL (Extract, Transform, Load); phân tích so sánh ba phương pháp bắt thay đổi dữ liệu (Log-based, Trigger-based, Timestamps-based).
  • Xử lý đồng thời (Concurrency): bản chất nghẽn I/O (I/O-bound) trong tác vụ Webhook và các kỹ thuật tối ưu hóa qua Asynchronous I/O, Multithreading và Parallel processing.
  • Hạ tầng bổ trợ: công nghệ ảo hóa container Docker và Docker-compose; quy trình thu thập, lập chỉ mục và phân tích response log với ELK Stack (Elasticsearch, Logstash, Kibana); quy trình giám sát hệ thống với Prometheus, Grafana và Exporter.

Chương 3: Giải pháp xây dựng hệ thống theo dõi đơn hàng tự động với lượng throughput lớn

Chương 3 tập trung vào thiết kế giải pháp kỹ thuật cụ thể:

  • Khảo sát quy trình 8 bước trong vòng đời đơn hàng tại GHTK (từ đăng đơn, chờ lấy hàng, lấy hàng, nhập kho trung tâm, vận chuyển, giao hàng, lưu kho/hoàn hàng, đến đối soát công nợ). Chuẩn hóa bảng mã 15 trạng thái đơn hàng của hệ thống.
Mã trạng thái Diễn giải trạng thái nghiệp vụ
-1 Hủy đơn hàng
1 Chưa tiếp nhận
2 Đã tiếp nhận
3 Đã lấy hàng / Đã nhập kho
4 Đã điều phối giao hàng / Đang giao hàng
5 Đã giao hàng / Chưa đối soát
6 Đã đối soát
7 Không lấy được hàng
8 Hoãn lấy hàng
9 Không giao được hàng
10 Hoãn giao hàng
11 Đã đối soát công nợ trả hàng
12 Đã điều phối lấy hàng / Đang lấy hàng
13 Đơn hàng bồi hoàn
20 Đang trả hàng (COD cầm hàng đi trả)
21 Đã trả hàng (COD đã trả xong hàng)
  • Xây dựng hệ thống CDC: Phân tích lược đồ cơ sở dữ liệu gồm 6 bảng (packages, shops, stations, customers, addresses, cods); cài đặt Debezium kết nối MySQL binlog; chuẩn hóa cấu trúc dữ liệu JSON đầu ra của Debezium.
  • Xây dựng hệ thống xử lý Webhook: Thực hiện thử nghiệm đối sánh thực nghiệm giữa 3 module xử lý đồng thời trong Python (threading, asyncio, multiprocessing) khi gửi lượng lớn HTTP request để chọn giải pháp tối ưu cho tác vụ I/O-bound. Xây dựng biểu đồ tuần tự cho luồng xử lý thông điệp và cơ chế gửi lại khi hệ thống đối tác gặp lỗi.
  • Xây dựng giải pháp ưu tiên thông điệp: Thiết kế phân tách topic theo độ ưu tiên nghiệp vụ và ứng dụng Redis để tối ưu hóa việc kiểm tra tính toán lặp lại.

Chương 4: Cài đặt và kết quả thực nghiệm

Chương 4 mô tả quá trình triển khai thực tế trên môi trường Docker. Tác giả thiết lập cụm Kafka, các worker xử lý và cấu hình máy chủ thử nghiệm (ghi nhận chi tiết thông số phần cứng CPU và bộ nhớ RAM). Quá trình đo kiểm thông lượng được thực hiện qua việc tạo tải, phân tích response log bằng ELK Stack và theo dõi trạng thái thông điệp trong Kafka qua Grafana, Prometheus và Exporter. Chương này trình bày các biểu đồ tương quan giữa số lượng request/giây với:

  • Tỷ lệ response thành công và số lượng thông điệp trễ (message lag).
  • Mức độ chiếm dụng tài nguyên CPU của hệ thống.
  • Mức độ sử dụng bộ nhớ RAM của hệ thống máy chủ.

Kết quả và đóng góp

Khóa luận đã hoàn thành các mục tiêu kỹ thuật đặt ra với các kết quả cụ thể:

  • Xây dựng thành công hệ thống Webhook hoàn chỉnh: Hệ thống vận hành tự động từ khâu bắt biến động dữ liệu tại MySQL bằng Debezium, truyền dẫn qua Apache Kafka, đến các worker gửi thông báo HTTP POST thời gian thực đến đối tác.
  • Tối ưu hóa hiệu năng tầng cơ sở dữ liệu: Việc ứng dụng giải pháp Log-based CDC giúp tách rời hoàn toàn tác vụ tracking ra khỏi mã nguồn ứng dụng nghiệp vụ lõi, không làm phát sinh truy vấn DML phụ như Trigger, giảm thiểu tải xử lý cho cơ sở dữ liệu chính.
  • Đạt chỉ tiêu thông lượng xử lý cao: Kết quả đo kiểm thực nghiệm xác nhận hệ thống duy trì khả năng xử lý ổn định ở mức thông lượng mục tiêu 250 request/giây (tương đương 3,6 triệu request/ngày), đảm bảo tỷ lệ phản hồi thành công cao và kiểm soát độ trễ thông điệp trong ngưỡng cho phép.
  • Đảm bảo tính tin cậy và tính tuần tự: Ứng dụng cơ chế message key trên partition của Kafka giúp bảo toàn 100% thứ tự các trạng thái chuyển tiếp của từng đơn hàng. Thiết kế cơ chế retry và lưu trữ đệm giải quyết triệt để vấn đề mất mát dữ liệu khi hệ thống đối tác xảy ra downtime tạm thời.
  • Đóng góp về mặt giải pháp kỹ thuật: Đưa ra một mô hình kiến trúc tham chiếu hoàn chỉnh cho bài toán tracking phân tán trong ngành logistics tại Việt Nam; cung cấp dữ liệu đánh giá thực nghiệm rõ ràng về việc ứng dụng concurrency trong tối ưu hóa tác vụ mạng I/O-bound.

Hạn chế và hướng nghiên cứu tiếp

Dựa trên phạm vi và nội dung triển khai, tác giả chỉ ra các hạn chế và hướng mở rộng:

  • Hạn chế: Các kịch bản thử nghiệm tải chủ yếu được thực hiện trên môi trường đóng gói container cục bộ (Docker trên một máy chủ phần cứng cố định), chưa phản ánh toàn diện các yếu tố bất định của hạ tầng mạng diện rộng (WAN) hoặc cụm máy chủ phân tán đa vùng (multi-region cloud infrastructure). Cơ chế retry khi đối tác downtime kéo dài cần thêm các thuật toán backoff phức tạp hơn để tránh dồn ứ hàng đợi.
  • Hướng nghiên cứu tiếp:
    • Nghiên cứu chuyển đổi mô hình triển khai từ Docker-compose sang nền tảng điều phối cụm Kubernetes (K8s) nhằm tự động co giãn số lượng worker (Horizontal Pod Autoscaler) linh hoạt theo lưu lượng tải thực tế.
    • Tích hợp các giải thuật kiểm soát lưu lượng nâng cao (rate limiting) theo từng endpoint đối tác để tránh làm quá tải các hệ thống nhận tin có năng lực chịu tải thấp.

Giá trị tham khảo

Khóa luận có giá trị tham khảo rõ ràng trong nghiên cứu và ứng dụng thực tiễn:

  • Đối tượng tham khảo: Sinh viên, học viên chuyên ngành Công nghệ thông tin, Kỹ thuật phần mềm; các kỹ sư phần mềm làm việc trong lĩnh vực phát triển hệ thống backend, kiến trúc hướng sự kiện (Event-Driven Architecture) và hệ thống phân tán phục vụ thương mại điện tử, logistics.
  • Nội dung giá trị nhất:
    • Bảng chuẩn hóa quy trình và 15 mã trạng thái vận đơn thực tế của Giao hàng tiết kiệm tại Chương 3.
    • Hướng dẫn thiết kế và kết nối kỹ thuật Log-based CDC sử dụng Debezium và Kafka Connect để trích xuất dữ liệu không xâm lấn.
    • Phương pháp phân tích, đối sánh hiệu năng các module xử lý đồng thời (threading, asyncio, multiprocessing) cho bài toán I/O-bound tải cao.

Câu hỏi thường gặp

1. Tại sao khóa luận lựa chọn kỹ thuật Log-based CDC (Debezium) thay vì phương pháp Trigger-based hay hook hàm trực tiếp trong mã nguồn ứng dụng?

Phương pháp hook hàm trực tiếp trong tầng ứng dụng (như Service xử lý đơn hàng) gây lặp mã, khó bảo trì, dễ lỗi khi sửa đổi logic và tốn tài nguyên hệ thống. Phương pháp Trigger-based tuy tự động nhưng làm giảm hiệu năng cơ sở dữ liệu do phải thực thi các câu lệnh DML bổ sung và tạo thêm bảng log cồng kềnh. Khóa luận chọn Log-based CDC với Debezium vì cơ chế này đọc trực tiếp transaction log (binlog của MySQL), giúp phát hiện thay đổi tức thì mà hoàn toàn không can thiệp vào mã nguồn ứng dụng và không làm suy giảm hiệu năng của cơ sở dữ liệu nguồn.

2. Hệ thống làm thế nào để đảm bảo tính tuần tự của các trạng thái đơn hàng trong môi trường xử lý phân tán?

Trong Apache Kafka, thứ tự thông điệp chỉ được đảm bảo tuyệt đối trong phạm vi của từng partition riêng lẻ. Hệ thống giải quyết bài toán này bằng cách sử dụng mã đơn hàng làm message key. Kafka sẽ băm (hash) key này để đưa toàn bộ các thông điệp có cùng mã đơn hàng vào chung một partition trên broker. Khi đó, consumer sẽ đọc và xử lý các thông điệp theo đúng tuần tự offset, ngăn chặn hiện tượng gửi trạng thái "Đã giao hàng" trước trạng thái "Đang giao hàng".

3. Thông lượng (throughput) mục tiêu của hệ thống là bao nhiêu và tác giả đã sử dụng những công cụ nào để đo lường, giám sát?

Thông lượng mục tiêu mà khóa luận đặt ra là tối thiểu 250 request/giây, tương đương xấp xỉ 3.600.000 request/ngày. Để đo lường và giám sát, tác giả sử dụng ngăn xếp ELK (Logstash thu thập và chuẩn hóa response log, Elasticsearch lưu trữ và lập chỉ mục, Kibana trực quan hóa số lượng response thành công/thất bại) kết hợp cùng Prometheus (thu thập metric hệ thống và metric Kafka qua Exporter) và Grafana (trực quan hóa tài nguyên CPU, RAM và message lag).

4. Hệ thống xử lý như thế nào khi endpoint Webhook của đối tác bị gián đoạn hoạt động (downtime)?

Do HTTP là giao thức phi trạng thái (stateless), nếu gửi thông báo trực tiếp khi đối tác gặp sự cố thì thông điệp sẽ bị mất hoàn toàn. Hệ thống khắc phục tình trạng này bằng cách sử dụng Kafka làm bộ đệm trung gian lưu trữ thông điệp (với thời gian lưu trữ mặc định là 7 ngày). Khi worker gửi HTTP request và nhận về lỗi (hoặc timeout), thông điệp sẽ được chuyển vào cơ chế retry hoặc hàng đợi chuyên biệt để gửi lại khi hệ thống đối tác hoạt động trở lại bình thường.

5. Trong kiến trúc Kafka của khóa luận, tham số sao lưu (replication factor) được thiết lập là bao nhiêu và nhằm mục đích gì?

Tác giả thiết lập tham số replication.factor = 3. Cấu hình này nhân bản dữ liệu của mỗi partition thành 3 bản sao nằm trên các broker khác nhau (gồm 1 Leader replica và 2 Follower replica). Thiết lập này giúp hệ thống đạt độ sẵn sàng cao, đảm bảo dữ liệu không bị mất mát khi một broker gặp sự cố, đồng thời giữ mức sử dụng dung lượng lưu trữ ở mức cân bằng, không gây quá tải bộ nhớ.

Kết luận

Khóa luận tốt nghiệp của tác giả Nguyễn Quyết Thắng đã giải quyết trọn vẹn bài toán theo dõi trạng thái hàng hóa thời gian thực trong lĩnh vực logistics bằng cách chuyển đổi từ cơ chế API polling sang hệ thống Webhook chịu tải cao. Thông qua việc kết hợp kỹ thuật Log-based CDC (Debezium), nền tảng phân tán Apache Kafka và các mô hình concurrency tối ưu tác vụ I/O-bound, hệ thống đã đáp ứng thành công mức thông lượng 250 request/giây với độ tin cậy và tính toàn vẹn thứ tự dữ liệu cao. Công trình cung cấp giải pháp kỹ thuật có tính ứng dụng thực tiễn rõ rệt cho các doanh nghiệp thương mại điện tử và vận chuyển hàng hóa quy mô lớn.