Gi i thi u chung 1 ớ ệ Giớ i thi u ch 1ệủ đề 2 Phân công công vi c 1ệ 2 Hàng đợi thông điệ p
Hàng đợi thông điệ p là gì?
Message Queue (H ệthống hàng đợi thông điệp) là h ệthống x lý d ử ữliệu động bao gồm các thành phần được k t n i v i nhau và làm ế ố ớ việc chung theo m t chuỗi xử lý ộ hướng tới m t tr ng thái cuộ ạ ối cùng mà người dùng mong mu n Dố ữ liệu động có th ể xu t phát t nhi u nguấ ừ ề ồn phát sinh như log, dữ liệu s ki n,v.v M t s hự ệ ộ ố ệ thống hàng đợ ửi x lý lu ng d u liên t c và ghi vào h ồ ữliệ ụ ệthống d ữliệu tĩnh để thực hiện lưu trữ [2]
M t cách d hi u, Message Queue là mộ ễ ể ột hàng đợi (queue), ch a các tin nhứ ắn (message) giúp cho các thành ph n (ho c các d ch v , v.v.) trong m t hầ ặ ị ụ ộ ệ thống có th ể trao đổi thông tin v i nhau Message Queue giớ ống như một hộp thư, tuân theo cơ chế FIFO (First In First Out) của queue Message nào được đưa vào trước thì sẽ được lấy ra trước
Hình II-1 mô t các cách các thành ph n c a hả ầ ủ ệ thống Message Queue tương tác với nhau M t h ộ ệthống Message Queue thường có nh ng thành ph n sau: ữ ầ
• Message: Thông tin được gửi đi (có thể là text, binary hoặc JSON)
• Message Queue: Nơi chứa những message này, cho phép producer và consumer có thể trao đổi với nhau
• Producer: Service tạo ra thông tin, đưa thông tin vào message queue
• Consumer: Service nh n message tậ ừ message queue và xử lý
• M t service có th v a là producer, vộ ể ừ ừa là consumer
2.2 Trong th ực tế, Message Queue được sử ụ d ng ra sao?
Trong các h ệthống s d ng ki n trúc ử ụ ế microservice, ta s dử ụng Message Queue để giúp các service giao ti p v i nhau m t cách ế ớ ộ bất đồng bộ Service A làm xong vi c có ệ thể gửi message queue để service B biết mà x ử lý Service A sau đó đi làm việc khác, không c n ph i chầ ả ờ service B làm xong Ví d , ta có mụ ột website cho phép người dùng t i video t ả ừ Youtube Website đó sẽ có nh ng dữ ịch v chính sau: ụ
• Web service: Là một producer, nh n thông tin (url c a video) t ậ ủ ừ phía người dùng, sau đó đưa thông tin vào message queue
• Processing Service: V a là consumer, vừ ừa là producer Service này đọc url từ Youtube qua message queue, bắt đầ ảu t i file v , encode lề ại và lưu vào server Sau khi encode xong, nó đưa url của file đã được encode vào message queue, gửi cho Uploading Service
• Uploading Service: Khi nhận được message t Processing Service, nó s upload ừ ẽ các video đó lên Google Drive, v.v
2.3 Ưu và nhược điểm củ a Message Queue
• Đảm b o duration/recovery: Do message đã được lưu trong queue, khi một ả service lấy message ra và x ử lý nhưng bị crash ho c l i, ta không lo bặ ỗ ị mất d ữliệu; vì có th l y message t trong queue ra và ch y l i Trong m t hể ấ ừ ạ ạ ộ ệ thống có nhiều consumer, n u m t vài consumer bế ộ ị crash cũng không làm crash toàn hệ thống
• Phân tách hệ thống: Giúp phân tách hệ thống thành nhi u service nhề ỏ hơn, mỗi service ch x lý 1 chỉ ử ức năng nhất định
• H ộtrợ rate limit, batching: Trong nhiều trường hợp, năng lực x lý hử ệ thống có h n Ví d ạ ụ như service chỉ có th x ể ử lý 300 đơn hàng/s Với message queue, ta có thể d n d n lầ ầ ấy đơn hàng trong queue ra xử lý, không s ợthất l c Ho c thay vì phạ ặ ải g i t ng email m t th i gian lâu, ta có thử ừ ấ ờ ể đợi message queue có yêu c u g i 200 ầ ử email r i gồ ửi luôn 1 lượt.
• Dễ scaling hệ thống: Vào giờ cao điểm, nhi u truy v n, ta có thề ấ ể tăng số lượng consumer lên để xử lý được nhiều messege hơn Khi không cần ta có thể giảm l i ạ
• Làm h ệthống ph c tứ ạp hơn: Thêm message queue s ẽtăng tính phức tạp c a h ủ ệ thống Ta c n ph i biếầ ả t rõ message nào g i vào queue nào, ai g i ai nh n Lúc ử ử ậ debug local s ở ẽ khó khăn hơn.
• Cần có Monitor Queue: Phải có các biện phát theo dõi (monitor), để đảm bảo lượng message queue không quá nhiều, làm đầy queue Queue tốt nhất là queue luôn r ng, ho c sỗ ặ ố lượng message trong queue không tăng lên nhiều (message gửi vào queue đều bị consume hết trong th i gian ng n nh t) ờ ắ ấ
• Cần có message format: Để gửi/nh n t 2 phía producer và consumer th ng nhậ ừ ố ất format v i nhau Nớ ếu 1 bên thay đổi định d ng s làm bên còn l i không thạ ẽ ạ ể đọc d u ữliệ
Ưu và nhược điểm c a Message Queue 3 ủ 1 Ưu điểm
• Web service: Là một producer, nh n thông tin (url c a video) t ậ ủ ừ phía người dùng, sau đó đưa thông tin vào message queue
• Processing Service: V a là consumer, vừ ừa là producer Service này đọc url từ Youtube qua message queue, bắt đầ ảu t i file v , encode lề ại và lưu vào server Sau khi encode xong, nó đưa url của file đã được encode vào message queue, gửi cho Uploading Service
• Uploading Service: Khi nhận được message t Processing Service, nó s upload ừ ẽ các video đó lên Google Drive, v.v
2.3 Ưu và nhược điểm củ a Message Queue
• Đảm b o duration/recovery: Do message đã được lưu trong queue, khi một ả service lấy message ra và x ử lý nhưng bị crash ho c l i, ta không lo bặ ỗ ị mất d ữliệu; vì có th l y message t trong queue ra và ch y l i Trong m t hể ấ ừ ạ ạ ộ ệ thống có nhiều consumer, n u m t vài consumer bế ộ ị crash cũng không làm crash toàn hệ thống
• Phân tách hệ thống: Giúp phân tách hệ thống thành nhi u service nhề ỏ hơn, mỗi service ch x lý 1 chỉ ử ức năng nhất định
• H ộtrợ rate limit, batching: Trong nhiều trường hợp, năng lực x lý hử ệ thống có h n Ví d ạ ụ như service chỉ có th x ể ử lý 300 đơn hàng/s Với message queue, ta có thể d n d n lầ ầ ấy đơn hàng trong queue ra xử lý, không s ợthất l c Ho c thay vì phạ ặ ải g i t ng email m t th i gian lâu, ta có thử ừ ấ ờ ể đợi message queue có yêu c u g i 200 ầ ử email r i gồ ửi luôn 1 lượt.
• Dễ scaling hệ thống: Vào giờ cao điểm, nhi u truy v n, ta có thề ấ ể tăng số lượng consumer lên để xử lý được nhiều messege hơn Khi không cần ta có thể giảm l i ạ
• Làm h ệthống ph c tứ ạp hơn: Thêm message queue s ẽtăng tính phức tạp c a h ủ ệ thống Ta c n ph i biếầ ả t rõ message nào g i vào queue nào, ai g i ai nh n Lúc ử ử ậ debug local s ở ẽ khó khăn hơn.
• Cần có Monitor Queue: Phải có các biện phát theo dõi (monitor), để đảm bảo lượng message queue không quá nhiều, làm đầy queue Queue tốt nhất là queue luôn r ng, ho c sỗ ặ ố lượng message trong queue không tăng lên nhiều (message gửi vào queue đều bị consume hết trong th i gian ng n nh t) ờ ắ ấ
• Cần có message format: Để gửi/nh n t 2 phía producer và consumer th ng nhậ ừ ố ất format v i nhau Nớ ếu 1 bên thay đổi định d ng s làm bên còn l i không thạ ẽ ạ ể đọc d u ữliệ
• Khó xử lý đồng bộ: Không ph i hả ệ thống nào cũng cần t i message queue Nớ ếu như service A gọi service B, theo cơ chế đồng bộ, cần kết quả xử lý ngay, ta nên dùng Rest ho c gRPC s tặ ẽ ốt hơn.
Apache Kafka
Event streaming là gì?
Event streaming là vi c thu th p dệ ậ ữ liệu theo th i gian th c t các ngu n s kiờ ự ừ ồ ự ện như cơ sở dữ liệu, cảm bi n, thi t b ế ế ị di động, d ch v ị ụ đám mây và ứng d ng ph n mụ ầ ềm dướ ại d ng lu ng s kiện; lưu trữ những luồng sự kiện này một cách b n vồ ự ề ững để ấ ại l y l sau; thao tác, x lý và ph n ng v i lu ng sử ả ứ ớ ồ ự ki n theo th i gian thệ ờ ực cũng như hồi quy; và định tuyến luồng sự kiện đến các công nghệ đích khác nhau khi cần thiết Event streaming do đó đảm bảo luồng và giải thích dữ liệu liên tục để thông tin đúng đắn đến đúng nơi, vào đúng thời điểm.
Apache Kafka là m t event streaming platform 4 ộ 3.3 T i sao nên sạ ử d ng Apache Kafka? 4ụ 3.4 C u trúc c a Apache Kafka 7ấủ 3.5 Cách Kafka ho ạt độ ng
Apache Kafka là m t event streaming platform, g m ba khộ ồ ả năng chính sau:
• Có thể publish (ghi) và subcribe to (đọc) tới nhi u lu ng s kiện (streams of ề ồ ự events)
• Có th ểstore (lưu trữ) các lu ng s ồ ựkiện (streams of events) lâu dài và đáng tin cậy
• Có th ểprocess (xử lý) các streams of events m i khi có b n ghi m i ỗ ả ớ
Và t t cấ ả chức năng này được cung c p theo cách phân tán, có khấ ả năng mở ộ r ng cao, linh ho t, có khạ ả năng chị ỗu l i và an toàn Kafka có thể được tri n khai trên máy ể tính, máy o và vùng chả ứa cũng như tại ch ỗ cũng như trên đám mây
3.3 T ại sao nên sử ụ d ng Apache Kafka?
Kafka có m t sộ ố đặc điểm sau:
• Là d án mã ngu n mự ồ ở
• Được đóng gói hoàn chỉnh
• Khả năng chị ỗi cao u l
• Tốc độ nhanh: V i mớ ột máy đơn cài đặt Kafka có th x lý sể ử ố lượng dữ liệu t ừ việc đọc và ghi lên tới hàng trăm megabyte trong một giây t hàng ngàn máy ừ khách
• Rất đáng tin cậy: Dữ liệu vào hàng đợ ẽ i s được lưu trữ trên ổ đĩa và được sao chép t i các nút khác trong cớ ụm để ngăn ngừa vi c m t dệ ấ ữ liệu, như vậy Kafka đảm b o tính ch u lỗi cao ả ị
• Có khả năng mở ộ r ng ngang: Kafka được thiết kế cho phép dễ dàng được mở r ng và trong su t vộ ố ới người dùng (nghĩa là không có thời gian chết – ng ng hoừ ạt động trong khi thêm m t nút máy ch m i vào c m) Khi Kafka ch y trên mộ ủ ớ ụ ạ ột c m, lu ng dụ ồ ữ liệu sẽ được phân chia và được v n chuy n t i các nút trong c m, ậ ể ớ ụ do đó cho phép trung chuyển các dữ liệu mà có khối lượng lớn hơn nhiều so với s c ch a c a mứ ứ ủ ột máy đơn [2]
Vì vậy, Kafka đang dần được thay th cho h ế ệthống nh n tin truy n thắ ề ống Nó được s d ng cho các hử ụ ệ thống nh n tin ắ thông thường trong các ng cữ ảnh khác nhau Đây là hệ qu khi khả ả năng mở ộ r ng ngang và chuy n giao dể ữ liệu đáng tin cậy là những yêu cầu quan tr ng nhọ ất [3]
Khi so sánh v i các hớ ệ thống truyền thông điệp truy n thề ống lâu đời như RabbitMQ Trong k t quế ả chạy th nghi m c a LinkedIn cùng m t c u hình vử ệ ủ ộ ấ ới RabbitMQ, Kafka cho thấy lượng dữ liệu đọc và ghi cao hơn nhiều so v i RabbitMQ ớ Ngược lại, lượng tài nguyên mà Kafka chiếm dụng lại ít hơn nhiều Do đó Kafka thích hợp hơn cho các ứng dụng xử lý thời gian th c vự ới lượng d u l n ữliệ ớ
M t vài use case cho Kafka: ộ
• Sử dụng như một hệ thống message queue thay th cho ActiveMQ hay RabbitMQ ế
• Website Activity Monitoring: Theo dõi hoạt động c a website ủ
• Metrics Collection: Theo dõi hành động người dùng, thu thập dữ liệu về page view, search action Sau đó ghi lại và sử dụng sau
• Event-Sourcing: Lưu lại trạng thái của hệ thống để có thể tái hiện trong trường h p system b down ợ ị Để hiểu rõ hơn về Kafka, hãy tưởng tượng một hệ thống thương mại điện tử có nhi u máy chề ủ thực hi n các công vi c khác nhau T t c các máy chệ ệ ấ ả ủ này đều muốn giao ti p v i Database Server Vì v y, ta sế ớ ậ ẽ có các data pipeline (đường k t nế ối) để ế k t nối các server khác đến Database Server [3]
Hình 3.1 Các đường pipeline k t n i các máy ch và Database Server ế ố ủ
Nhưng trong thực tế, hệ thống thương mại điện tử sẽ còn phải kết nối đến m t vài ộ server khác nữa, như Security Systems, Real time Monitoring,… Lúc này các đườ- ng data pipeline tr nên ph c tở ứ ạp hơn theo sự ra tăng của số lượng hệ thống
Hình 3.2 Các đường pipeline ph c tứ ạp hơn khi số lượng hệ thống tăng Để giải quy t vế ấn đề này thì Kafka ra đời Kafka tách rời các data pipeline gi a ữ các h ệthống, giúp cho vi c giao ti p gi a các h ệ ế ữ ệthống tr ở nên đơn giản hơn.
Hình 3.3 Kafka h ỗtrợ giao ti p gi a các h ế ữ ệthống
Giờ đây, thay vì có hàng loạt các data pipeline gi a các hữ ệ thống với nhau để giao tiếp, ta s s dẽ ử ụng Kafka để giúp các hệthống giao tiếp với nhau
Hình 3.4 M t mô hình cộ ấu trúc Kafka đơn giản
Hình 3.5 M t mô hình c u trúc Kafka chi tiộ ấ ết
Cấu trúc c a Kafka bao g m các thành ph n chính sau: ủ ồ ầ
• Producer: M t producer có th là b t kì ng d ng nào Nó có chộ ể ấ ứ ụ ức năng publish message (ghi d ữliệu) vào một topic nào đó thông qua Broker Cụ thể hơn, producer có nhi m v ệ ụchọn message nào để đưa vào topic nào, nhiệm vụ này rất quan trọng giúp cho Kafka có kh ả năng mở ộ r ng t [2] ốt.
• Messages: Messages đơn thuần là byte array và developer có thể sử dụng chúng để lưu bất kì object v i b t kì format nào - ớ ấ thông thường là String, JSON
• Topic: Là “chủ đề”, thông thường các dữ liệu liên quan đến nhau sẽ được nhóm vào m t Topic M i Topic có th ộ ỗ ể được coi là m t ngu n dộ ồ ữ u riêng bi t D liệ ệ ữliệu được truy n trong Kafka theo Topic, khi mu n truy n d ề ố ề ữliệu khác nhau hay truyền d ữliệu cho các ứng d ng khác nhau ta s tụ ẽ ạo ra các Topic mới M t topic s là mộ ẽ ột category hoặc feed name nơi mà record được publish
• Partitions: Các topic được chia nhỏ vào các đoạn khác nhau, các đoạn này được g i là partition Trên m i partition, d ọ ỗ ữliệu s được lưu theo một thứ tự b t biẽ ấ ến và được gán cho một id gọi là offset, được hiểu như chỉ số của một m ng Offset trên ả mỗi partition là độ ậc l p M t partition có thộ ể được sao chép trên nhi u máy khác ề nhau trong một cụm Kafka
• Consumer: M t consumer có th là b t kì ng d ng nào có chộ ể ấ ứ ụ ức năng subscribe vào m t topic và tiêu th các tin nh n Consumer sộ ụ ắ ẽ đọc dữ u tliệ ừ broker Kafka là hệ thống s d ng mô hình truy n thông public-subscribe nên m i m t topic có ử ụ ề ỗ ộ thể được x lý b i nhi u consumer khác nhau, miử ở ề ễn là consumer đấy subcribe topic đấy
• Broker: Kafka cluster là m t c m ch a nhi u server, mộ ụ ứ ề ỗi một server này được gọi là một broker Broker là nơi lưu trữ các partition, m t broker có thộ ể lưu trữ nhiều partition
• Zookeeper: Được dùng để quản lý và bố trí các broker
3.5 Cách Kafka ho ạt động
Hình 3.6 Cách Kafka hoạt động
Với hình ảnh này, Kafka có các đặc điểm sau:
• Được ch y trên m t c m v i 3 Broker lạ ộ ụ ớ ần lượt là Broker 1, Broker 2, Broker 3
• Topic đó được chia làm 3 Partition lần lượt là Partition 1, Partition 2, Partition 3
• M i Partition s có m t b n sao chép t i mỗ ẽ ộ ả ạ ột Broker để ph c vụ ụ cơ chế sao lưu, kh c ph c l ắ ụ ỗi.
RabitMQ
RabbitMQ là gì?
RabbitMQ là m t message broker mã ngu n m ộ ồ ở được s d ng r ng rãi v i kho ng ử ụ ộ ớ ả
10 ngàn người dùng trên toàn th ếgiới t nh ng công ty kh i nghi p nh cho ừ ữ ở ệ ỏ đến nh ng ữ công ty có quy mô lớn hơn [4] Message broker là m t ph n m m giúp các ng d ng, ộ ầ ề ứ ụ hệ thống và d ch v có th giao tiị ụ ể ếp và trao đổi thông tin v i nhau Chúng có th viớ ể ết bằng nh ng ngôn ng ữ ữ khác nhau và được cài đặt ở nh ng máy khác nhau [5]ữ Điều này là h ỗtrợ tuy t v i cho các hệ ờ ệ thống microservice
4.2 Các giao thứ c RabbitMQ h ỗ trợ
RabbitMQ ban đầu được phát triển để ỗ trợ h AMQP 0-9-1 (Advanced Message Queuing Protocol) vì vậy đây là giao thức cốt lõi được h ỗtrợ bởi RabbitMQ Các hướng dẫn cài đặt trên trang chủ của RabbitMQ cũng dựa trên giao thức này Ngoài ra, RabbitMQ còn h ỗtrợ STOMP (Simple or Stream Text Orientated Messaging Protocol), AMPQ 1.0, HTTP and WebSockets, RabbitMQ Streams [6]
Quá trình xu t b n tin nh n khá gi ng nhau mấ ả ắ ố ở ọi giao th c mà RabbitMQ h ứ ỗtrợ Tất c b n giao thả ố ức đều cho phép người dùng xu t b n mấ ả ột tin nh n có payload (body) ắ và m t ho c nhi u property (header) T t nhiên các property này khác nhau m i giao ộ ặ ề ấ ở ỗ thức [7]
Tất c b n giao thả ố ức cũng hỗ trợ cơ chế xác nh n (acknowledgement mechanism) ậ dành cho nhà xu t b n, cho phép ng d ng xu t b n theo dõi các tin nhấ ả ứ ụ ấ ả ắn đã hoặc chưa được nhà môi gi i (broker) ch p nh n thành công và ti p t c xu t bớ ấ ậ ế ụ ấ ản đợt ti p theo hoế ặc thử xu t b n lấ ả ại đợt hiện tại.
M t mô hình AMQP 0-9-ộ 1 đơn giản được cài đặt như hình dưới đây [8]:
Hình 4.1 Mô hình AMQP 0-9-1 đơn giản
Khởi đầu, publisher xu t b n các message và truy n t exchange (có thấ ả ề ới ể coi như hộp thư hoặc bưu điện) Từ đó, exchange phân phát các bản sao của tin nhắn tới các queue (hàng đợi) theo các luật gọi là “binding” Sau cùng, broker chuyển các tin nhắn từ queue đến consumer ho c các consumer chặ ủ động kéo các tin nh n v theo yêu c u ắ ề ầ RabbitMQ chính là broker đứng ở giữa publisher và consumer
4.3.2 Publisher/Producer Đây là thuật ngữ để chỉ một ứng dụng hay dịch vụ xuất b n ra các message Tu ả ỳ theo t ng giao th c, các publisher gừ ứ ửi message đến những nơi khác nhau Như ví dụ trên, v i giao th c AMQP 0-9-ớ ứ 1, các message được gửi đến exchange Trong khi đó, nếu s dử ụng phương thức AMQP 1.0, vi c xu t b n th c hiệ ấ ả ự ện trên m t link (liên k t) ộ ế hay n u s dế ử ụng MQTT (WebSokets) thì được gửi đến topics Với STOMP thì có đa dạng s l a chự ự ọn cho đích để xu t bấ ản hơn, bao gồm c topic, queue, AMQP 0-9-1 ả exchange [7]
Exchange là m t th c th c a APQP 0-9-ộ ự ể ủ 1 nơi các tin nhắn (message) được gửi đến Exchange điều hướng các tin nhắn (message) đến hàng đợi (queue) Các thu t toán ậ điều hướng phụ thuộc vào “exchange type” và “binding”.
Có 4 lo i exchange ạ như trong bảng dưới đây:
Bảng 4.1 Các loại exchange RabbitMQ
Loại Exchange Tên mặc định trước khi định nghĩa
Direct exchange (Empty string) and amq.direct
Headers exchange amq.match (and amq.headers in RabbitMQ
Exchange được khai báo với mộ ốt s thuộc tính như:
• Độ ề b n (Durability: exchanges survive broker restart)
• Tự động xoá (Auto-delete: exchange b xoá khi không ị còn hàng đợi nào liên kết v i nó nớ ữa)
• Đối số (Arguments: không b t buắ ộc, được sử d ng bụ ởi các plugin và các tính năng đặc biệt c a broker) ủ
Các thu c tính c a mộ ủ ột hàng đợi bao g m: ồ
• Độ bền: được định nghĩa sẵn là bền (durable) hay t m thời (transient) Metadata ạ c a mủ ột hàng đợi bền được lưu trữ trong ổ đĩa (disk) còn metadata của hàng đợi t m thạ ời được lưu trong bộ nh (memory) khi có th ớ ể
• Độc quy n (ch ề ỉ được s d ng bởi mộ ếử ụ t k t nối và hàng đợ ẽ ị xóa khi k t ni s b ế ối đó đóng)
• Tự động xóa (hàng đợi có ít nh t mấ ột người tiêu dùng s b ẽ ị xóa khi người tiêu dùng cuối cùng hủy đăng ký)
• Đối số (tùy chọn; được sử d ng bởi plugin và các tính năng dành riêng cho nhà ụ môi giới như TTL tin nhắn, giới hạn độ dài hàng đợi, v.v.)
M t queue phộ ải được khai báo trước khi sử dụng
Binding là lu t mà các exchange s dậ ử ụng để định tuy n các tin nhế ắn đến queue
Một hàng đợi Q mu n nhố ận được tin nh n thì ph i g n (bind) v i exchange E Có mắ ả ắ ớ ột thu c tính không b bu c cộ ắt ộ ủa binding là routing key (khoá điều hướng) được s d ng ử ụ với m t sộ ố loại exchange Thu c tính này giộ ống như mộ ộ ọt b l c các tin nh n ắ
Cách các lo i exchange k t h p v i binding ạ ế ợ ớ để thực hiện điều hướng các tin nhắn được mô t chi tiết ởả ph n 4.4 vầ ới hình nh minh ho ả ạ
Nếu m t tin nh n không th gộ ắ ể ửi đến hàng đợi nào (ví d do không có binding cho ụ exchange mà nó được xuất bản tới) thì nó sẽ bị loại bỏ hoặc quay trở lại publisher, tu ỳ thu c vào các thu c tính c a tin nhộ ộ ủ ắn mà publisher đã đặt.
Lưu trữ tin nhắn trong các hàng đợi không mang ý nghĩa gì cho đến khi các ứng dụng có th xể ử lý (consume) chúng V i AMQP 0-9-1 model, có hai cách các ng d ng ớ ứ ụ có th làm vi c này: ể ệ
• Đăng ký để nh n các tin nhậ ắn được gửi đến (“push API”): đây là cách được khuyến khích s dử ụng Dùng phương thức basic.consume
Hình 4.2 Cách basic.consume hoạt động
• Thăm dò (polling) (“pull API”): Yêu cầu được gửi lặp đi lặp lại cho đến khi message kh dả ụng Dùng phương thức basic.get
Hình 4.3 Cách basic.get hoạt động
Trừ khi h ệthống đang được thử nghi m hoệ ặc trong trường hợp b t bu c x lý yêu ắ ộ ử cầu một cách đồng b (synchronized), hộ ệ thống không nên dùng cách này vì r t kém ấ hi u qu và tiêu t n tài nguyên [8] ệ ả ố
Trong nhiều trường hợp, ví dụ mạng không đáng tin cậy và các ứng dụng (consumer) có th không x ể ử lý được tin nhắn, do đó, mô hình AMQP 0-9-1 có khái niệm về xác nh n tin nhậ ắn (Message Acknowledgements) Điều này giúp broker biết được khi nào thì có th xoá tin nh n khể ắ ỏi hàng đợi.
Có hai ch xác nh n (Acknowledgement mode): ế độ ậ
• Mô hình xác nhận t ự động (Automatic acknowledgement model): Sau khi broker g i mử ột tin nh n tắ ới ứng d ng (s dụ ử ụng phương thức basic.deliver hoặc basic.get- ok)
• Mô hình xác nh n rõ ràng (Explicit acknowledgement model): Sau khi ng d ng ậ ứ ụ g i lử ại một xác nh n (s dậ ử ụng phương thức basic.ack)
Với mô hình xác nh n rõ ràng, ng d ng có th lậ ứ ụ ể ựa ch n thọ ời điểm gửi l i xác ạ nh n, có th là ngay sau khi nhậ ể ận được tin nh n hoắ ặc sau khi lưu tin nhắn vào một nơi nào đó trước khi xử lý ho c sau khi x lý xong hoàn toàn tin nhặ ử ắn đó.
Nếu m t consumer chộ ết trước khi g i l i xác nh n, broker s g i l i tin nhử ạ ậ ẽ ử ạ ắn đó cho một consumer khác Trong trường hợp không có consumer nào kh d ng, broker s ả ụ ẽ chờ n khi có ít nh t m t consumer cđế ấ ộ ủa queue đấy có th x lý m i thể ử ớ ử g i l ử ại.
4.4 Cách hoạ t đ ộ ng củ a m ột số loạ i exchange
Hình 4.4 Luồng tin nh n v Direct Exchange ắ ới
Các thành ph n chính 12 ầ 2 Publisher/Producer
M t mô hình AMQP 0-9-ộ 1 đơn giản được cài đặt như hình dưới đây [8]:
Hình 4.1 Mô hình AMQP 0-9-1 đơn giản
Khởi đầu, publisher xu t b n các message và truy n t exchange (có thấ ả ề ới ể coi như hộp thư hoặc bưu điện) Từ đó, exchange phân phát các bản sao của tin nhắn tới các queue (hàng đợi) theo các luật gọi là “binding” Sau cùng, broker chuyển các tin nhắn từ queue đến consumer ho c các consumer chặ ủ động kéo các tin nh n v theo yêu c u ắ ề ầ RabbitMQ chính là broker đứng ở giữa publisher và consumer
4.3.2 Publisher/Producer Đây là thuật ngữ để chỉ một ứng dụng hay dịch vụ xuất b n ra các message Tu ả ỳ theo t ng giao th c, các publisher gừ ứ ửi message đến những nơi khác nhau Như ví dụ trên, v i giao th c AMQP 0-9-ớ ứ 1, các message được gửi đến exchange Trong khi đó, nếu s dử ụng phương thức AMQP 1.0, vi c xu t b n th c hiệ ấ ả ự ện trên m t link (liên k t) ộ ế hay n u s dế ử ụng MQTT (WebSokets) thì được gửi đến topics Với STOMP thì có đa dạng s l a chự ự ọn cho đích để xu t bấ ản hơn, bao gồm c topic, queue, AMQP 0-9-1 ả exchange [7]
Exchange là m t th c th c a APQP 0-9-ộ ự ể ủ 1 nơi các tin nhắn (message) được gửi đến Exchange điều hướng các tin nhắn (message) đến hàng đợi (queue) Các thu t toán ậ điều hướng phụ thuộc vào “exchange type” và “binding”.
Có 4 lo i exchange ạ như trong bảng dưới đây:
Bảng 4.1 Các loại exchange RabbitMQ
Loại Exchange Tên mặc định trước khi định nghĩa
Direct exchange (Empty string) and amq.direct
Headers exchange amq.match (and amq.headers in RabbitMQ
Exchange được khai báo với mộ ốt s thuộc tính như:
• Độ ề b n (Durability: exchanges survive broker restart)
• Tự động xoá (Auto-delete: exchange b xoá khi không ị còn hàng đợi nào liên kết v i nó nớ ữa)
• Đối số (Arguments: không b t buắ ộc, được sử d ng bụ ởi các plugin và các tính năng đặc biệt c a broker) ủ
Các thu c tính c a mộ ủ ột hàng đợi bao g m: ồ
• Độ bền: được định nghĩa sẵn là bền (durable) hay t m thời (transient) Metadata ạ c a mủ ột hàng đợi bền được lưu trữ trong ổ đĩa (disk) còn metadata của hàng đợi t m thạ ời được lưu trong bộ nh (memory) khi có th ớ ể
• Độc quy n (ch ề ỉ được s d ng bởi mộ ếử ụ t k t nối và hàng đợ ẽ ị xóa khi k t ni s b ế ối đó đóng)
• Tự động xóa (hàng đợi có ít nh t mấ ột người tiêu dùng s b ẽ ị xóa khi người tiêu dùng cuối cùng hủy đăng ký)
• Đối số (tùy chọn; được sử d ng bởi plugin và các tính năng dành riêng cho nhà ụ môi giới như TTL tin nhắn, giới hạn độ dài hàng đợi, v.v.)
M t queue phộ ải được khai báo trước khi sử dụng
Binding là lu t mà các exchange s dậ ử ụng để định tuy n các tin nhế ắn đến queue
Một hàng đợi Q mu n nhố ận được tin nh n thì ph i g n (bind) v i exchange E Có mắ ả ắ ớ ột thu c tính không b bu c cộ ắt ộ ủa binding là routing key (khoá điều hướng) được s d ng ử ụ với m t sộ ố loại exchange Thu c tính này giộ ống như mộ ộ ọt b l c các tin nh n ắ
Cách các lo i exchange k t h p v i binding ạ ế ợ ớ để thực hiện điều hướng các tin nhắn được mô t chi tiết ởả ph n 4.4 vầ ới hình nh minh ho ả ạ
Nếu m t tin nh n không th gộ ắ ể ửi đến hàng đợi nào (ví d do không có binding cho ụ exchange mà nó được xuất bản tới) thì nó sẽ bị loại bỏ hoặc quay trở lại publisher, tu ỳ thu c vào các thu c tính c a tin nhộ ộ ủ ắn mà publisher đã đặt.
Lưu trữ tin nhắn trong các hàng đợi không mang ý nghĩa gì cho đến khi các ứng dụng có th xể ử lý (consume) chúng V i AMQP 0-9-1 model, có hai cách các ng d ng ớ ứ ụ có th làm vi c này: ể ệ
• Đăng ký để nh n các tin nhậ ắn được gửi đến (“push API”): đây là cách được khuyến khích s dử ụng Dùng phương thức basic.consume
Hình 4.2 Cách basic.consume hoạt động
• Thăm dò (polling) (“pull API”): Yêu cầu được gửi lặp đi lặp lại cho đến khi message kh dả ụng Dùng phương thức basic.get
Hình 4.3 Cách basic.get hoạt động
Trừ khi h ệthống đang được thử nghi m hoệ ặc trong trường hợp b t bu c x lý yêu ắ ộ ử cầu một cách đồng b (synchronized), hộ ệ thống không nên dùng cách này vì r t kém ấ hi u qu và tiêu t n tài nguyên [8] ệ ả ố
Trong nhiều trường hợp, ví dụ mạng không đáng tin cậy và các ứng dụng (consumer) có th không x ể ử lý được tin nhắn, do đó, mô hình AMQP 0-9-1 có khái niệm về xác nh n tin nhậ ắn (Message Acknowledgements) Điều này giúp broker biết được khi nào thì có th xoá tin nh n khể ắ ỏi hàng đợi.
Có hai ch xác nh n (Acknowledgement mode): ế độ ậ
• Mô hình xác nhận t ự động (Automatic acknowledgement model): Sau khi broker g i mử ột tin nh n tắ ới ứng d ng (s dụ ử ụng phương thức basic.deliver hoặc basic.get- ok)
• Mô hình xác nh n rõ ràng (Explicit acknowledgement model): Sau khi ng d ng ậ ứ ụ g i lử ại một xác nh n (s dậ ử ụng phương thức basic.ack)
Cách ho ạt độ ng c a m t s ủ ộ ố loạ i exchange
Với mô hình xác nh n rõ ràng, ng d ng có th lậ ứ ụ ể ựa ch n thọ ời điểm gửi l i xác ạ nh n, có th là ngay sau khi nhậ ể ận được tin nh n hoắ ặc sau khi lưu tin nhắn vào một nơi nào đó trước khi xử lý ho c sau khi x lý xong hoàn toàn tin nhặ ử ắn đó.
Nếu m t consumer chộ ết trước khi g i l i xác nh n, broker s g i l i tin nhử ạ ậ ẽ ử ạ ắn đó cho một consumer khác Trong trường hợp không có consumer nào kh d ng, broker s ả ụ ẽ chờ n khi có ít nh t m t consumer cđế ấ ộ ủa queue đấy có th x lý m i thể ử ớ ử g i l ử ại.
4.4 Cách hoạ t đ ộ ng củ a m ột số loạ i exchange
Hình 4.4 Luồng tin nh n v Direct Exchange ắ ới
Việc định tuy n trong ế Direct Exchange rất đơn giản - m t tin nh n s ộ ắ ẽ được chuyển đến hàng đợi có khóa liên kết khớp chính xác với khóa định tuyến của tin nhắn Direct Exchange r t hấ ữu ích để phân bi t các tin nhệ ắn được xu t b n trên cùng mấ ả ột Exchange bằng cách s dử ụng mã định danh chuỗi đơn giản [9] Ví d chúng ta có mụ ột direct exchange OrderCreatedEvents_Direct và hai hàng đợi được liên kết v i nó ớ
Hình 4.5 Thu c tính c a direct exchange và binding ộ ủ order_create_queue g n v i binding key ắ ớ order-create order_create_log_queue g n v i binding keyắ ớ order-create-log
Ghi chú: routing key của hàng đợi có th gể ọi là binding key để phân bi t v i routing ệ ớ key c a tin nh n ủ ắ
Khi m t tin nh n m i có routing key ộ ắ ớ order-create đến direct exchange, exchange s nh tuyẽ đị ến nó đến hàng đợ ằng khóa địi b nh tuy n thích hế ợp, trong trường hợp này là hàng đợi order_create_queue
Hình 4.6 Thu c tính c a tin nh n và tộ ủ ắ ổng quan hàng đợi
Nếu routing key tin nh n không kh p v i b t k binding key nào, tin nh n s b ắ ớ ớ ấ ỳ ắ ẽ ị loạ ỏi b N u có nhiế ều hơn một hàng đợi b ràng buị ộc trao đổi v i cùng m binding keyớ ột , direct exchange s ẽ phát thông báo đế ấ ả các hàng đợn t t c i phù h p ợ
Hình 4.7 Luồng tin nh n v i Topic Exchange ắ ớ
Topic exchange tương tự như direct exchange, nhưng việc định tuyến được thực hi n theo mệ ẫu định tuy n (routing pattern) Thay vì s dế ử ụng khóa định tuy n cế ố định, nó s d ng ký tử ụ ự đại di n Tin nhệ ắn được định tuyến đến m t ho c nhiộ ặ ều hàng đợ ựa i d trên s kh p giự ớ ữa routing key c a tin nh n và m u nh tuy n Routing key ph i bao ủ ắ ẫ đị ế ả
18 gồm danh sách các từ được phân cách b ng d u chằ ấ ấm “.” Ví dụ: order.logs.customer, order.logs.international, order.logs.personnel
Mẫu định tuyến cũng có thể chứa d u sao ấ (“*”) để kh p v i m t tớ ớ ộ ừ ở ị v trí cụ thể của khóa định tuyến Ví dụ: mẫu định tuyến “order.*.*.electronics” chỉ khớp với các khóa định tuyến trong đó từ đầu tiên là “order” và từ thứ tư là “electronics”.
Mẫu định tuyến cũng có thể chứa ký hi u ệ thăng (“#”) có nghĩa là khớp 0 hoặc nhi u t Ví d : mề ừ ụ ẫu định tuyến “order.logs.customer.#” khớp với bất kỳ khóa định tuy n nào bế ắt đầu bằng “order.logs.customer”
Hình 4.8 Thu c tính c a topic exchange và binding ộ ủ
Hình 4.9 Luồng tin nh n v i Fanout Exchange ắ ớ
Fanout exchange sao chép và định tuy n tin nhế ắn đã nhận đến t t cấ ả các hàng đợi được liên k t v i nó b t k khóa ho c mế ớ ấ ể ặ ẫu định tuy n Các khoá ế được cung cấp đơn gi n b b qua Fanout exchange có th h u ích khi cùng m t tin nh n cả là ị ỏ ể ữ ộ ắ ần được gửi đến m t hoặc nhiộ ều hàng đợ ới nh ng consumer có thể x lý cùng một tin nh n theo i v ữ ử ắ nh ng cách khác nhau ữ
Ví d : khi tụ ạo đơn hàng, kho hàng cần được thông báo để chu n b ẩ ị đơn hàng, công ty v n chuyậ ển hàng hóa cũng cần được thông báo, người tiêu dùng muốn lưu giữ nhật ký đơn hàng cũng cần được thông báo
Hình 4.10 Thu c tính c a fanout exchange và binding ộ ủ
Hình 4.11 Luồng tin nh n v i Header Exchange ắ ớ
Header exchange nh tuy n các thông báo dđị ế ựa trên các đối số chứa tiêu đề và giá trị tùy ch n Nó s d ng các thuọ ử ụ ộc tính tiêu đề ủ c a tin nh n ắ để định tuy n Mế ột đố ối s đặc biệt là “x match”, đượ- c thêm vào trong liên k t giế ữa trao đổi và hàng đợi, chỉ định xem t t cấ ả các tiêu đề ph i kh p hay ch mả ớ ỉ ột tiêu đề Thuộc tính “x match” có thể- có hai giá trị khác nhau: “any” hoặc “ ”, trong đó “all any” là giá trị mặc định Giá tr allị “ ” có nghĩa là tất cả các cặp tiêu đề (khóa, giá trị) phải khớp nhau, trong khi giá trị “any” có nghĩa là ít nhất một trong các cặp tiêu đề phải khớp Ví dụ tạo một header exchange OrderCreatedEvents_Header và ba hàng đợi liên kết với nó
Hình 4.12 Thu c tính c a header exchange và binding ộ ủ
Khi tin nhắn được xu t bấ ản t i header exchange vớ ới các đối số tiêu đề (key value): “format = pdf”, “type = report” và với đối số ràng buộc “x match = all”, nó sẽ- được gửi đến Q1
Hình 4.13 Thu c tính c a tin nh n có header ộ ủ ắ
Hình 4.13 minh ho mạ ột tin nhắn có các đố ố tiêu đềi s là (key = value): “format pdf” và với đối số ràng buộc “x match = Any”- và không có routing key Khi được xuất phản đến header exchange nó sẽ được gửi đến Q2 vì nó đáp ứng một điều kiện và không ph i ả thỏa mãn mọi điều ki n ệ
Demo s d ng RabbitMQ 21 ử ụ 1 Hello World
Work Queues
Mục đích: Thi t l p 1 Work Queue, nh m phân chia các các v t n th i gian x ế ậ ằ ụ ố ờ ử lý cho nhi u workers khác nhauề
Các bước th c hiự ện: Khai báo thư viện, thiết l p k t nậ ế ối, channel và queue tương t ví d trênự ụ
Các ưu điểm của Work Queues:
- Cơ chếRound robin dispatching: Work Queue cho phép x lý các tác v ử ụ song song Khi có nhi u workers, các tác v s ề ụ ẽ được phân lần lượt cho các workers theo th tứ ự
- Cơ chế Message acknowledgment: Yêu c u consumer g i l i 1 tin nhầ ử ạ ắn khi nhận được gói tin Đảm b o n u 1 tác v làm workers b s p thì tác v ả ế ụ ị ậ ụ đó vẫn sẽ được lưu lại và sẽ được điều phối sang workers khác
- Cơ chế message durability: Ta đã đảm b o gói tin không b m t nả ị ấ ếu consumers ch t vế ới cơ chế ACK, nhưng gói tin vẫn s b m t n u server ẽ ị ấ ế AMQP sập
- Cơ chế Fair dispatch: Ta định nghĩa prefetch(1), gi i h n m i workers ch ớ ạ ỗ ỉ nh n tậ ối đa 1 task, như vậy nếu 1 worker đang xử lý thì tasks m i sớ ẽ được điều ph i sang các workers r nhố ả
Hình 5.6 Kết qu ảchạy Work Queues
- Khở ại t o 3 receivers có chức năng nhận tác v queue ụ ở “task_queue”
- Khở ại t o 1 sender có chức năng gửi các tác v v i th i gian x lý khác nhauụ ớ ờ ử
- Khi đó, các tác vụ được gửi đi sẽ lần lượt được 3 receivers nh n và th c thi:ậ ự
• M i receiver s nh n 1 tác vỗ ẽ ậ ụ và chỉ nh n tác vụ mậ ới cho đến khi hoàn thành tác v ụ cũ
• Các gói tin được chuyển đến receivers lần lượt cho đến khi tìm thấy receiver r nhả
• Nếu ta g i t ử ừ4 gói tin đổ lên, chỉ 3 gói tin đầu sẽ được th c thi luôn, ự các gói tin còn lại s phẽ ải đợi cho đến khi có 1 receiver trống
Publish/Subcribe
Mục đích: Thi t l p k t n i cho phép gế ậ ế ố ửi gói tin đến t t cấ ả các bên đăng kí nhận bằng exchange Fanout
- Khai báo thư viện, thiết lập kết nối
- Sau khi thi t l p k t n i thành công, ta kh i t o 1 exchange v i ki u là ế ậ ế ố ở ạ ớ ể
- Sau đó, ta có thể:
• Thực hi n việệ c gửi tin b ng method publish() ằ
• Thực hi n vi c nh n tin b ng cách kh i t o 1 default queue và dùng ệ ệ ậ ằ ở ạ method consume()
Các ưu điểm của Work Queues:
- Cho phép gửi gói tin đến tất cả các bên đăng kí nhận
Hình 5.9 Kết qu ảchạy Publish/Subcribe
- Khở ại to 3 receivers có chức năng nhận tin t exchange “logs” bằng các ừ queues được khởi tạo mặc định
- Khở ại t o 1 sender có chức năng gửi tin thông qua exchange “logs”
- Khi đó, các gói tin sẽ thông qua exchanges được chuy n tiể ếp đến các queues và nh n lậ ại ở ả c 3 receivers
Routing
Mục đích: Thiế ật l p k t n i cho phép gế ố ửi các gói tin đến các hàng đợi mà có khóa liên k t chính xác vế ới khóa định tuy n, thông qua ế exchange Direct
- Thực hiện tương tự ới exchange Fanout, thay khai báo exchange thành v
- Điểm khác là khi g i và nh n tin, c n truy n thêm một khóa để đánh dấu ử ậ ầ ề hàng đợi phù hợp
Các ưu điểm của Routing:
- Cho phép gửi gói tin đến các hàng đợi chọn lọc theo ý muốn
Hình 5.12 Kết qu ảchạy Routing
- Khở ại to 1 receiver A có chức năng nhận tất cả các tin nh n với ba ki u ắ ể
- Khở ại t o 1 receiver B có chức năng chỉ nh n các tin nh n có kiậ ắ ểu”error”
- Khở ại t o 1 sender g i tin v i mử ớ ột trong ba khóa “info, waring, error”:
• Tấ ảt c các gói tin có m t trong ba khóa s ộ ẽ được nh n receiver Aậ ở
• Các gói tin có khóa “error” có được receiver B nh nậ
Topics 29 5.6 T ng k t demo 31ổế
Mục đích: Thi t l p k t n i cho phép g i nh n gói tin theo m t chế ậ ế ố ử ậ ộ ủ đề, quy ước đã định trước bằng exchange Topic
- Thực hi n gi ng vệ ố ới exchange Routing, thay khai báo exchange thành
Các ưu điểm của Topics
- Cho phép g i gói tin theo các ch khác nhauử ủ đề
- M t receiver có th nh n mộ ể ậ ột ho c nhi u chủ tùy thu c vào mong muặ ề đề ộ ốn c a bên nh n.ủ ậ
Hình 5.15 Kết qu ảchạy Topics Quy trình ch y: ạ
- Khở ại t o 3 receivers, m i receiver s nh n các gói tin v i các topics khác ỗ ẽ ậ ớ nhau
- Khở ại t o 1 receiver nhận topic “#” - có chức năng nhận t t c các gói tinấ ả
- Khở ại t o 1 sender có chức năng gửi gói tin v i mã topic ớ tương ứng
Qua ph n demo, ta có thầ ể rút ra được những ưu điểm l n nh t c a RabbitMQ so ớ ấ ủ với các công ngh truy n thông khác là hệ ề ỗ trợ truy n tin về ới độ tin c y cao, nhi u cách ậ ề thức định tuyến khác nhau, phù hợp cho nhiều nhu cầu khác nhau của người dùng:
• Phân chia các tác v hi u qu : ụ ệ ả Cơ chế Work Queues giúp phân chia công vi c hiệ ệu qu gi a nhiả ữ ều workers, giúp tối ưu hóa sức mạnh x lý c a h th ng ử ủ ệ ố
• Publish/Subcribe: Cơ chế này cho phép d dàng gễ ửi thông điệp đến nhiều địa chỉ mà không c n biầ ết thông điệp sẽ đi đến đâu cụ thể
• Routing: Exchange Direct và Routing cho phép định rõ đường d n cho các tin ẫ nh n, giúp tùy ch nh và qu n lý lu ng thông tin m t cách hi u qu ắ ỉ ả ồ ộ ệ ả
• Topics: Exchange Topic giúp tổ chức tin nh n theo các chắ ủ đề, cho phép đăng ký và nhận tin theo đúng những ch quan tr ng ủ đề ọ
