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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (7.91 MB, 38 trang )

Trang 1<div class="page_container" data-page="1">

ĐẠ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

</div>Trang 2<div class="page_container" data-page="2">

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ụ

</div>Trang 4<div class="page_container" data-page="4">

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

</div>Trang 6<div class="page_container" data-page="6">

Danh mục bảng biểu

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

</div>Trang 7<div class="page_container" data-page="7">

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 tố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 Hồng Bách (trưởng nhóm): Tìm hiểu hàng đợi thơng điệp, Kafka. • Hồ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.

</div>Trang 8<div class="page_container" data-page="8">

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

</div>Trang 9<div class="page_container" data-page="9">

• 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 tồ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 ln 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ệ

</div>Trang 10<div class="page_container" data-page="10">

• 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 tồ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 hồ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. ả ị

</div>Trang 11<div class="page_container" data-page="11">

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

</div>Trang 12<div class="page_container" data-page="12">

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.

</div>Trang 13<div class="page_container" data-page="13">

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

</div>Trang 14<div class="page_container" data-page="14">

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.

</div>Trang 15<div class="page_container" data-page="15">

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.

</div>Trang 16<div class="page_container" data-page="16">

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 q 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 đã q 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. Ngồ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 tồ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.

</div>Trang 17<div class="page_container" data-page="17">

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 đó.

</div>Trang 18<div class="page_container" data-page="18">

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 tồ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. Ngồ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

</div>Trang 19<div class="page_container" data-page="19">

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 xố (Auto-delete: exchange b xố 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) ủ

</div>