Báo Cáo Bài Tập Lớn Chủ Đề Công Nghệ Thông Điệp.pdf

ĐẠI HỌC QU C GIA HÀ N I ỐỘTRƯỜNG ĐẠI HỌC CÔNG NGHỆ

CHỦ ĐỀ: CÔNG NGH Ệ THÔNG ĐIỆP

Giảng viên: TS Võ Đình Hiếu

1.2 Phân công công vi c 1ệ 2 Hàng đợi thông điệp 2

2.1 Hàng đợi thông điệp là gì? 2

2.2 Trong th c tự ế, Message Queue được sử dụng ra sao? 2

2.3 Ưu và nhược điểm c a Message Queue 3ủ 2.3.1 Ưu điểm 3

2.3.2 Nhược điểm 3

3 Apache Kafka 4

3.1 Event streaming là gì? 4

3.2 Apache Kafka là m t event streaming platform 4ộ 3.3 T i sao nên sạ ử d ng Apache Kafka? 4ụ

iv

Danh mục hình ảnh

Hình 2.1 Hệ thống Message Queue 2

Hình 3.1 Các đường pipeline k t n i các máy ch và Database Server 6ếốủ Hình 3.2 Các đường pipeline ph c tứ ạp hơn khi số lượng h ệ thống tăng 6

Hình 3.3 Kafka h ỗ trợ giao ti p gi a các h ếữệ thống 7

Hình 3.4 M t mô hình cộấu trúc Kafka đơn giản 7

Hình 3.5 M t mô hình c u trúc Kafka chi ti t 7ộấế Hình 3.6 Cách Kafka hoạt động 9

Hình 3.7 Hành động Producer ghi, đưa các Message mới vào các Partition 11

Hình 4.1 Mô hình AMQP 0-9-1 đơn giản 12

Hình 4.2 Cách basic.consume hoạt động 15

Hình 4.3 Cách basic.get hoạt động 15

Hình 4.4 Luồng tin nh n v Direct Exchange 16ắới Hình 4.5 Thu c tính c a direct exchange và binding 16ộủ Hình 4.6 Thu c tính c a tin nh n và tộủắổng quan hàng đợi 17

Hình 4.7 Luồng tin nh n v i Topic Exchange 17ắớ Hình 4.8 Thu c tính c a topic exchange và binding 18ộủ Hình 4.9 Luồng tin nh n v i Fanout Exchange 18ắớ Hình 4.10 Thu c tính c a fanout exchange và binding 19ộủ Hình 4.11 Luồng tin nh n v i Header Exchange 19ắớ Hình 4.12 Thu c tính c a header exchange và binding 20ộủ Hình 4.13 Thu c tính c a tin nh n có header 20ộủắ Hình 5.1 Receiver HelloWorld 21

Hình 5.2 Sender HelloWorld 22

Hình 5.3 K t qu ếả chạy HelloWorld 22

Hình 5.4 Receiver Work Queues 23

Hình 5.5 Sender Work Queues 24

Hình 5.6 K t qu ếả chạy Work Queues 24

Hình 5.7 Receiver Publish/Subcribe 25

vi

Danh mục bảng biểu

Bảng 4.1 Các lo i exchange RabbitMQ 13ạ

1

1 Giới thiệu chung

1.1. Giới thiệu chủ đề

Trong b i c nh hiố ả ện đại, nhi u hề ệ thống được xây dựng theo cơ chế phân tán, các dịch v c n trao i v i nhau m i có th xụ ầ đổ ớ ớ ể ử lý được yêu c u tầ ừ người dùng Vi c giao ệ tiếp gi a các d ch v này cữ ị ụ ần được xem xét một cách th n trậ ọng đểđảm b o c các yêu ả ả cầu chức năng và phi chức năng Có hai mẫu giao tiếp cơ bản là đồng b (synchronous) ộ và bất đồng b (asynchronous) [1] ộ

Giao tiếp là đồng bộ khi một d ch v g i m t yêu cị ụ ử ộ ầu đến m t dộ ịch v ụ khác và đợi đến khi nhận được phản hồi trước khi tiếp t c th c hi n Viụ ự ệ ệc này được thực hiện đồng bộ ph bi n nh t là qua HTTP, s d ng các giao thổ ế ấ ử ụ ức như REST, GraphQL và gRPC Hệ thống nên s m u giao tiử ẫ ếp đồng b khi d ch v không th ộ ị ụ ể tiếp t c mà không có phụ ản hồi t d ch v khác, các d ch v ừ ị ụ ị ụ được k t n i mế ố ạnh m ho c vi c tính toán và ph n hẽ ặ ệ ả ồi m t ít th i gian ấ ờ

Giao ti p là bế ất đồng b khi m t d ch v g i yêu cộ ộ ị ụ ử ầu đến m t d ch v khác và ộ ị ụ không đợi phản hồi; thay vào đó, nó tiếp tục với công vi c cệ ủa mình Nó thường được triển khai bằng cách s d ng một trung gian tin nhắn (message broker) như RabbitMQ, ử ụ Kafka, ActiveMQ, v.v

Nhược điểm của giao tiếp bất đồng bộ là độ trễ khi xử lý, khó theo dõi luồng các tin nh n chuy n qua l i gi a các d ch vắ ể ạ ữ ị ụ, có nguy cơ message broker trở thành SPoF (sigle point of failure, n u h ng s kéo theo c hế ỏ ẽ ả ệ thống d ng hoừ ạt động) Nhưng đổi l i, mạ ẫu giao tiếp này đem đến những ưu điểm vượt trội như tối đa hoá việc sử dụng tài nguyên và độ sẵn sàng do các dịch vụ không cần chờ phản hồi ngay lập tức, nguy cơ quá tải được gi m thi u, các d ch v không c n liên k t quá m nh mả ể ị ụ ầ ế ạ ẽ, ki m soát tể ốt hơn về s c và th l ự ố ử ại.

Báo cáo này s ẽ đưa ra một cái nhìn t ng quan v ổ ề hàng đợi thông điệp, tìm hi u chi ể tiết v hai công ngh ề ệ thông điệp ph ổ biến là Kafka và RabbitMQ Cu i cùng là t p trung ố ậ vào việc demo ưu điểm của RabbitMQ

1.2 Phân công công vi c ệ

Các thành viên tham gia đóng góp vào việc xây dựng báo cáo bao gồm: • Nguyễn Hoàng Bách (trưởng nhóm): Tìm hiểu hàng đợi thông điệp, Kafka • Hoàng Th Thu Hà: Vi t gi i thi u, tìm hi u RabbitMQ, trình bày báo cáo ị ế ớ ệ ể • Bá Thanh Tùng: Demo cài đặt và sử dụng RabbitMQ

2 2 Hàng đợi thông điệp

2.1. 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

Hình 2.1 H ệ thống Message Queue

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: ụ

3

• 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ủ Message Queuea

2.3.1. Ưu điểm

• Đả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 ạ

2.3.2. Nhược điểm

• 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ệ

4

• 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.

3 Apache Kafka 3.1 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

3.2 Apache Kafka là m t event streaming platform ộ

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 đợ ẽ được lưu trữi s 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 ả ị

5

• 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 ủ

• Stream Processing: X lý stream ử • Log Aggregation: T ng h p log ổ ợ

• 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 ủa hệ th c ố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]

6

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.

7

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ệ ống giao tiếp với nhau th

3.4. Cấu trúc c a Apache Kafka ủ

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

8

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

9 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 • Có 1 Topic là MCL

• 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.

• M i Partition s có mỗ ẽ ột Broker để làm leader, các Broker khác cũng lưu trữ Partition đó thì gọi là follower Follower chỉ có vai trò sao lưu dữ liệu Ví dụ như Partition 1 có leader là Broker 1, follower là Broker 3

• M i Partition sỗ ẽ được c u hình tham s nhân b n (replication factor) Trong hình ấ ố ả trên, replication factor bằng 2, nghĩa là mỗi partition sẽ được lưu trữ trên 2 broker • Chỉ s (0, 1, 2 ) trên m i partition là offset c a m i partition ch không ph i offset ố ỗ ủ ỗ ứ ả

c a topic ủ

• Một điểm lưu ý nữa của Apache Kafka, đó là nền tảng Apache Kafka được xây d ng k t h p v i n n tự ế ợ ớ ề ảng Apache Zookeeper Zookeeper đóng vai trò cung cấp các d ch v lõi c a h ị ụ ủ ệ thống phân tán như: dịch v qu n lý c u hình h ụ ả ấ ệ thống, bầu trưởng nhóm (leader election), định danh (naming), lưu trữ các thông tin chung metadata như thông tin về topic, partition của topic, danh sách broken, vị trí d ữ liệu offset mà consumer đã đọc đến… Zookeeper được Kafka để bầu tự động leader cho các partition, qu n lý danh sách nút máy ch hoả ủ ạt động và qu n lý danh ả sách các topic

10 Hoạt động của các thành phần chính khác: • Topic:

o Đối với Topic ch có m t Partition: M i topic sỉ ộ ỗ ẽ được đặt tên bởi người dùng và có th coi mể ỗi topic như một Message Queue Các Message mới do m t ho c nhiộ ặ ều producer đẩy vào, sẽ luôn luôn được thêm vào cuối hàng đợi B i vì mở ỗi thông điệp được đẩy vào topic s ẽ được gán m t offset ộ tương ứng (ví dụ: thông điệp đầu tiên có offset là 1, thông điệp thứ hai là 2, ) nên consumer có th ể dùng offset này để điều khiển quá trình đọc thông điệp Nhưng cần lưu ý là bởi vì Kafka sẽ t ự động xóa những thông điệp đã quá cũ ( thông điệp đẩy vào đã quá hai tuần hoặc xóa bởi vì bộ nhớ cho phép để chứa thông điệp đã đầy) vì v y s g p l i n u truy c p vào các ậ ẽ ặ ỗ ế ậ thông điệp đã bị xóa

o Đối với Topic có nhi u Partition: Khi mề ột thông điệp được đẩy vào topic, mặc định nó sẽ được g n m t chu i s bắ ộ ỗ ố ất kì Thông điệp được đẩy vào Parttion nào ph thu c vào giá tr ụ ộ ị băm của chu i s ỗ ố đó, điều này đảm bảo s ố lượng thông điệp trên mỗi partition là tương tự nhau B i vì t i m t thở ạ ộ ời điểm, một partition ch ỉđược đọc bởi một consumer duy nh t, v y v i viấ ậ ớ ệc tăng số lượng partition s ẽ tăng số lượng dữ liệu được đọc lên tương đương v i viớ ệc song song hóa được việc đọc Ngoài ra, offset chính là định danh duy nh t cho mấ ỗi thông điệ ởp trong partition ch không ph i trong toàn ứ ả b topic, vì vộ ậy để consumer đọc chính xác thông điệp, chúng ta c n cung ầ cấp địa chỉ của thông điệp có d ng (topic, partition, offset) ạ

• Partition: V i m i partition, tùy thuớ ỗ ộc vào người dùng c u hình, ta s có m t s ấ ẽ ộ ố b n sao chép nhả ất định để đảm b o dả ữ liệu không b m t khi m t node trong cị ấ ộ ụm b h ng Tuy nhiên sị ỏ ố lượng bản sao không được vượt quá số lượng broker trong c m, và nh ng bụ ữ ản sao đó sẽ được lưu lên các broker khác Broker chứa b n chính ả c a partition gủ ọi là broker “leader” Những b n sao chép này có tác d ng giúp h ả ụ ệ thống không b m t d liệu n u có m t sị ấ ữ ế ộ ố broker b l i, vị ỗ ới điều kiện số lượng broker b l i không lị ỗ ớn hơn hoặc b ng sằ ố lượng b n sao c a m i partition Ví d ả ủ ỗ ụ m t partition có hai bộ ản sao được lưu trên 3 broker sẽ không b mị ất d ữ liệu n u có ế m t broker b l i Còn mộ ị ỗ ột điều quan tr ng n a phọ ữ ải lưu ý, do các phiên bản sao chép này không nh n d ậ ữ liệu tr c ti p t ự ế ừ producer hay được đọc bởi consumer, mà nó chỉ đồng b v i paritition chính vì vộ ớ ậy nó không làm tăng khả năng song song hóa việc đọc và ghi

11

Hình 3.7 Hành động Producer ghi, đưa các Message mới vào các Partition

• Producer: Producer có nhi m vệ ụ đẩy dữ liệu vào m t ho c nhiộ ặ ều topic Người dùng có th quyể ết định li u nhệ ững thông điệp (m i dòng c a dỗ ủ ữ liệu) nào s cùng ẽ thu c vào m t partition thông qua m t chuộ ộ ộ ỗi khóa đính kèm với thông điệp Nếu không producer s gán m t khóa ng u nhiên và quyẽ ộ ẫ ết định đích đến của thông điệp d a trên giá tr ự ị băm của khóa

• Consumer: Consumer có nhi m v kéo d ệ ụ ữ liệu t m t topic ch ừ ộ ỉ định v Tùy thuề ộc vào mục đích sử ụ d ng, Kafka cung cấp hai hàm API như sau: High Level Consumer: API này hướng t i nh ng ớ ữ ứng d ng không quan tâm v ụ ề việc điều khiển việc đọc thông điệp (m i dòng c a dỗ ủ ữ liệu), người dùng ch có thỉ ể đọ ừc t thông điệp cũ nhất hoặc đọc t ừ thông điệp mới nhất API này luôn lưu lại offset c a thông ủ điệp được lấy về mới nhất của mỗi partition vào Zookeeper Simple Consumer: Việc s dụng API này tương đốử i phức tạp hơn API trên nhưng nó cho phép điều khi n viể ệc đọc m t cách linh ho t dộ ạ ựa trên offset Do đó, API này cho phép ứng d ng có th x lý lụ ể ử ại thông điệp nếu g p l i trong quá trình xặ ỗ ử lý trước đó.

12 4 RabitMQ

4.1 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.

4.3 Các thành ph n chính ầ

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

13

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]

4.3.3 Exchange

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 Fanout exchange amq.fanout

Topic exchange amq.topic

Headers exchange amq.match (and amq.headers in RabbitMQ Exchange được khai báo với mộ ốt s thuộc tính như:

• Tên (Name)

• Độ ề 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) ủ