chương 1 bao gồm Webhook, Message Broker, Change Data Capture và concurrency để có thể thực hiện đồng thời nhiều request hơn trong thời điểm cao tải.1 Định nghĩa về webhook Webhook thường được gọi là reverse APIs hay push APIs. Mục đích chính của webhook là server sẽ cung cấp dữ liệu cho client theo thời gian thực khi có sự kiện phát sinh bên server. Trong thời đại công nghệ hiện nay, có rất nhiều sự kiện được thực hiện bên phía máy chủ mỗi giây như cập nhật cơ sở dữ liệu, tính toán và trả về kết quả, .Vậy nên một công cụ giúp đưa các dữ liệu này đến client ngay tại thời điểm sự kiện đó xảy ra là điều hoàn toàn cần thiết. Đối với các API thông thường, client cần phải tạo request API đến server thường xuyên để biết có sự kiện mới hay không thì webhook lại có thể ngay lập tức thông báo cho client biết khi có sự kiện mới diễn ra.
Webhook được triển khai bằng cách client sẽ đưa cho server 1 end-point URL và chỉ định sự kiện mà client cần được biết. Một khi có sự kiện xảy ra tại server, server sẽ tự động gửi dữ liệu bằng một HTTP request (thường là POST) về sự kiện mà client đã đăng ký đến URL đó.2 Trường hợp sử dụng webhook Webhook thường được sử dụng để thông báo về các sự kiện theo thời gian thực một cách tiết kiệm tài nguyên nhất có thể. Cũng chình vì vậy mà webhook được sử dụng trong trường hợp này. Việc sử dụng webhook có thể dẫn đến hai vấn đề sau: 7 • Do webhook thực hiện HTTP request để thông báo đến client nên sau khi thông báo xong thì sợi dây liên kết giữa client và server sẽ bị cắt đứt (do HTTP là stateless).
Nói cách khác, nếu client gặp lỗi thì client sẽ mất dữ liệu đã được trong khoảng thời gian client không hoạt động. Việc áp dụng Message Broker sẽ giúp giải quyết vấn đề này và sẽ gửi lại message đã mất. • Webhook có thể thực hiện rất nhiều request vì sẽ có rất nhiều sự kiện thay đổi. Khi số lượng lớn request đến đồng thời như vậy mà client không có khả năng chịu tải sẽ rất dễ gây sập hệ thống.2 Message Broker Message broker là một module trung gian giữa các service và ứng dụng, cho phép các services và ứng dụng có thể giao tiếp với nhau thông qua message, kể cả các service hay ứng dụng này không cùng một ngôn ngữ.
Message là một đơn vị dữ liệu trong message broker, nó có thể là request, response, text, binary hoặc JSON. Message broker có thể lưu trữ và điều hướng message đến đến đích phù hợp, message broker cho phép bên gửi gửi message mà không cần biết rõ bên nhận, trạng thái của bên nhận hay số lượng là bao nhiêu. Điều này đảm bảo rằng hai thành phần gửi và nhận được tách rời nhau và không phải chờ đợi nhau, khi đó nếu có nhiều message được gửi đến trong một khoảng thời gian ngắn, hệ thống vẫn có thể xử lý tất cả. Để cung cấp khả năng lưu trữ tin cậy và đảm bảo dữ liệu không bị mất khi truyền tải, message broker cung cấp một message queue chứa các message theo cơ chế vào trước thì ra trước (First In First Out) và các thành phần có thể tương tác với queue này để gửi và nhận message.
Để gửi message, một thành phần được gọi là producer tạo ra các message và đẩy vào queue. Message được lưu trữ trong queue cho đến khi một thành phần khác là consumer nhận message và xử lý các tác vụ với message nhận được. Message broker cung cấp 2 mô hình chính để điều hướng message.1 Mô hình điều hướng message Point-to-point messaging Trong mô hình point-to-point messaging (giao tiếp dữ liệu dạng điểm-điểm), mes- sage được gửi từ producer đến một và chỉ một consumer cho dù có nhiều consumer 8 lắng nghe chung trong một queue. Mỗi message đều chỉ được gửi đến một endpoint duy nhất.
Mô hình này được sử dụng khi muốn bảo đảm message được nhận bởi duy nhất một consumer và chỉ được xử lý một lần duy nhất bởi consumer. Một ví dụ về trường hợp sử dụng point-to-point messaging là xử lý giao dịch tài chính. Trong hệ thống này, bên gửi tiền và bên nhận tiền cần đảm bảo rằng mỗi giao dịch thanh toán sẽ được gửi một lần và chỉ một lần duy nhất.1: Mô hình point-to-point messaging [2] Publish/Subscribe messaging Mô hình Publish/Subscribe messaging (giao tiếp dữ liệu dạng phát hành/đăng ký) cho phép message được gửi tới nhiều endpoint khác nhau thay vì chỉ duy nhất một như point-to-point. Lúc này message queue được gọi là message topic hay topic.
Trong mô hình này, producer được gọi là publisher còn consumer được gọi là subscriber. Các publisher đẩy các message vào trong topic sau đó những subscribers mà subscribe chung vào topic đó sẽ nhận message và xử lý chúng. Điểm khác biệt giữa point-to-point messaging và publish/subscribe messaging là số lượng consumer (subscriber) subscribe vào một queue.2: Mô hình publish/subscribe messaging [2] Việc sử dụng message broker cung cấp một cách truyền tải không đồng bộ giữa bên gửi và bên nhận vì các bên gửi không cần phải không cần phải đợi phản hồi của bên nhận, việc này nhằm đảm bảo khi có nhiều message được gửi đến, hệ thống có thể chịu tải cao, hai bên gửi và nhận không cần phải chờ đợi nhau vì bị chặn bởi request trước đó. Ngoài ra, khả năng đảm bảo message không bị mất vì các message được lưu trong topic nhằm tránh mất thông tin đến client trong trường hợp client gặp sự cố cũng là một điểm nổi bật của message broker.
Để đáp ứng được khả năng chịu tải cao của hệ thống của khóa luận, mô hình publish/subscribe được chọn để triển khai để có thể giúp phân phối message đến nhiều bên nhận cùng lúc và có thể nâng cấp dễ dàng khi có thêm nhiều bên nhận. Note: Để đơn giản và đỡ gây nhầm lẫn, các thuật ngữ publisher/subscriber/mes- sage topic đã được đề cập trong mô hình publish/subscribe đề cập ở trên sẽ lần lượt chuyển thành producer/consumer/topic. Hiện nay, có nhiều Message Broker hoạt động trên nền tảng và cách thức khác nhau, nhưng mục đích chính của Message Broker vẫn là điều hướng, trung chuyển message từ bên gửi đến bên nhận. Có thể kể đến một vài Message Broker được sử dụng phổ biến hiện nay như: Apache Kafka, RabbitMQ, Apache ActiveMQ,.
10 mỗi Message Broker lại có một kiến trúc và use case khác nhau và được phân chia thành hai loại chính là Message base gồm RabbitMQ, ActiveMQ,. và Data pipeline như Kafka.1 sẽ nêu rõ sự khác biệt giữa hai loại Message Broker này từ đó nhằm có thể đưa ra lựa chọn phù hợp cho khóa luận: Message Base Data Pipeline Sau khi consumer nhận được mes- Sau khi consumer nhận được mes- sage thì message này sẽ bị xóa khỏi sage thì message này vẫn được lưu queue mà consumer subscribe lại trong vài ngày kể từ khi topic nhận được message Lưu trạng thái của consumer để đảm Không lưu trạng thái của consumer bảo tất cả các consumer subscribe vào topic đều nhận được message Khi một message mới được đẩy vào Khi có message mới, consumer có topic, consumer đang subscribe vào thể tùy ý lấy message theo dạng topic đó chỉ lấy được duy nhất một batch, có thể chỉ lấy message mới message mới đó hoặc cả message cũ Bảng 2.1: So sánh sự khác nhau giữa Message base và Data pipeline Dựa vào bảng trên, có thể thấy rõ sự khác nhau cơ bản giữa 2 loại và lựa chọn phù hợp với từng bài toán: • Đối với các bài toán yêu cầu đảm bảo mỗi consumer đều nhận được message và diu nhất một lần nhận thì Message base sẽ thích hợp làm hệ thống truyền tải message giữa các service và ứng dụng với nhau. • Còn đối với các bài toán yêu cầu có khả năng lưu trữ message, tốc độ truyền tải message cao và khả năng phân tán mạnh. Khi có message mới thì consumer có thể lựa chọn message muốn lấy thay vì chỉ được lấy message mới nhất và cùng một message consumer có thể lấy lại nhiều lần khi bị mất message thì Data pipeline là sự lựa chọn dành cho bài toán này.
Để phù hợp với nhu cầu của khóa luận, bài toán đặt ra là yêu cầu sự chính xác cao, hệ thống có thể xử lý lượng message lớn với tốc độ cao, mở rộng dễ dàng, đảm bảo không bị mất message bởi vì đối với các thông tin đơn hàng khi được gửi sang 11 cho đối tác phải phải đảm bảo nhanh chóng, yêu cầu sự chính xác và hệ thống phải có khả năng mở rộng dễ dàng khi có thêm nhiều đối tác nên Data pipeline như Apache Kafka là sự lựa chọn phù hợp để giải quyết bài toán này.2 Giới thiệu về Kafka Apache Kafka hay Kafka là một nền tảng publish/subscribe message phân tán dùng để xử lý streaming, xây dựng data pipeline theo thời gian thực hoặc được sử dụng như là một Message Broker. Kafka ban đầu được phát triển bởi LinkedIn vào năm 2011, được viết bằng ngôn ngữ Java và Scala. Sau đó trở thành một project open-source với Apache license nên được gọi là Apache Kafka. Kafka hiện nay có thể xử lý từ 1 triệu message mỗi giây hay hàng nghìn tỷ message một ngày và là nền tảng xử lý dữ liệu streaming phổ biến nhất thế giới được các tổ chức hàng đầu áp dụng trong cơ sở hạ tầng dữ liệu của mình phục vụ cho các hệ thống quan trọng.
Dưới đây là các lý do chính giải thích tại sao Kafka được sử dụng rộng rãi: • Đảm bảo thông lượng cao: Có khả năng xử lý dữ liệu tốc độ cao và khối lượng lớn mà không gặp vấn đề về performance, Kafka có thể xử lý một triệu message trong một giây. • Khả năng mở rộng cao: Vì Kafka là hệ thống phân tán, nên có khả năng mở rộng rất nhanh và dễ dàng. • Khả năng sẵn sàng cao: Vì các message được lưu trữ trong topic và các topic này được lưu trữ trên server (broker) nên các message không thể bị mất khi hệ thống gặp sự cố. Ngoài ra Kafka còn có cơ chế tự cân bằng các message cho các broker khi các broker khác gặp sự cố.
• Khả năng lưu trữ lâu bền: Lưu trữ an toàn, bảo mật các luồng dữ liệu trong một cụm phân tán, đáng tin cậy và có khả năng chịu lỗi cao.3 Kiến trúc của Kafka Hình 2.3: Kiến trúc cơ bản của Kafka [3] Topic Message trong Kafka được lưu trữ vào trong các topic. Topic có thể được coi như là một table trong cơ sở dữ liệu hoặc tệp tin (folder) trong hệ thống file (filesystem), trong khi các message được coi là các file trong folder đó. Một topic có các đặc điểm sau: • Topic là dạng queue: Mỗi khi một message mới được đẩy vào topic, message sẽ được đẩy vào cuối topic và được đọc từ đầu topic.