Giao Thuc Amqp Ky Thuat Ket Noi Mang

Giao-thfíc-AMQP - Kỹ thuật kết nối mạng
Mạng máy tính (Trường Đại học Thăng Long)
Scan to open on Studocu
Studocu is not sponsored or endorsed by any college or university

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)
TRƯỜNG ĐẠI HỌC THĂNG LONG
KHOA TOÁN TIN
TIỂU LUẬN
GIAO THỨC AMQP VÀ ỨNG DỤNG

TRONG IOT
MÔN HỌC: KỸ THUẬT KẾT NỐI MẠNG

LỚP: KTKNM.1
GIẢNG VIÊN: PGS.TS. HOÀNG TRỌNG MINH
THÀNH VIÊN: A42340_PHAN THỊ THƯỞNG
A43364_NGUYỄN MINH
THƯỞNG
A41767_NGUYỄN THU HƯƠNG
A43620_KIỀU TUẤN ANH
HÀ NỘI-2024

MỤC LỤC
CHƯƠNG 1. GIỚI THIỆU CHUNG......................................................................................

1.1. Tổng quan về IOT............................................................................................1
1.1.1. Khái niệm IoT.............................................................................................
1.1.2. Cấu trúc của một hệ thống IoT...................................................................
1.1.3. Cách hoạt động của IoT.............................................................................
1.1.4. Ưu và nhược điểm của IoT.........................................................................
1.1.5. Lợi ích của IoT...........................................................................................
1.1.6. Các ứng dụng của IIoT trong các ngành khác nhau..................................
1.2. Tổng quan về giao thức AMQP.....................................................................10
1.2.1. Khái niệm AMQP.....................................................................................
1.2.2. Ưu điểm của AMQP.................................................................................
1.2.3. Giới thiệu chung về giao thức AMQP......................................................
1.3. Mục tiêu của tài liệu.......................................................................................13
1.4. Tổng quan.......................................................................................................13
1.4.1. Tại sao chọn AMQP?...............................................................................
1.4.2. Phạm vi của AMQP..................................................................................
1.4.3. Mô hình Hàng đợi Tin nhắn Nâng cao (Mô hình AMQ)...........................
1.4.4. Giao thức xếp hàng tin nhắn nâng cao (AMQP)......................................
1.4.5. Quy mô Triển khai....................................................................................
1.4.6. Phạm vi chức năng...................................................................................
1.4.7. Cấu trúc tài liệu này.................................................................................
1.5. Quy ước...........................................................................................................18
1.5.1. Hướng dẫn cho Người triển khai..............................................................
1.5.2. Đánh số phiên bản...................................................................................
1.5.3. Thuật ngữ kỹ thuật...................................................................................

CHƯƠNG 2. GIAO THỨC AMQP.......................................................................................
2.1. Kiến trúc chung..............................................................................................22
2.1.1. Thực thể chính..........................................................................................
2.1.2. Exchanges Trao đổi..................................................................................
2.1.2.3.4 Xây dựng hàng đợi dùng chung...........................................................
2.2. Kiến trúc lệnh AMQP....................................................................................33
2.2.1. Lệnh giao thức (Lớp & Phương thức)......................................................
2.2.2. Ánh xạ AMQP tới API phần mềm trung gian...........................................
2.2.3. Không có xác nhận...................................................................................
2.2.4. Lớp kết nối...............................................................................................
2.2.5. Lớp kênh...................................................................................................
2.2.6. Lớp trao đổi.............................................................................................
2.2.7. Lớp xếp hang............................................................................................
2.2.8. Lớp cơ bản...............................................................................................
2.2.9. Lớp giao dịch...........................................................................................
2.3. Kiến trúc giao thông AMQP..........................................................................38
2.3.1. Mô tả chung.............................................................................................
2.3.2. Các kiểu dữ liệu......................................................................................
2.3.3. Đàm phán giao thức.................................................................................
2.3.4. Khung phân định......................................................................................
2.3.5. Xử lý lỗi....................................................................................................
2.3.6. Đóng kênh và kết nối................................................................................
2.4. Kiến trúc máy khách AMQP.........................................................................43
CHƯƠNG 3. ĐẶC ĐIỂM KỸ THUẬT CHỨC NĂNG.......................................................
3.1. Đặc điểm kỹ thuật chức năng máy chủ........................................................45
3.1.1. Thông điệp và nội dung............................................................................
3.1.2. Máy chủ ảo...............................................................................................
3.1.3. Trao đổi....................................................................................................

3.1.4. Hàng đợi tin nhắn....................................................................................
3.1.5. Bindings...................................................................................................
3.1.6. Người tiêu dùng........................................................................................
3.1.7. Chất lượng dịch vụ (QoS).........................................................................
3.1.8. Acknowledgements (ACK)........................................................................
3.1.9. Kiểm soát lưu lượng.................................................................................
3.1.10. Quy ước đặt tên....................................................................................
3.2. Đặc tả lệnh AMQP (Lớp & Phương pháp)..................................................70
3.2.1. Ghi chú giải thích.....................................................................................
3.2.2. Chi tiết lớp và phương thức......................................................................
3.3. Thông số kỹ thuật...........................................................................................72
3.3.1. Số cổng được gán IANA...........................................................................
3.3.2. Định dạng cấp dây AMQP.......................................................................

CHƯƠNG 1. GIỚI THIỆU CHUNG
1.1. TỔNG QUAN VỀ IOT
1.1.1. Khái niệm IoT

IoT là tên viết tắt của Internet of Things có nghĩa là Internet vạn vật. Hay cụ thể hơn nữa
thì có thể gọi đây là Mạng lưới vạn vật kết nối Internet hoặc Mạng lưới thiết bị kết nối Internet.
Là một hệ thống mạng lưới trong đó các thiết bị vật lý được kết nối với internet và có khả năng
giao tiếp với nhau. Mục tiêu của IoT là tạo ra một môi trường thông tin toàn cầu, nơi mà các
đối tượng từ các thiết bị nhỏ như cảm biến đến các hệ thống lớn như xe thông minh có thể thu
thập, chia sẻ, và xử lý dữ liệu mà không cần sự can thiệp trực tiếp của con người.
Các thiết bị Internet of Things có thể là đồ vật được gắn thêm cảm biến để thu thập dữ
liệu về môi trường xung quanh, các máy tính, bộ điều khiển tiếp nhận dữ liệu và ra lệnh cho
các thiết bị khác hoặc là các đồ vật được tích hợp cả hai tính năng trên.
Ngày nay, các doanh nghiệp trong nhiều ngành nghề khác nhau đang sử dụng Internet of
Things (IoT) để hoạt động hiệu quả hơn, hiểu rõ hơn về khách hàng, để cung cấp dịch vụ khách
hàng nâng cao, cải thiện khả năng ra quyết định và gia tăng giá trị cho doanh nghiệp.
1.1.2. Cấu trúc của một hệ thống IoT

- Hệ thống IoT có thể được chia thành 5 thành phần chính bao gồm:
+ Thiết bị IoT (IoT devices): Đây là các thiết bị vật lý được kết nối với internet, được
trang bị cảm biến và có khả năng thu thập và truyền thông dữ liệu. Các thiết bị này
có thể là cảm biến nhiệt độ, đèn thông minh, thiết bị đo khoảng cách, và nhiều loại
thiết bị khác.
+ Kết nối (connectivity): Đây là thành phần cung cấp khả năng kết nối giữa các thiết
bị IoT với nhau và với Internet. Kết nối IoT có thể sử dụng các công nghệ khác
nhau, VD như Wi-Fi, Bluetooth, Zigbee, LoRa, …
+ Cơ sở hạ tầng (infrastructure): Đây là thành phần cung cấp nền tảng cho hoạt động
của hệ thống IoT. Cơ sở hạ tầng IoT bao gồm các yếu tố như mạng lưới, trung tâm
dữ liệu, …
+ Dữ liệu (data): Đây là thành phần quan trọng nhất của hệ thống IoT. Dữ liệu được
thu thập từ các thiết bị IoT được sử dụng để phân tích, ra quyết định và thực hiện
các hành động.

+ Ứng dụng (applications): Đây là thành phần sử dụng dữ liệu từ các thiết bị IoT để
cung cấp các giá trị cho người dùng. Ứng dụng IoT có thể được sử dụng trong các
lĩnh vực khác nhau, chẳng hạn như sản xuất, nông nghiệp, chăm sóc sức khỏe, …
1.1.3. Cách hoạt động của IoT

- Mọi hệ thống IoT hoàn chỉnh đều hoạt động qua 4 bước:
+ Thu thập dữ liệu:
• Các thiết bị IoT được trang bị cảm biến để thu thập dữ liệu
từ môi trường xung quanh. Các loại dữ liệu có thể bao gồm
nhiệt độ, độ ẩm, ánh sáng, áp suất, chuyển động, và nhiều
thông tin khác.
• Dữ liệu này sau đó được chuyển đến các nút trung tâm hay
thiết bị thu thập dữ liệu (Data Collection Hub).
+ Chia sẻ dữ liệu: Nhờ cảm biến/ thiết bị được kết nối Internet, dữ liệu được chia sẻ
thông qua bộ lưu trữ đám mây.
+ Xử lý dữ liệu: Dữ liệu trên bộ lưu trữ đám mây được hệ thống máy tính xử lý. Máy
tính tự đưa ra quyết định hoặc gửi kết quả tới người dùng.
+ Đưa ra quyết định: Người dùng nhận dữ liệu qua email, thông báo, … và có thể dựa
vào đó để đưa ra điều chỉnh thông qua một bộ giao diện.
Hệ thống IoT bao gồm các thiết bị thông minh hỗ trợ web sử dụng hệ thống nhúng (như
bộ xử lý, cảm biến và phần cứng truyền thông) để thu thập, gửi và xử lý trên dữ liệu mà chúng
thu thập được. Các thiết bị IoT chia sẻ dữ liệu cảm biến thu thập được bằng cách kết nối với
cổng IoT hoặc thiết bị biên khác, nơi dữ liệu được gửi đến đám mây để phân tích hoặc phân
tích cục bộ.
Đôi khi, các thiết bị này giao tiếp với các thiết bị liên quan khác và hoạt động dựa trên
thông tin chúng nhận được từ nhau. Các thiết bị thực hiện hầu hết công việc mà không có sự
can thiệp của con người, mặc dù mọi người có thể tương tác với các thiết bị. Internet of Things
cũng có thể tận dụng trí tuệ nhân tạo (AI) và Machine Learning (máy học) để hỗ trợ quá trình
thu thập dữ liệu trở nên dễ dàng và linh hoạt hơn.
Các công nghệ sử dụng trong IoT.

- Các công nghệ được sử dụng trong lĩnh vực IoT rất đa dạng và liên quan đến cả phần
cứng và phần mềm. Dưới đây là một số công nghệ quan trọng thường được áp dụng
trong hệ thống IoT:
Giao thức Kết Nối:
- Wi-Fi: Cho các thiết bị có nguồn năng lượng đủ, đòi hỏi băng thông cao.
- Bluetooth và Bluetooth Low Energy (BLE): Thích hợp cho các thiết bị di động và có
nguồn năng lượng hạn chế.
- Zigbee và Z-Wave: Sử dụng cho các mạng cảm biến và điều khiển trong nhà thông
minh.
- LoRa (Long Range): Được sử dụng cho ứng dụng truyền thông từ xa, như quản lý
trong ngành nông nghiệp thông minh.
Giao thức Truyền Thông:
- AMQP (Advanced Message Queuing Protocol) giao thức giao tiếp được sử dụng trong
các hệ thống tin nhắn. Nó cho phép các hệ thống gửi và nhận tin nhắn một cách chính
xác và bảo đảm
- MQTT (Message Queuing Telemetry Transport): Giao thức nhắn tin nhẹ và hiệu quả
cho truyền thông máy-máy.
- CoAP (Constrained Application Protocol): Thiết kế cho các thiết bị có tài nguyên hạn
chế và kết nối không đồng bộ.
- HTTP/HTTPS: Sử dụng cho việc tương tác với các ứng dụng web và dịch vụ trực
tuyến.
Phần Cứng IoT:
- Cảm biến và Bộ Cảm Biến: Bao gồm nhiều loại như cảm biến nhiệt độ, độ ẩm, ánh
sáng, chuyển động, và nhiều loại khác.
- Module IoT và Vi xử lý nhúng: Cho phép kết nối và xử lý dữ liệu trên thiết bị.
- RFID (Radio-Frequency Identification): Sử dụng để theo dõi và quản lý thông tin về vị
trí và cách chuyển động
Mạng và Bảo Mật:
- 5G: Cung cấp băng thông rộng và kết nối ổn định, thích hợp cho các ứng dụng yêu cầu
truyền tải dữ liệu lớn và độ trễ thấp.

- Blockchain: Được sử dụng để bảo mật và quản lý an toàn thông tin trên các thiết bị
IoT.
- SSL/TLS: Bảo mật kết nối truyền thông giữa các thiết bị và hệ thống trung
tâm. Phần Mềm và Phân Tích Dữ Liệu:
- Edge Computing: Xử lý dữ liệu ngay tại nguồn thu thập, giảm bớt độ trễ và tăng cường
bảo mật.
- Cloud Computing: Lưu trữ và xử lý dữ liệu tập trung trong đám mây, cung cấp linh
động cho các hệ thống lớn.
- Big Data và Analytics: Phân tích dữ liệu để tìm kiếm thông tin quan trọng và xu
hướng.
Trí Tuệ Nhân Tạo và Học Máy:
- Machine Learning (ML) và Deep Learning (DL): Sử dụng để phân tích và dự đoán
hành vi dữ liệu từ các thiết bị IoT.
- Edge AI: Triển khai mô hình ML và DL trực tiếp trên thiết bị để giảm độ trễ và tăng
cường bảo mật.
Các công nghệ này thường được kết hợp để tạo ra các hệ thống IoT mạnh mẽ, linh hoạt
và an toàn. Tùy thuộc vào ứng dụng cụ thể, sự lựa chọn giữa các công nghệ này có thể thay đổi
để đáp ứng các yêu cầu đặc biệt của dự án.
1.1.4. Ưu và nhược điểm của IoT

- Ưu điểm:
+ Khả năng truy cập thông tin từ mọi nơi, mọi lúc trên mọi thiết bị.
+ Cải thiện kết nối giữa các thiết bị điện tử.
+ Chuyển các gói dữ liệu qua mạng được kết nối tiết kiệm thời gian và tiền bạc.
+ Tự động hóa các nhiệm vụ giúp cải thiện chất lượng dịch vụ của doanh nghiệp và
giảm nhu cầu can thiệp của con người.
- Nhược điểm:

+ Khi số lượng thiết bị được kết nối ngày càng tăng và nhiều thông tin được chia sẻ
giữa các thiết bị, thì khả năng hacker có thể lấy cắp thông tin bí mật cũng tăng lên.
+ Việc thu thập và quản lý dữ liệu từ tất cả các thiết bị của các doanh nghiệp có quy
mô cũng sẽ là một thách thức lớn.
+ Nếu có lỗi trong hệ thống, có khả năng mọi thiết bị được kết nối sẽ bị hỏng.
+ Vì không có tiêu chuẩn quốc tế về khả năng tương thích cho IoT nên rất khó để các
thiết bị từ các nhà sản xuất khác nhau liên kết với nhau.
1.1.5. Lợi ích của IoT

- Trong cuộc sống:
+ Internet vạn vật có ảnh hưởng sâu rộng đến cuộc sống và công việc, với IoT giúp
máy móc thực hiện công việc nặng nhọc và nhàm chán. VD như, thiết bị thông minh
có thể thay đổi thói quen buổi sáng bằng cách tự động chuẩn bị cà phê, mở rèm cửa,
đặt hàng thực phẩm và nấu ăn. Đồng hồ thông minh lên lịch họp, ô tô thông minh tự
động nạp nhiên liệu với GPS.
IoT mở ra tiềm năng không giới hạn trong cuộc sống hàng ngày.
- Đối với doanh nghiệp :
+ Đẩy nhanh quá trình đổi mới:
Internet vạn vật mở ra cơ hội cho doanh nghiệp tiếp cận phân tích
cao cấp để phát hiện những khía cạnh mới. VD như, thông qua việc
thu thập dữ liệu về hành vi của khách hàng, doanh nghiệp có thể tạo
ra chiến dịch tiếp thị chính xác.
+ Chuyển đổi dữ liệu thành thông tin chuyên sâu và hành động bằng AI và ML:
Dữ liệu lịch sử và xu hướng có thể được sử dụng để dfi đoán tương
lai, như việc kết hợp thông tin bảo hành và dữ liệu IoT để dfi đoán sfi
cố bảo trì. Điều này giúp cung cấp dịch vụ khách hàng chủ động và
xây dfing lòng trung thành.
+ Tăng cường tính bảo mật:

Giám sát liên tục cả cơ sở hạ tầng kỹ thuật số và vật lý có thể tối ưu
hóa hiệu suất, cải thiện hiệu quả và giảm rủi ro.
VD: dữ liệu từ thiết bị giám sát có thể kết hợp với thông tin phần
cứng để tfi động cập nhật hệ thống.
+ Đưa ra các giải pháp khác biệt:

Công nghệ IoT có thể được áp dụng để tập trung vào khách hàng và
nâng cao hài lòng, chẳng hạn như bổ sung sản phẩm bán chạy kịp
thời để tránh tình trạng thiếu hụt hàng hóa.
Ví dụ về các thiết bị IoT?

- Thermostat thông minh:
+ Thiết bị điều chỉ nhiệt độ trong nhà thông minh, có khả năng tự động điều chỉ dựa
trên lịch trình, điều kiện thời tiết và thậm chí là sở thích của người sử dụng.
- Đèn thông minh:
+ Đèn có khả năng kết nối với mạng và có thể được điều khiển từ xa thông qua điện
thoại di động hoặc bằng cách tự động thay đổi độ sáng và màu sắc dựa trên điều
kiện môi trường.
- Camera an ninh thông minh:
+ Các camera an ninh có khả năng kết nối internet, cung cấp khả năng theo dõi từ xa,
nhận dạng khuôn mặt và gửi cảnh báo khi phát hiện sự cố.
- Tủ lạnh thông minh:
+ Tủ lạnh có khả năng kết nối internet, cung cấp thông tin về nhiệt độ, tồn kho thực
phẩm, và thậm chí có thể tạo danh sách mua sắm thông qua ứng dụng điện thoại.
- Bình nước thông minh:
+ Bình nước có khả năng theo dõi lượng nước uống hàng ngày, đưa ra nhắc nhở và kết
nối với ứng dụng để theo dõi tiến trình sức khỏe.
- Cảm biến khói và khí CO thông minh:
+ Cảm biến có khả năng theo dõi chất khói và CO trong nhà, cung cấp cảnh báo và
thông báo tới người dùng qua điện thoại di động.
- Ứng dụng theo dõi vị trí (GPS):
6

+ Thiết bị di động sử dụng GPS để theo dõi vị trí, cung cấp dịch vụ định vị và thông
báo về vị trí của người sử dụng.
Các thiết bị này chỉ là một số ví dụ và không đại diện cho tất cả các ứng dụng của IoT.
Các loại thiết bị ngày càng đa dạng, và sự phát triển của IoT tiếp tục mang lại những đổi mới
và tiện ích mới trong cuộc sống hàng ngày.
Tổng quan về IoT trong công nghiệp.
- IoT trong công nghiệp (IIoT) là việc ứng dụng của thiết bị thông minh trong các lĩnh
vực như sản xuất, bán lẻ, y tế để tối ưu hóa hiệu quả kinh doanh. Các thiết bị công
nghiệp, từ cảm biến đến máy móc, cung cấp dữ liệu chi tiết theo thời gian thực để cải
thiện quản lý chuỗi cung ứng, kho vận, nguồn nhân lực và sản xuất, đồng thời giảm chi
phí và tăng doanh thu.
1.1.6. Các ứng dụng của IIoT trong các ngành khác nhau
- Sản xuất:
+ Sử dụng cảm biến để theo dõi tình trạng của các thiết bị máy móc trong sản xuất.
Giúp dự đoán thời gian bảo dưỡng để tránh sự cố và giảm thiểu thời gian ngừng
máy.
+ Sử dụng cảm biến để theo dõi môi trường làm việc và sự vận hành của nhân viên,
giúp cải thiện an toàn lao động và giảm nguy cơ tai nạn.
- Công nghiệp ô tô:
+ Phân tích dựa trên cảm biến và robot để tối ưu hóa trong quy trình sản xuất và bảo
dưỡng ô tô.
+ Sử dụng GPS và các cảm biến khác để theo dõi vị trí và tình trạng của xe ô tô. Điều
này hỗ trợ trong việc quản lý độ an toàn, giảm tai nạn giao thông và cải thiện hệ
thống định vị.
- Kho vận và vận tải:
+ Hỗ trợ quản lý chuỗi cung ứng, từ quản lý tồn kho đến bảo trì đội xe.
+ Theo dõi tài sản và tối ưu hóa tiêu thụ năng lượng trong vận chuyển.
- Bán lẻ:

+ IoT giúp theo dõi và quản lý hiệu suất của các chuỗi cung ứng, từ quá trình sản xuất,
hàng còn trong kho, hàng tồn cho đến giao hàng. Các cảm biến và thiết bị kết nối
giúp cải thiện sự minh bạch và định rõ vị trí của hàng hóa.
Ứng dụng công nghệ IoT dành cho người dùng và doanh nghiệp.
- Có rất nhiều ứng dụng trong thế giới thực của Internet vạn vật, từ IoT của người dùng,
IoT của doanh nghiệp cho đến IoT của các ngành sản xuất và công nghiệp (IIoT). Các
ứng dụng của IoT trải dài trên nhiều lĩnh vực bao gồm ô tô, viễn thông và năng lượng.
VD: Ở phân khúc người tiêu dùng, smart home (nhà thông minh) được
trang bị tính năng kiểm soát đèn, nhiệt độ, an ninh, và các thiết bị gia
đình khác từ xa thông qua điện thoại hoặc loa thông minh. Ví dụ: Hệ
thống Google Home, Amazon Alexa.
- Các thiết bị đeo có cảm biến và phần mềm có thể thu thập và phân tích dữ liệu người
dùng, gửi thông điệp tới các công nghệ khác về người dùng với mục đích làm cho cuộc
sống của người dùng dễ dàng và thoải mái hơn.
- Các thiết bị đeo được cũng được sử dụng vì mục đích an toàn công cộng. Cải thiện thời
gian phản ứng của những người ứng cứu đầu tiên trong các trường hợp khẩn cấp bằng
cách cung cấp các tuyến đường được tối ưu hóa đến một địa điểm hoặc bằng cách theo
dõi các dấu hiệu quan trọng của công nhân xây dựng hoặc lính cứu hỏa tại các địa điểm
nguy hiểm đến tính mạng.
- Trong lĩnh vực chăm sóc sức khỏe, IoT mang lại nhiều lợi ích, bao gồm khả năng theo
dõi bệnh nhân chặt chẽ hơn bằng cách sử dụng phân tích dữ liệu được tạo ra. Các bệnh
viện thường sử dụng hệ thống IoT để hoàn thành các nhiệm vụ như quản lý hàng tồn
kho cho cả dược phẩm và dụng cụ y tế.
- Trong một thành phố thông minh cũng tiến hành sử dụng công nghệ IoT, chẳng hạn
như đèn đường thông minh và đồng hồ thông minh, có thể giúp giảm kẹt xe, tiết kiệm
năng lượng, giám sát và giải quyết các mối quan tâm về môi trường cũng như cải thiện
vấn đề ô nhiễm môi trường.
VD: Các tòa nhà thông minh có thể giảm chi phí năng lượng bằng cách
sử dụng các cảm biến phát hiện có bao nhiêu người ở trong phòng. Tfi
động điều chỉnh nhiệt độ vd như: Bật máy điều hòa không khí nếu cảm
biến phát hiện phòng họp có người hoặc tắt khi mọi người đã rời văn
phòng.

- Trong nông nghiệp, các hệ thống canh tác thông minh dựa trên IoT có thể giúp theo
dõi, chẳng hạn như ánh sáng, nhiệt độ, độ ẩm và độ ẩm đất của ruộng trồng bằng cách
sử dụng các cảm biến được kết nối. IoT cũng là công cụ trong việc tự động hóa hệ
thống tưới tiêu.
- Quyền riêng tư và bảo mật IoT
- Quyền riêng tư và bảo mật là những vấn đề quan trọng khi nói đến triển khai công
nghệ Internet of Things (IoT). Do thông tin được thu thập và chia sẻ từ các thiết bị IoT
có thể chứa nhiều thông tin cá nhân và nhạy cảm, việc bảo vệ quyền riêng tư và đảm
bảo an toàn thông tin là vô cùng cần thiết. Dưới đây là một số điểm quan trọng liên
quan đến quyền riêng tư và bảo mật trong lĩnh vực IoT.
- Quyền riêng tư:
+ Thu Thập Dữ Liệu:
Người dùng cần được thông báo rõ ràng và đồng ý với việc thu
thập dữ liệu từ thiết bị IoT. Thông tin về mục đích sử dụng và loại
dữ liệu thu thập cũng cần được cung cấp.
+ Tự Quyết Định Quyền Riêng Tư:

Người dùng nên có quyền kiểm soát thông tin của mình. Họ cần có khả năng tắt
chức năng thu thập dữ liệu, xóa thông tin đã được thu thập và quyết định liệu dữ
liệu của họ có thể được chia sẻ hay không.
+ Anonymization và Pseudonymization:
Dữ liệu nên được giữ ẩn danh hoặc giả danh để bảo vệ danh tính cá
nhân. Điều này giúp giảm rủi ro liên quan đến việc xâm phạm
quyền riêng tư.
+ Bảo Mật Thiết Bị:
Thiết bị IoT cần có các biện pháp bảo mật mạnh mẽ để ngăn chặn
truy cập trái phép và sử dụng thông tin cá nhân một cách trái
phép.
+ Bảo mật:
• Mạng và Kết Nối:
Dữ liệu truyền qua mạng nên được mã hóa để ngăn chặn việc đọc
thông tin từ bên ngoài. Kết nối cũng cần được bảo vệ để ngăn chặn
9

tấn công mạng.
• Phần Mềm Bảo Mật:

Thiết bị IoT nên được trang bị phần mềm bảo mật mạnh mẽ để
ngăn chặn các loại tấn công như malware và ransomware.
• Cập Nhật Phần Mềm Định Kỳ:

Các bản vá và cập nhật bảo mật nên được triển khai định kỳ để
đảm bảo rằng thiết bị IoT luôn được bảo vệ chống lại các lỗ hổng
bảo mật mới.
• Quản Lý Khóa và Đăng Nhập:

Quản lý an toàn thông tin đăng nhập và mã xác minh là quan trọng
để ngăn chặn truy cập trái phép vào thiết bị.
• Quản Lý Dữ Liệu:
Bảo mật dữ liệu lưu trữ và xử lý trên thiết bị IoT là cfic kỳ quan
trọng. Cần có biện pháp để ngăn chặn truy cập trái phép và lưu trữ
dữ liệu an toàn.
• Chính Sách Bảo Mật:

Doanh nghiệp cần thiết lập chính sách bảo mật mạnh mẽ và giáo
dục người sử dụng về các biện pháp bảo mật cần được tuân theo.
Việc duy trì sự cân bằng giữa tiện ích và bảo mật là vô cùng quan trọng để chúng ta có
thể đảm bảo rằng IoT sẽ đem lại lợi ích mà không gây ra nguy cơ đối với quyền riêng tư
và an toàn thông tin cho người dùng.
1.2. TỔNG QUAN VỀ GIAO THỨC AMQP
1.2.1. Khái niệm AMQP

AMQP (Advanced Message Queuing Protocol) là một giao thức giao tiếp để gửi và nhận
tin nhắn giữa các hệ thống. Nó bảo đảm tin nhắn được gửi đến đúng hàng đợi và được xử lý
một cách chính xác. AMQP cung cấp các tính năng như giới hạn băng thông, giới hạn tải, và tự
động chuyển tiếp tin nhắn đến hệ thống khác nếu hệ thống gốc không thể xử lý tin nhắn đó.
10

1.2.2. Ưu điểm của AMQP
AMQP có những ưu điểm sau:
- Tính năng tin cậy:
+ AMQP bảo đảm rằng tin nhắn sẽ được gửi đến đúng hàng đợi và được xử lý một
cách chính xác, từ đó giúp ngăn chặn sự mất tin nhắn hoặc sự lặp lại tin nhắn.
- Tự động chuyển tiếp:
+ AMQP cung cấp tính năng tự động chuyển tiếp tin nhắn đến hệ thống khác nếu hệ
thống gốc không thể xử lý tin nhắn đó, từ đó giúp ngăn chặn sự gián đoạn trong quá
trình trao đổi tin nhắn.
- Giới hạn băng thông:
+ AMQP cung cấp tính năng giới hạn băng thông, giúp ngăn chặn sự quá tải trong hệ
thống tin nhắn.
- Đa nền tảng:
+ AMQP là một giao thức mã nguồn mở, nó có thể chạy trên nhiều nền tảng khác
nhau và được sử dụng trong nhiều ngành nghề khác nhau.
- Scalability:
+ AMQP có thể mở rộng dễ dàng, từ đó giúp hệ thống của bạn tăng tốc độ và xử lý
lượng dữ liệu lớn hơn mà không gây ra sự gián đoạn hoặc sự quá tải trong hệ thống.
- Tách rời giữa gửi và nhận:
+ AMQP cho phép tách rời giữa việc gửi và nhận tin nhắn, từ đó giúp cho việc xử lý
tin nhắn trở nên dễ dàng hơn và giúp cho hệ thống hoạt động mượt mà hơn.
1.2.3. Giới thiệu chung về giao thức AMQP
AMQP hay giao thức xếp hàng thông tin nâng cao được tạo ra như một giao thức tiêu
chuẩn mở cho phép khả năng tương tác giữa các hệ thống thông tin, bất kể nhà cung cấp hoặc
nền tảng broker thông tin nào được sử dụng. Với AMQP, bạn có thể sử dụng bất kỳ thư viện
ứng dụng client tuân thủ AMQP nào bạn muốn và bất kỳ broker nào tuân thủ AMQP mà bạn
muốn.
AMQP là một giao thức lớp ứng dụng cho phép các ứng dụng client nói chuyện với
server và tương tác. Tuy nhiên, AMQP không chỉ được coi là một giao thức được sử dụng để
liên lạc qua dây. AMQP là cả giao thức lớp mạng và kiến trúc cấp cao cho các broker thông tin.
11

Nó xác định một tập hợp các khả năng thông tin phải được cung cấp bởi server tuân thủ
AMQP, bao gồm các quy tắc về cách thông tin phải được định tuyến và lưu trữ trong broker để
tuân theo mô hình AMQ.
AMQP là một giao thức lớp ứng dụng tập trung vào giao tiếp process-to-process trên các
mạng IP. Một lược đồ mã hóa và một tập hợp các thủ tục cho phép hai server khác nhau giao
tiếp với nhau bất kể công nghệ được sử dụng. Nhìn chung, mục tiêu của AMQP là cho phép
thông tin truyền qua các dịch vụ broker qua các kết nối TCP / IP. AMQP được coi là một giao
thức nhỏ gọn, vì nó là một giao thức nhị phân, có nghĩa là mọi thứ được gửi qua AMQP đều là
dữ liệu nhị phân. Giao thức nhị phân tránh gửi dữ liệu vô ích qua dây.
Các thành phần của AMQP
- Hàng đợi thông tin
+ Hàng đợi hoạt động như một bộ đệm lưu trữ các thông tin được sử dụng sau này.
Hàng đợi cũng có thể được khai báo với một số thuộc tính trong quá trình tạo. Ví
dụ: nó có thể được đánh dấu là lâu bền, tự động xóa và độc quyền, trong đó độc
quyền có nghĩa là nó chỉ có thể được sử dụng bởi một kết nối và hàng đợi này sẽ bị
xóa khi kết nối đó đóng.
- Trao đổi và các loại trao đổi
+ Một kênh định tuyến các thông điệp đến một hàng đợi tùy thuộc vào loại trao đổi và
các ràng buộc giữa trao đổi và hàng đợi. Đối với một hàng đợi để nhận thông tin, nó
phải được ràng buộc với ít nhất một trao đổi.
+ Các broker AMQP 0.9.1 cung cấp bốn loại trao đổi - trao đổi trực tiếp, trao đổi
fanout, trao đổi chủ đề và trao đổi tiêu đề.
+ Một trao đổi có thể được khai báo với một số thuộc tính trong quá trình tạo. Ví dụ:
nó có thể được đánh dấu là bền để nó tồn tại sau khi khởi động lại broker hoặc nó có
thể được đánh dấu là tự động xóa nghĩa là nó sẽ tự động bị xóa khi hàng đợi cuối
cùng không bị ràng buộc.
- Ràng buộc
+ Ràng buộc là một quan hệ giữa hàng đợi và một trao đổi bao gồm một tập hợp các
quy tắc mà trao đổi sử dụng (trong số những thứ khác) để định tuyến thông điệp đến
hàng đợi.
- Thông tin và Nội dung
12

+ Thông tin là một thực thể được gửi từ publisher đến hàng đợi và cuối cùng được
người tiêu dùng đăng ký. Mỗi thông tin chứa một tập hợp các tiêu đề xác định các
thuộc tính như tuổi thọ, độ bền và mức độ ưu tiên.
+ AMQP 0.9.1 cũng có một tính năng tích hợp được gọi là xác nhận tin nhắn được sử
dụng để xác nhận việc gửi hoặc xử lý tin nhắn.
- Kết nối
+ Kết nối trong AMQP 0.9.1 là kết nối mạng giữa ứng dụng của bạn và AMQP broker
ví dụ: kết nối TCP / IP socket.
- Kênh
+ Kênh là một kết nối ảo bên trong một kết nối, giữa hai AMQP peer. Việc xuất bản
hoặc gửi thông tin đến hoặc từ hàng đợi được thực hiện qua một kênh (AMQP). Một
kênh được ghép nối, một kết nối đơn lẻ có thể có nhiều kênh.
- Máy chủ ảo
+ Máy chủ ảo (vhost) là cách để tách biệt các ứng dụng trong broker. Những người
dùng khác nhau có thể có các đặc quyền truy cập khác nhau vào các vhost khác
nhau. Hàng đợi và trao đổi được tạo để chúng chỉ tồn tại trong một vhost.
1.3. MỤC TIÊU CỦA TÀI LIỆU
Tài liệu này xác định một giao thức mạng, Giao thức Hàng đợi Tin nhắn
Nâng cao (AMQP), cho phép các ứng dụng khách tuân thủ giao tiếp với các
máy chủ phần mềm trung gian nhắn tin tuân thủ. Chúng tôi hướng đến đối
tượng là các chuyên gia kỹ thuật có kinh nghiệm trong lĩnh vfic này và
chúng tôi cung cấp các thông số kỹ thuật và hướng dẫn đầy đủ để một kỹ
sư có kỹ năng phù hợp có thể xây dfing các giải pháp tuân thủ bằng bất kỳ
ngôn ngữ lập trình hoặc nền tảng phần cứng hiện đại nào.
1.4. TỔNG QUAN
1.4.1. Tại sao chọn AMQP?

AMQP tạo ra khả năng tương thích hoàn toàn giữa các máy khách tuân thủ và máy chủ
trung gian nhắn tin (còn gọi là "bộ trung gian").
Mục tiêu của chúng tôi là cho phép phát triển và sử dụng rộng rãi trong ngành công
nghiệp công nghệ phần mềm trung gian nhắn tin tiêu chuẩn hóa, do đó sẽ giảm chi phí tích hợp
doanh nghiệp và hệ thống, đồng thời cung cấp các dịch vụ tích hợp cấp công nghiệp cho một
13

đối tượng rộng. Mục tiêu của chúng tôi là thông qua AMQP, cuối cùng khả năng trung gian
nhắn tin có thể được tích hợp vào chính mạng và sự phổ biến rộng rãi của phần mềm trung gian
nhắn tin sẽ tạo điều kiện cho việc phát triển các loại ứng dụng hữu ích mới.
1.4.2. Phạm vi của AMQP
Để cho phép khả năng tương tác hoàn toàn cho phần mềm trung gian nhắn tin yêu cầu cả
giao thức mạng và ngữ nghĩa của các dịch vụ phía máy chủ phải được chỉ định đầy đủ. Do đó,
AMQP xác định cả giao thức mạng và các dịch vụ phía máy chủ thông qua:
- Một tập hợp các khả năng nhắn tin được xác định được gọi là "Mô hình Giao
thức Hàng đợi Tin nhắn Nâng cao" (mô hình AMQ). Mô hình AMQ bao gồm một
tập hợp các thành phần định tuyến và lưu trữ các tin nhắn trong dịch vụ môi giới, cùng
với một tập hợp các quy tắc để kết nối các thành phần này với nhau.
- Một giao thức cấp mạng, AMQP, cho phép các ứng dụng khách giao tiếp với máy
chủ và tương tác với mô hình AMQ mà máy chủ triển khai.
Người ta có thể suy luận một phần ngữ nghĩa của máy chủ từ các thông số kỹ thuật của
giao thức AMQP, nhưng chúng tôi tin rằng việc mô tả rõ ràng các ngữ nghĩa này sẽ giúp hiểu
rõ hơn về giao thức.
1.4.3. Mô hình Hàng đợi Tin nhắn Nâng cao (Mô hình AMQ)
Chúng tôi xác định rõ ràng ngữ nghĩa của máy chủ vì khả năng tương tác yêu cầu chúng
phải giống nhau trong bất kỳ triển khai máy chủ nào. Do đó, mô hình AMQ chỉ định một tập
hợp các thành phần mô-đun và các quy tắc chuẩn để kết nối chúng. Có ba loại thành phần
chính, được kết nối thành các chuỗi xử lý trong máy chủ để tạo ra chức năng mong muốn:
- "Exchange" (Bộ chuyển mạch): tiếp nhận tin nhắn từ các ứng dụng nhà xuất bản và
định tuyến chúng đến các "hàng đợi tin nhắn", dựa trên các tiêu chí tùy ý, thường là
thuộc tính hoặc nội dung tin nhắn.
- "Message queue" (Hàng đợi tin nhắn): lưu trữ tin nhắn cho đến khi chúng có thể
được xử lý an toàn bởi một ứng dụng khách sử dụng (hoặc nhiều ứng dụng).
- "Binding" (Ràng buộc): xác định mối quan hệ giữa một hàng đợi tin nhắn và một
exchange, đồng thời cung cấp các tiêu chí định tuyến tin nhắn.
Sử dụng mô hình này, chúng ta có thể mô phỏng dễ dàng các khái niệm trung gian nhắn
tin cổ điển về hàng đợi lưu trữ và chuyển tiếp và đăng ký chủ đề. Chúng ta cũng có thể thể hiện
14

các khái niệm ít phổ biến hơn như định tuyến dựa trên nội dung, phân phối khối lượng công
việc và hàng đợi tin nhắn theo yêu cầu
Nói một cách đơn giản, một máy chủ AMQP tương tự như một máy chủ email, với mỗi
exchange hoạt động như một tác nhân truyền tin và mỗi hàng đợi tin nhắn như một hộp thư.
Các ràng buộc xác định các bảng định tuyến trong mỗi tác nhân chuyển giao. Nhà xuất bản
gửi tin nhắn đến các tác nhân chuyển giao riêng lẻ, sau đó định tuyến các tin nhắn vào các hộp
thư. Người tiêu dùng lấy tin nhắn từ hộp thư. Ngược lại, trong nhiều hệ thống phần mềm trung
gian trước AMQP, nhà xuất bản gửi tin nhắn trực tiếp đến các hộp thư riêng lẻ (trong trường
hợp hàng đợi lưu trữ và chuyển tiếp) hoặc đến danh sách gửi thư (trong trường hợp đăng ký
chủ đề).
Sự khác biệt là khi các quy tắc kết nối hàng đợi tin nhắn với exchange nằm dưới sự kiểm
soát của kiến trúc sư (thay vì được nhúng trong mã), nó trở nên có thể thực hiện những điều thú
vị, chẳng hạn như xác định một quy tắc nói rằng, "đặt một bản sao của tất cả các tin nhắn chứa
tiêu đề như-và-như-vậy vào hàng đợi tin nhắn này".
Thiết kế của mô hình AMQ được thúc đẩy bởi các yêu cầu chính sau:
- Hỗ trợ ngữ nghĩa có thể so sánh với các sản phẩm nhắn tin chính.
- Cung cấp mức hiệu suất có thể so sánh với các sản phẩm nhắn tin chính.
- Cho phép ứng dụng lập trình ngữ nghĩa cụ thể của máy chủ thông qua giao thức.
- Linh hoạt và có thể mở rộng, nhưng đơn giản.
1.4.4. Giao thức xếp hàng tin nhắn nâng cao (AMQP)
- Giao thức AMQP là giao thức nhị phân với các tính năng hiện đại: đa kênh, được đàm
phán,
- không đồng bộ, an toàn, di động, trung lập và hiệu quả. AMQP được chia thành hai lớp
một cách hữu ích:
15

Lớp chức năng xác định một tập hợp các lệnh (được nhóm thành các lớp chức năng logic)
thực hiện công việc hữu ích thay mặt cho ứng dụng.
Lớp truyền tải chịu trách nhiệm truyền tải các lệnh này từ ứng dụng đến máy chủ và
ngược lại, đồng thời xử lý ghép kênh kênh, đóng khung, mã hóa nội dung, nhịp tim, biểu diễn
dữ liệu và xử lý lỗi.
Có thể thay thế lớp truyền tải bằng các phương thức truyền tải tùy ý mà không làm thay
đổi chức năng hiển thị của ứng dụng trong giao thức. Cũng có thể sử dụng cùng một lớp truyền
tải cho các giao thức cấp cao khác nhau.
Thiết kế của mô hình AMQ được thúc đẩy bởi các yêu cầu sau:
- Đảm bảo khả năng tương tác giữa các triển khai tuân thủ.
- Cung cấp quyền kiểm soát rõ ràng đối với chất lượng dịch vụ.
- Nhất quán và rõ ràng trong việc đặt tên.
- Cho phép cấu hình hoàn toàn hệ thống máy chủ thông qua giao thức.
- Sử dụng ký hiệu lệnh dễ dàng ánh xạ vào các API cấp ứng dụng.
- Rõ ràng, để mỗi thao tác chỉ thực hiện một việc duy nhất.
Thiết kế của lớp truyền tải AMQP được thúc đẩy bởi các yêu cầu chính sau, không theo
thứ tự cụ thể:
- Nhỏ gọn, sử dụng mã hóa nhị phân để đóng gói và giải nén nhanh chóng.
- Xử lý tin nhắn với mọi kích thước mà không có giới hạn đáng kể.
- Mang nhiều kênh qua một kết nối duy nhất.
- Tồn tại lâu dài, không có giới hạn tích hợp đáng kể.
16

- Cho phép đường ống lệnh không đồng bộ.
- Để dễ dàng mở rộng để xử lý các nhu cầu mới và thay đổi.
- Để tương thích với các phiên bản tương lai.

- Có thể sửa chữa, sử dụng mô hình xác nhận mạnh mẽ.
- Trung lập đối với các ngôn ngữ lập trình.
- Phù hợp với quy trình tạo mã.
1.4.5. Quy mô Triển khai

Phạm vi của AMQP bao gồm các cấp độ quy mô khác nhau, đại khái như sau:
- Nhà phát triển/sử dụng thông thường: 1 máy chủ, 1 người dùng, 10 hàng đợi tin
nhắn, 1 tin nhắn mỗi giây.
- Ứng dụng sản xuất: 2 máy chủ, 10-100 người dùng, 10-50 hàng đợi tin nhắn, 10 tin
nhắn mỗi giây (36.000 tin nhắn/giờ).
- Ứng dụng quan trọng cấp bộ phận: 4 máy chủ, 100-500 người dùng, 50-100 hàng
đợi tin nhắn, 100 tin nhắn mỗi giây (360.000/giờ).
- Ứng dụng quan trọng cấp khu vực: 16 máy chủ, 500-2.000 người dùng, 100-500
hàng đợi tin nhắn và chủ đề, 1.000 tin nhắn mỗi giây (3,6 triệu/giờ).
- Ứng dụng quan trọng cấp toàn cầu: 64 máy chủ, 2.000-10.000 người dùng, 500-
1.000 hàng đợi tin nhắn và chủ đề, 10.000 tin nhắn mỗi giây (36 triệu/giờ).
- Dữ liệu thị trường (giao dịch): 200 máy chủ, 5.000 người dùng, 10.000 chủ đề,
100.000 tin nhắn mỗi giây (360 triệu/giờ).
Bên cạnh khối lượng, độ trễ của việc truyền tin nhắn cũng có thể rất quan trọng. Ví dụ, dữ
liệu thị trường mất giá trị rất nhanh. Các triển khai có thể phân biệt bản thân bằng cách cung
cấp các Chất lượng dịch vụ hoặc Khả năng quản lý khác nhau trong khi vẫn tuân thủ hoàn toàn
với đặc tả này.
1.4.6. Phạm vi chức năng
Chúng tôi muốn hỗ trợ nhiều kiến trúc nhắn tin khác nhau:
- Lưu trữ và chuyển tiếp với nhiều người gửi và một người nhận: Kiểu này phù hợp
cho các trường hợp dữ liệu cần được truyền đi và lưu trữ để người nhận có thể truy cập
sau.
17

- Phân phối khối lượng công việc với nhiều người gửi và nhiều người nhận: Kiểu
này sử dụng nhiều người gửi để phân tán khối lượng công việc và nhiều người nhận để
xử lý đồng thời, thích hợp cho các tác vụ lớn.
- Xuất bản-đăng ký với nhiều người gửi và nhiều người nhận: Kiểu này cho phép
một người gửi (nhà xuất bản) gửi dữ liệu cho nhiều người nhận (đăng ký) đã đăng ký
quan tâm đến chủ đề đó.
- Định tuyến dựa trên nội dung với nhiều người gửi và nhiều người nhận: Kiểu này
định tuyến tin nhắn dựa trên nội dung của tin nhắn, cho phép gửi tin nhắn đến các
người nhận cụ thể dựa trên thông tin trong tin nhắn.
- Chuyển file theo hàng đợi với nhiều người gửi và nhiều người nhận: Kiểu này sử
dụng hàng đợi để lưu trữ file tạm thời trước khi gửi đến người nhận, đảm bảo truyền
file đáng tin cậy.
- Kết nối điểm-đến-điểm giữa hai thiết bị: Kiểu này thiết lập kết nối trực tiếp giữa hai
thiết bị để trao đổi dữ liệu, thường dùng cho các trường hợp cần truyền dữ liệu nhanh
chóng và đáng tin cậy.
- Phân phối dữ liệu thị trường với nhiều nguồn và nhiều người nhận: Kiểu này cho
phép phân phối dữ liệu thị trường từ nhiều nguồn (ví dụ: sàn giao dịch chứng khoán)
đến nhiều người nhận (ví dụ: các nhà đầu tư) một cách nhanh chóng và chính xác.
1.4.7. Cấu trúc tài liệu này
Tài liệu này được chia thành năm chương, hầu hết được thiết kế để đọc độc lập tùy theo
mức độ quan tâm của bạn:
- "Tổng quan" (chương này): Đọc chương này để biết phần giới thiệu.
- "Kiến trúc tổng quát": Chúng tôi mô tả kiến trúc và thiết kế tổng thể của
AMQP. Chương này nhằm giúp các kiến trúc sư hệ thống hiểu cách AMQP hoạt động.
- "Đặc tả chức năng": Chúng tôi định nghĩa cách các ứng dụng hoạt động với
AMQP. Chương này bao gồm một phần thảo luận dễ đọc, tiếp theo là một đặc tả chi
tiết về từng lệnh giao thức, được coi là tài liệu tham khảo cho những người triển khai.
Trước khi đọc chương này, bạn nên đọc Kiến trúc tổng quát.
- "Đặc tả kỹ thuật": Chúng tôi định nghĩa cách hoạt động của lớp truyền tải
AMQP. Chương này bao gồm một phần thảo luận ngắn, tiếp theo là một đặc tả chi tiết
về các cấu trúc cấp mạng, được coi là tài liệu tham khảo cho những người triển khai.
18

Bạn có thể đọc chương này riêng biệt nếu bạn muốn hiểu cách giao thức cấp mạng hoạt
động (nhưng không phải mục đích sử dụng của nó).
1.5. QUY ƯỚC
1.5.1. Hướng dẫn cho Người triển khai

- Chúng tôi sử dụng các thuật ngữ PHẢI, KHÔNG ĐƯỢC, NÊN, KHÔNG NÊN và
CÓ THỂ như được định nghĩa bởi IETF RFC 2119. Các thuật ngữ này có ý nghĩa
cụ thể trong việc xác định mức độ bắt buộc và khuyến nghị đối với các triển khai
AMQP.
- Chúng tôi sử dụng thuật ngữ "máy chủ" khi thảo luận về hành vi cụ thể được yêu
cầu của một máy chủ AMQP tuân thủ.
- Chúng tôi sử dụng thuật ngữ "máy khách" khi thảo luận về hành vi cụ thể được
yêu cầu của một máy khách AMQP tuân thủ.
- Chúng tôi sử dụng thuật ngữ "peer" để chỉ "máy chủ hoặc máy khách".
- Tất cả các giá trị số đều là thập phân trừ khi có quy định khác.
- Các hằng số giao thức được hiển thị dưới dạng tên viết hoa. Các triển khai AMQP
NÊN sử dụng các tên này khi xác định và sử dụng các hằng số trong mã nguồn và
tài liệu.
- Tên thuộc tính, đối số phương thức và trường khung được hiển thị dưới dạng tên
viết thường. Các triển khai AMQP NÊN sử dụng các tên này một cách nhất quán
trong mã nguồn và tài liệu.
- Các chuỗi trong AMQP phân biệt chữ hoa chữ thường. Ví dụ: "amq.Direct" chỉ
định một exchange khác với "amq.direct".
1.5.2. Đánh số phiên bản
Phiên bản AMQP được thể hiện bằng hai hoặc ba chữ số - số chính, số phụ và số hiệu
chỉnh tùy chọn. Theo quy ước, phiên bản được thể hiện dưới dạng chính-phụ[-sửa đổi] hoặc
chính.phụ[.sửa đổi]:
- Các số chính, phụ và sửa đổi có thể có giá trị từ 0 đến 99 cho các đặc tả chính thức.
- Các số chính, phụ và sửa đổi từ 100 trở lên được dành cho mục đích thử nghiệm và
phát triển nội bộ.
- Số phiên bản thể hiện khả năng tương tác về cú pháp và ngữ nghĩa.
19

- Phiên bản 0-9-1 được biểu diễn là chính = 0, phụ = 9, sửa đổi = 1.
- Phiên bản 1.1 sẽ được biểu diễn là chính = 1, phụ = 1, sửa đổi = 0. Viết "AMQP/1.1"
tương đương với viết "AMQP/1.1.0" hoặc AMQP/1-1-0.
1.5.3. Thuật ngữ kỹ thuật
Các thuật ngữ sau có ý nghĩa đặc biệt trong bối cảnh của tài liệu này:
Kiến trúc lệnh AMQP: Một lệnh giao thức cấp mạng được mã hóa thực hiện các hành
động trên trạng thái của Kiến trúc mô hình AMQ.
Kiến trúc mô hình AMQ: Một khung logic đại diện cho các thực thể chính và ngữ nghĩa
mà một triển khai máy chủ tuân thủ AMQP phải cung cấp, sao cho trạng thái máy chủ có thể
được điều khiển bởi máy khách để đạt được các ngữ nghĩa được xác định trong đặc tả này.
Kết nối: Một kết nối mạng, ví dụ như kết nối socket TCP/IP.
Kênh: Một luồng truyền thông hai chiều giữa hai AMQP peer. Các kênh được ghép kênh
để một kết nối mạng duy nhất có thể mang nhiều kênh.
Máy khách: Người khởi tạo kết nối hoặc kênh AMQP. AMQP không đối xứng. Máy
khách tạo và sử dụng thông điệp trong khi máy chủ xếp hàng và định tuyến thông điệp.
Máy chủ: Tiến trình chấp nhận các kết nối của máy khách và thực hiện các chức năng
xếp hàng và định tuyến thông điệp AMQP. Còn được gọi là "broker".
Peer: Một trong hai bên trong kết nối AMQP. Một kết nối AMQP chỉ bao gồm hai peer
(một là máy khách, một là máy chủ).
Frame: Một gói dữ liệu kết nối được xác định chính thức. Các frame luôn được ghi và
đọc liền kề - như một đơn vị duy nhất - trên kết nối.
Lớp giao thức: Một tập hợp các lệnh AMQP (còn được gọi là Phương thức) xử lý một
loại chức năng cụ thể.
Phương thức: Một loại khung lệnh AMQP cụ thể truyền các lệnh từ một peer sang
peer khác.
Nội dung: Dữ liệu ứng dụng được truyền từ máy khách sang máy chủ và từ máy chủ
sang máy khách. Thuật ngữ này đồng nghĩa với "message".
Tiêu đề nội dung: Một loại khung cụ thể mô tả các thuộc tính của nội dung.
20

Thân nội dung: Một loại khung cụ thể chứa dữ liệu ứng dụng thô. Các frame thân
nội dung hoàn toàn không rõ ràng - máy chủ không kiểm tra hoặc sửa đổi chúng theo bất kỳ
cách nào.
Message: Đồng nghĩa với "nội dung".
Exchange: Thực thể bên trong máy chủ nhận messages từ các ứng dụng producer và
có thể định tuyến chúng đến các message queue trong máy chủ.
Loại exchange: Thuật toán và triển khai của một mô hình exchange cụ thể. Ngược
lại với "instance exchange", là thực thể nhận và định tuyến messages bên trong máy chủ.
Message queue: Một thực thể được đặt tên để lưu giữ messages và chuyển tiếp
chúng đến các ứng dụng consumer.
Binding: Một thực thể tạo ra mối quan hệ giữa một message queue và một exchange.
Routing key: Một địa chỉ ảo mà một exchange có thể sử dụng để quyết định cách
định tuyến một message cụ thể.
Bền vững (Durable): Tài nguyên máy chủ tồn tại sau khi khởi động lại máy chủ.
Tạm thời (Transient): Tài nguyên máy chủ hoặc message bị xóa hoặc đặt lại sau
khi khởi động lại máy chủ.
Bền bỉ (Persistent): Một message mà máy chủ lưu trữ trên bộ nhớ đĩa đáng tin
cậy và KHÔNG ĐƯỢC mất sau khi khởi động lại máy chủ.
Consumer: Một ứng dụng client yêu cầu messages từ một message queue.
Producer: Một ứng dụng client xuất bản messages đến một exchange.
Virtual host: Một tập hợp các exchange, message queue và các đối tượng liên quan.
Virtual host là các miền máy chủ độc lập chia sẻ môi trường xác thực và mã hóa chung.
Assertion: Một điều kiện phải đúng để quá trình tiếp tục.
Exception: Một assertion thất bại, được xử lý bằng cách đóng Channel hoặc
Connection.
Các thuật ngữ sau không có ý nghĩa đặc biệt trong ngữ cảnh
của AMQP:
- Topic (Chủ đề): Thường là một phương tiện để phân phối tin nhắn; AMQP triển
khai các chủ đề bằng cách sử dụng một hoặc nhiều loại exchange (trung tâm trao đổi).
21

- Subscription (Đăng ký): Thường là một yêu cầu để nhận dữ liệu từ các chủ
đề; AMQP triển khai các đăng ký dưới dạng message queue (hàng đợi tin nhắn) và
binding (liên kết).
- Service (Dịch vụ): Thường đồng nghĩa với server (máy chủ). AMQP sử dụng
thuật ngữ "server" để phù hợp với danh pháp tiêu chuẩn của IETF.
- Broker: Đồng nghĩa với server. AMQP sử dụng các thuật ngữ "client" (máy khách)
và "server" để phù hợp với danh pháp tiêu chuẩn của IETF.
- Router (Bộ định tuyến): Đôi khi được sử dụng để mô tả các hành động của
một exchange. Các exchange cũng có thể hoạt động như điểm cuối tin nhắn và "router"
có ý nghĩa đặc biệt trong lĩnh vực mạng, vì vậy AMQP không sử dụng thuật ngữ này.
22

CHƯƠNG 2. GIAO THỨC AMQP
2.1. KIẾN TRÚC CHUNG
Phần này giải thích các ngữ nghĩa máy chủ phải được chuẩn hóa để đảm bảo khả năng
tương tác giữa các triển khai AMQP
2.1.1. Thực thể chính
Sơ đồ này hiển thị mô hình AMQ tổng thể:
Chúng ta có thể tóm tắt rằng một máy chủ trung gian là một máy chủ dữ liệu chấp nhận
tin nhắn và thực hiện hai việc chính với chúng, đó là định tuyến chúng đến các người tiêu dùng
khác nhau tùy thuộc vào các tiêu chí tùy ý và lưu trữ chúng trong bộ nhớ hoặc trên đĩa khi
người tiêu dùng không thể chấp nhận chúng đủ nhanh.
Trong một máy chủ trước AMQP, các nhiệm vụ này được thực hiện bởi các động cơ
đơnolithic thực hiện các loại định tuyến và lưu trữ cụ thể. Mô hình AMQ tiếp cận với các mảnh
nhỏ hơn, có thể kết hợp theo cách đa dạng và mạnh mẽ hơn. Nó bắt đầu bằng cách chia các
nhiệm vụ này thành hai vai trò khác nhau
Có hai thành phần chính trong AMQP để xử lý tin nhắn: exchange và message queue.
- - Exchange chấp nhận tin nhắn từ nhà sản xuất và định tuyến chúng đến các hàng đợi
tin nhắn.
- - Message queue lưu trữ tin nhắn và chuyển tiếp chúng đến các ứng dụng tiêu thụ. Có
một giao diện rõ ràng giữa exchange và message queue, được gọi là “binding” 1.
AMQP cung cấp các ngữ nghĩa có thể chạy được tại thời điểm chạy, thông qua hai khía
cạnh chính:
23

+ Khả năng tạo các loại exchange và message queue tùy ý tại thời điểm chạy thông
qua giao thức (một số được định nghĩa trong tiêu chuẩn, nhưng các loại khác có thể
được thêm vào như các tiện ích mở rộng của máy chủ).
+ Khả năng kết nối các exchange và message queue với nhau tại thời điểm chạy thông
qua giao thức để tạo bất kỳ hệ thống xử lý tin nhắn nào cần thiết
2.1.1.1 The Message Queue ( Hàng đợi tin nhắn )
Một hàng đợi tin nhắn lưu trữ các tin nhắn trong bộ nhớ hoặc trên đĩa, và chuyển chúng
theo thứ tự đến một hoặc nhiều ứng dụng tiêu thụ. Hàng đợi tin nhắn là các thực thể lưu trữ và
phân phối tin nhắn. Mỗi hàng đợi tin nhắn hoàn toàn độc lập và là một đối tượng khá thông
minh.
Một hàng đợi tin nhắn có nhiều thuộc tính: riêng tư hoặc chia sẻ, bền vững hoặc tạm thời,
được đặt tên bởi khách hàng hoặc máy chủ, v.v. Bằng cách chọn các thuộc tính mong muốn,
chúng ta có thể sử dụng hàng đợi tin nhắn để triển khai các thực thể trung gian thông thường
như:
- Một hàng đợi lưu trữ và chuyển tiếp (store-and-forward queue) được chia sẻ, giữ các
tin nhắn và phân phối chúng giữa các người tiêu dùng theo cơ chế round-robin. Hàng
đợi lưu trữ và chuyển tiếp thường bền vững và được chia sẻ giữa nhiều người tiêu
dùng.
- Một hàng đợi trả lời riêng tư (private reply queue) , giữ các tin nhắn và chuyển tiếp
chúng đến một người tiêu dùng duy nhất. Hàng đợi trả lời thường tạm thời, được đặt
tên bởi máy chủ và riêng tư cho một người tiêu dùng.
- Một hàng đợi đăng ký riêng tư (private subscription queue) , giữ các tin nhắn được thu
thập từ các nguồn “đăng ký” khác nhau và chuyển tiếp chúng đến một người tiêu dùng
duy nhất.
Hàng đợi đăng ký thường tạm thời, được đặt tên bởi máy chủ và riêng tư cho một người
tiêu dùng. Những loại này không được định nghĩa chính thức trong AMQP: chúng là ví dụ về
cách sử dụng hàng đợi tin nhắn. Việc tạo các thực thể mới như hàng đợi đăng ký bền vững,
chia sẻ là rất đơn giản
2.1.1.2 The Exchange (Sàn giao dịch)
Một sàn giao dịch chấp nhận các tin nhắn từ một ứng dụng sản xuất và định tuyến chúng
đến các hàng đợi tin nhắn theo các tiêu chí được sắp xếp trước. Những tiêu chí này được gọi là
24

“ràng buộc”. Sàn giao dịch là các động cơ phù hợp và định tuyến. Nghĩa là, chúng kiểm tra các
tin nhắn và sử dụng bảng ràng buộc của chúng, quyết định cách chuyển tiếp các tin nhắn này
đến các hàng đợi tin nhắn hoặc các sàn giao dịch khác. Sàn giao dịch không bao giờ lưu trữ tin
nhắn.
Thuật ngữ “sàn giao dịch” được sử dụng để chỉ cả một lớp thuật toán và các trường hợp
của một thuật toán như vậy. Chính xác hơn, chúng ta nói về “loại sàn giao dịch” và “thể hiện
sàn giao dịch”.
AMQP định nghĩa một số loại sàn giao dịch tiêu chuẩn, bao gồm các loại định tuyến cơ
bản cần thiết để thực hiện việc giao hàng thông điệp thông thường. Các máy chủ AMQP sẽ
cung cấp các thể hiện mặc định của các sàn giao dịch này. Các ứng dụng sử dụng AMQP có
thể tạo các thể hiện sàn giao dịch riêng của mình. Các loại sàn giao dịch được đặt tên để các
ứng dụng tạo các sàn giao dịch riêng của mình có thể cho máy chủ biết sử dụng loại sàn giao
dịch nào. Các thể hiện sàn giao dịch cũng được đặt tên để các ứng dụng có thể chỉ định cách
ràng buộc hàng đợi và xuất bản tin nhắn.
Sàn giao dịch có thể làm nhiều hơn là định tuyến tin nhắn. Chúng có thể hoạt động như
các đại lý thông minh hoạt động từ bên trong máy chủ, chấp nhận tin nhắn và sản xuất tin nhắn
khi cần thiết. Khái niệm sàn giao dịch được thiết kế để định nghĩa một mô hình để thêm tính
mở rộng vào các máy chủ AMQP một cách khá chuẩn mực, vì tính mở rộng có một số ảnh
hưởng đến tính tương thích.
2.1.1.3 Khóa định tuyến
Trong trường hợp tổng quát, một trao đổi kiểm tra các thuộc tính của một tin nhắn, các
trường đầu và nội dung của nó, và sử dụng điều này và có thể là dữ liệu từ các nguồn khác
nhau, quyết định cách định tuyến tin nhắn.
Trong phần lớn các trường hợp đơn giản, trao đổi kiểm tra một trường chính duy nhất,
chúng ta gọi là "chìa khóa định tuyến". Chìa khóa định tuyến là một địa chỉ ảo mà trao đổi có
thể sử dụng để quyết định cách định tuyến tin nhắn.
Đối với định tuyến điểm-điểm, chìa khóa định tuyến thường là tên của một hàng đợi tin
nhắn.
Đối với định tuyến chủ đề pub-sub, chìa khóa định tuyến thường là giá trị của thứ bậc chủ
đề.
Trong các trường hợp phức tạp hơn, chìa khóa định tuyến có thể được kết hợp với định
tuyến dựa trên các trường đầu và/hoặc nội dung của tin nhắn.
25

2.1.1.4 Tương tfi với Email
Nếu chúng ta tạo một phối giống với hệ thống email, chúng ta sẽ thấy rằng các khái niệm
của AMQP không phải là cách mạng:
- Một tin nhắn AMQP tương đương với một tin nhắn email;
- Một hàng đợi tin nhắn giống như một hộp thư;
- Một người tiêu thụ giống như một ứng dụng email, lấy và xóa email;
- Một sàn giao dịch giống như một MTA (mail transfer agent), kiểm tra email và quyết
định, dựa trên các chìa khóa định tuyến và bảng, cách gửi email đến một hoặc nhiều
hộp thư;
- Một chìa khóa định tuyến tương đương với địa chỉ To:, Cc: hoặc Bcc: trong email, mà
không có thông tin của máy chủ (định tuyến hoàn toàn nội bộ trong một máy chủ
AMQP);
- Mỗi phiên bản của sàn giao dịch giống như một quy trình MTA riêng biệt, xử lý một
phần của miền email hoặc loại cụ thể của lưu lượng email;
- Một ràng buộc giống như một mục trong bảng định tuyến của MTA.
Sức mạnh của AMQP đến từ khả năng tạo ra hàng đợi (hộp thư), sàn giao dịch (quy trình
MTA) và ràng buộc (mục định tuyến) vào thời gian chạy, và kết nối chúng lại với nhau theo
cách vượt xa khỏi một ánh xạ đơn giản từ địa chỉ "đến" đến tên hộp thư.
Tuy nhiên, không nên đưa phối giống giữa email và AMQP quá xa: có những khác biệt
cơ bản. Thách thức trong AMQP là định tuyến và lưu trữ tin nhắn trong một máy chủ, hoặc
trong ngôn ngữ SMTP (IETF RFC 821) gọi là "hệ thống tự trị". Ngược lại, thách thức trong
email là định tuyến tin nhắn giữa các hệ thống tự trị.
Định tuyến bên trong một máy chủ và giữa các máy chủ là các vấn đề riêng biệt và có
những giải pháp riêng biệt, ngay cả chỉ vì những lý do nhàm chán như duy trì hiệu suất minh
bạch. Để định tuyến giữa các máy chủ AMQP thuộc sở hữu của các tổ chức khác nhau, người
ta thiết lập các cầu nối rõ ràng, nơi một máy chủ AMQP hành động và làm khách của một máy
chủ khác để truyền tin nhắn giữa những tổ chức riêng biệt đó. Cách làm này thường phù hợp
với các loại doanh nghiệp mà AMQP dự kiến sẽ được sử dụng, vì những cầu nối này có thể
được hỗ trợ bởi các quy trình kinh doanh, nghĩa vụ hợp đồng và quan ngại về bảo mật.
26

2.1.1.5 Luồng tin nhắn
Sơ đồ này hiển thị luồng tin nhắn thông qua máy chủ mô hình AMQ:
Một tin nhắn AMQP bao gồm một tập hợp các thuộc tính cộng với nội dung không rõ nghĩa.
Một "tin nhắn" mới được tạo ra bởi một ứng dụng sản xuất bằng cách sử dụng API khách
AMQP. Người sản xuất đặt "nội dung" vào tin nhắn và có thể thiết lập một số "thuộc tính" cho
tin nhắn. Người sản xuất đánh dấu tin nhắn với "thông tin định tuyến", có vẻ giống như một địa
chỉ, nhưng gần như bất kỳ kế hoạch nào cũng có thể được tạo ra. Sau đó, người sản xuất gửi tin
nhắn đến một "sàn giao dịch" trên máy chủ.
Khi tin nhắn đến máy chủ, sàn giao dịch (thường) định tuyến tin nhắn đến một tập hợp
các "hàng đợi" tin nhắn cũng tồn tại trên máy chủ. Nếu tin nhắn không thể định tuyến, sàn giao
dịch có thể im lặng loại bỏ nó hoặc trả lại nó cho người sản xuất. Người sản xuất có thể chọn
cách xử lý tin nhắn không thể định tuyến.
Một tin nhắn có thể tồn tại trên nhiều hàng đợi tin nhắn. Máy chủ có thể xử lý điều này
theo cách khác nhau, bằng cách sao chép tin nhắn, sử dụng đếm tham chiếu, vv. Điều này
không ảnh hưởng đến khả năng tương tác. Tuy nhiên, khi một tin nhắn được định tuyến đến
nhiều hàng đợi tin nhắn, nó giống nhau trên mỗi hàng đợi tin nhắn. Không có một định danh
duy nhất phân biệt các bản sao khác nhau.
Khi một tin nhắn đến hàng đợi tin nhắn, hàng đợi tin nhắn cố gắng ngay lập tức chuyển
nó đến một ứng dụng tiêu thụ thông qua AMQP. Nếu điều này không khả thi, hàng đợi tin nhắn
lưu trữ tin nhắn (trong bộ nhớ hoặc trên đĩa theo yêu cầu của người sản xuất) và đợi cho đến
27

khi có một tiêu thụ sẵn sàng. Nếu không có tiêu thụ, hàng đợi tin nhắn có thể trả lại tin nhắn
cho người sản xuất thông qua AMQP (nếu người sản xuất yêu cầu điều này).
Khi hàng đợi tin nhắn có thể chuyển tin nhắn đến một tiêu thụ, nó loại bỏ tin nhắn khỏi bộ
đệm nội tại của nó. Điều này có thể xảy ra ngay lập tức hoặc sau khi tiêu thụ đã xác nhận rằng
nó đã xử lý tin nhắn thành công. Tiêu thụ chọn cách và khi nào thông báo "acknowledgements"
về tin nhắn. Tiêu thụ cũng có thể từ chối một tin nhắn (một "negative acknowledgement").
Tin nhắn từ người sản xuất và các thông báo xác nhận từ tiêu thụ được nhóm lại thành
"giao dịch". Khi một ứng dụng chơi cả hai vai trò, điều này thường xảy ra: gửi tin nhắn và gửi
xác nhận, và sau đó xác nhận hoặc hủy bỏ giao dịch.
Giao dịch giữa máy chủ và tiêu thụ không được thực hiện; đủ khi thực hiện giao dịch cho
các xác nhận này.
2.1.1.6 Những gì nhà sản xuất nhìn thấy
Bằng cách tạo phối giống với hệ thống email, ta có thể thấy rằng người sản xuất trong mô
hình AMQP không gửi tin nhắn trực tiếp đến một hàng đợi tin nhắn. Cho phép điều này sẽ phá
vỡ sự trừu tượng được thiết lập trong mô hình AMQP. Điều này giống như cho phép email
tránh qua bảng định tuyến của MTA và trực tiếp đến một hộp thư. Điều này sẽ làm cho không
thể chèn các bộ lọc và xử lý trung gian, chẳng hạn như phát hiện thư rác.
Mô hình AMQP sử dụng nguyên tắc tương tự như hệ thống email: tất cả các tin nhắn
được gửi đến một điểm trung tâm, có thể so sánh với một sàn giao dịch hoặc MTA. Điểm trung
tâm này kiểm tra các tin nhắn dựa trên các quy tắc và thông tin được che giấu từ người gửi và
sau đó định tuyến chúng đến các điểm giao nhận đã được chỉ định, cũng được che giấu từ
người gửi. Phương pháp này đảm bảo rằng quá trình định tuyến và xử lý của tin nhắn được
kiểm soát và quản lý tập trung, cho phép áp dụng các chức năng và biện pháp bảo mật bổ sung
trước khi tin nhắn đến địa điểm cuối cùng của chúng.
2.1.1.7 Người tiêu dùng nhìn thấy gì
Sự phối giống của chúng tôi với hệ thống email bắt đầu phân rã khi chúng ta xem xét về
người tiêu thụ. Khách hàng email là bên thụ động - họ có thể đọc hộp thư của họ, nhưng họ
28

không có bất kỳ ảnh hưởng nào đối với cách những hộp thư này được điền. Một người tiêu thụ
AMQP cũng có thể là bên thụ động, giống như các khách hàng email. Điều này có nghĩa là
chúng ta có thể viết một ứng dụng mà mong đợi một hàng đợi tin nhắn cụ thể sẵn sàng và đã
được kết nối, và nó sẽ đơn giản xử lý tin nhắn từ hàng đợi tin nhắn đó.
Tuy nhiên, chúng tôi cũng cho phép ứng dụng khách hàng AMQP:
- Tạo hoặc xóa các hàng đợi tin nhắn;
- Xác định cách các hàng đợi tin nhắn này được điền, thông qua việc tạo ràng buộc;
- Chọn các sàn giao dịch khác nhau có thể hoàn toàn thay đổi ngữ nghĩa định tuyến.
Điều này giống như việc có một hệ thống email trong đó người ta có thể, qua giao thức:
- Tạo một hộp thư mới;
- Báo với MTA rằng tất cả các tin nhắn với một trường tiêu biểu cụ thể nên được sao
chép vào hộp thư này;
- Thay đổi hoàn toàn cách hệ thống email giải diễn địa chỉ và các tiêu biểu khác.
Chúng ta thấy rằng AMQP giống như một ngôn ngữ để kết nối các phần lại với nhau hơn
là một hệ thống. Điều này là một phần của mục tiêu của chúng tôi, để làm cho hành vi của máy
chủ có thể được lập trình thông qua giao thức.
2.1.1.8 Chế độ tfi động
Hầu hết các kiến trúc tích hợp không cần mức độ phức tạp như vậy. Như một nhiếp ảnh
gia nghiệp dư, đa số người dùng AMQP cần một chế độ "chỉ cần bấm và chụp". AMQP cung
cấp điều này thông qua việc sử dụng hai khái niệm đơn giản hóa:
- Một sàn giao dịch mặc định cho các người sản xuất tin nhắn;
- Một ràng buộc mặc định cho các hàng đợi tin nhắn chọn tin nhắn dựa trên sự khớp
giữa chìa khóa định tuyến và tên hàng đợi tin nhắn.
Thực tế, ràng buộc mặc định cho phép một người sản xuất gửi tin nhắn trực tiếp đến một
hàng đợi tin nhắn, với điều kiện có quyền thích hợp - nó mô phỏng mô hình địa chỉ "gửi đến
đích" đơn giản nhất mà mọi người mong đợi từ middleware truyền thống.
29

Ràng buộc mặc định không ngăn cản việc sử dụng hàng đợi tin nhắn theo cách phức tạp
hơn. Tuy nhiên, nó giúp người dùng sử dụng AMQP mà không cần phải hiểu cách các sàn giao
dịch và các ràng buộc hoạt động.
2.1.2. Exchanges Trao đổi
2.1.2.1 Các loại trao đổi
Mỗi loại sàn giao dịch thực hiện một thuật toán định tuyến cụ thể. Có một số loại sàn giao
dịch tiêu chuẩn, được giải thích trong chương "Functional Specifications", nhưng có hai loại
đặc biệt quan trọng:
- Loại sàn giao dịch trực tiếp (direct exchange), thực hiện định tuyến dựa trên một chìa
khóa định tuyến. Sàn giao dịch mặc định là một sàn giao dịch trực tiếp.
- Loại sàn giao dịch chủ đề (topic exchange), thực hiện định tuyến dựa trên một mẫu
định tuyến.
Máy chủ sẽ tạo ra một tập hợp các sàn giao dịch, bao gồm một sàn giao dịch trực tiếp và
một sàn giao dịch chủ đề khi khởi động với các tên được biết đến trước và các ứng dụng khách
hàng có thể phụ thuộc vào điều này.
2.1.2.2 Vòng đời trao đổi
Mỗi máy chủ AMQP trước đó tạo ra một số sàn giao dịch (instances). Những sàn giao
dịch này tồn tại khi máy chủ bắt đầu và không thể bị hủy. Ứng dụng AMQP cũng có thể tạo ra
các sàn giao dịch riêng của mình. AMQP không sử dụng một phương thức "tạo" cụ thể, nó sử
dụng một phương thức "khai báo" mạnh mẽ, có nghĩa là "tạo nếu chưa có, nếu có rồi thì tiếp
tục". Có thể là ứng dụng sẽ tạo ra các sàn giao dịch cho việc sử dụng riêng và hủy chúng khi
công việc của họ kết thúc. AMQP cung cấp một phương thức để hủy các sàn giao dịch, nhưng
thông thường các ứng dụng không thực hiện điều này. Trong các ví dụ của chúng tôi trong
chương này, chúng tôi sẽ giả định rằng tất cả các sàn giao dịch đều được tạo ra bởi máy chủ khi
khởi động. Chúng tôi sẽ không hiển thị ứng dụng khai báo các sàn giao dịch của mình.
2.1.2.3 Hàng đợi tin nhắn
2.1.2.3.1 Thuộc tính hàng đợi tin nhắn
Khi một ứng dụng khách hàng tạo một hàng đợi tin nhắn, nó có thể chọn một số thuộc
tính quan trọng:
- name - nếu không chỉ định, máy chủ sẽ chọn một tên và cung cấp cho ứng dụng khách
hàng. Thông thường, khi các ứng dụng chia sẻ một hàng đợi tin nhắn, chúng đồng ý
30

trước về tên của hàng đợi tin nhắn, và khi một ứng dụng cần một hàng đợi tin nhắn cho
mục đích riêng của mình, nó để máy chủ cung cấp một tên.
- exclusive - nếu được đặt, hàng đợi thuộc sở hữu của kết nối hiện tại và sẽ bị xóa khi
kết nối đó đóng.
- durable - nếu được đặt, hàng đợi tin nhắn vẫn tồn tại và hoạt động khi máy chủ khởi
động lại. Nó có thể mất các tin nhắn tạm thời nếu máy chủ khởi động lại.
2.1.2.3.2 Vòng đời của hàng đợi
Có hai chu kỳ sống chính của hàng đợi tin nhắn:
- Hàng đợi tin nhắn bền vững (Durable) được chia sẻ bởi nhiều người tiêu thụ và tồn tại
độc lập - tức là chúng sẽ tiếp tục tồn tại và thu thập tin nhắn có hoặc không có người
tiêu thụ để nhận chúng.
- Hàng đợi tin nhắn tạm thời (Temporary) là riêng tư cho một người tiêu thụ và được
liên kết với người tiêu thụ đó. Khi người tiêu thụ ngắt kết nối, hàng đợi tin nhắn sẽ bị
xóa.
Có một số biến thể như các hàng đợi tin nhắn được chia sẻ sẽ bị xóa khi người tiêu thụ
cuối cùng ngắt kết nối. Sơ đồ dưới đây mô tả cách hàng đợi tin nhắn tạm thời được tạo ra và
xóa:
2.1.2.3.3 Ràng buộc

Một ràng buộc là mối quan hệ giữa một sàn giao dịch và một hàng đợi tin nhắn, giúp sàn
giao dịch biết cách định tuyến các tin nhắn. Ràng buộc được xây dựng từ các lệnh của ứng
dụng khách hàng (ứng dụng sở hữu và sử dụng hàng đợi tin nhắn) đến một sàn giao dịch.
Chúng ta có thể diễn đạt một lệnh ràng buộc bằng mã giả như sau:
31

Xem xét ba trường hợp sử dụng điển hình: hàng đợi chia sẻ, hàng đợi phản hồi riêng, và đăng
ký pub-sub.
2.1.2.3.4 Xây dựng hàng đợi dùng chung

Hàng đợi chia sẻ là "hàng đợi điểm-đến-điểm" middleware kinh điển. Trong AMQP,
chúng ta có thể sử dụng sàn giao dịch và ràng buộc mặc định. Hãy giả sử hàng đợi tin nhắn của
chúng ta có tên là "app.svc01". Dưới đây là mã giả cho việc tạo hàng đợi chia sẻ:
Chúng tôi có thể có nhiều người tiêu dùng trên hàng đợi chung này. Để tiêu thụ từ hàng
đợi được chia sẻ, mỗi người tiêu dùng thực hiện việc này:
Để xuất bản lên hàng đợi được chia sẻ, mỗi nhà sản xuất sẽ gửi một tin nhắn đến sàn giao
dịch mặc định:
2.1.2.3.5 Xây dựng hàng đợi trả lời

Hàng đợi phản hồi thường là tạm thời, với tên do máy chủ chỉ định. Thông thường, chúng
cũng là riêng tư, tức là chỉ được đọc bởi một người tiêu thụ duy nhất. Ngoài những đặc điểm
riêng này, hàng đợi phản hồi sử dụng các tiêu chí khớp giống giống như các hàng đợi tiêu
chuẩn, vì vậy chúng ta cũng có thể sử dụng sàn giao dịch mặc định.
Dưới đây là mã giả cho việc tạo hàng đợi phản hồi, trong đó S: chỉ ra một phản hồi từ
máy chủ:
Để xuất bản lên hàng đợi trả lời, nhà sản xuất sẽ gửi tin nhắn đến sàn giao dịch mặc định:
32

Một trong những thuộc tính thông báo tiêu chuẩn là Reply-To, được thiết kế đặc biệt để
mang tên của hàng đợi trả lời.
2.1.2.3.6 Xây dựng hàng đợi đăng ký Pub-Sub
Trong middleware kinh điển, thuật ngữ "subscription" không rõ ràng và thường đề cập
đến ít nhất hai khái niệm khác nhau: bộ tiêu chí khớp với các tin nhắn và hàng đợi tạm thời giữ
các tin nhắn khớp. AMQP tách công việc thành các ràng buộc (bindings) và hàng đợi tin nhắn.
Không có thực thể AMQP nào được gọi là "subscription".
Hãy đồng ý rằng một đăng ký pub-sub:
- Giữ các tin nhắn cho một người tiêu thụ duy nhất (hoặc trong một số trường hợp cho
nhiều người tiêu thụ);
- Tập hợp tin nhắn từ nhiều nguồn thông qua một tập hợp các ràng buộc khớp với chủ
đề, trường tin nhắn hoặc nội dung theo cách khác nhau.
- Sự khác biệt chính giữa một hàng đợi đăng ký và một hàng đợi có tên hoặc hàng đợi
phản hồi là tên của hàng đợi đăng ký không quan trọng với mục đích định tuyến, và
định tuyến được thực hiện dựa trên các tiêu chí khớp trừu tượng hơn là sự khớp 1-1
của trường chìa khóa định tuyến.
Hãy xem mô hình pub-sub thông thường của "cây chủ đề" và thực hiện điều này. Chúng
ta cần một loại sàn giao dịch có khả năng khớp với một cây chủ đề. Trong AMQP, đây là loại
sàn giao dịch "topic". Sàn giao dịch chủ đề khớp với các ký tự đại diện như "STOCK.USD.*"
với các giá trị chìa khóa định tuyến như "STOCK.USD.NYSE".
Chúng ta không thể sử dụng sàn giao dịch hoặc ràng buộc mặc định vì chúng không thực
hiện định tuyến theo kiểu chủ đề. Vì vậy, chúng ta phải tạo một ràng buộc một cách rõ ràng.
Dưới đây là mã giả để tạo và ràng buộc hàng đợi đăng ký pub-sub:
33

Để tiêu thụ từ hàng đợi đăng ký, người tiêu dùng thực hiện điều này:
Khi xuất bản một tin nhắn, nhà sản xuất thực hiện một số việc như sau:
Trao đổi chủ đề xử lý khóa định tuyến đến ("STOCK.USD.ACME") bằng bảng ràng buộc
của nó, và tìm thấy một kết quả phù hợp với tmp.2. Sau đó nó định tuyến tin nhắn đến hàng đợi
đăng ký đó.
2.2. KIẾN TRÚC LỆNH AMQP
Phần này giải thích cách ứng dụng giao tiếp với máy chủ.
2.2.1. Lệnh giao thức (Lớp & Phương thức)
Phần mềm trung gian thường đối mặt với sự phức tạp trong thiết kế cấu trúc giao thức. Mục
tiêu chính của chúng tôi là tạo ra một kiến trúc quản lý được từ sự phức tạp đó. Tiếp cận của
chúng tôi là mô hình một API truyền thống, sử dụng các lớp để chứa các phương thức, và định
nghĩa các phương thức để thực hiện các nhiệm vụ cụ thể một cách hiệu quả. Mặc dù đây dẫn
đến một tập lệnh lớn, nhưng nó tương đối dễ hiểu.
Các lệnh AMQP được tổ chức thành các lớp, mỗi lớp đại diện cho một lĩnh vực chức năng cụ
thể. Một số lớp là tùy chọn, và mỗi đối tác sẽ chỉ thực hiện các lớp mà nó cần hỗ trợ.
Có hai cuộc trò chuyện phương thức chính trong hệ thống của chúng
tôi: 1 Yêu cầu-phản hồi đồng bộ:
- Một đối tác gửi một yêu cầu và đợi phản hồi từ đối tác khác.
- Các phương thức yêu cầu và phản hồi đồng bộ được sử dụng cho các chức năng không
quan trọng về hiệu suất.
34

- Đối tác đợi phản hồi trước khi tiếp tục thực hiện các phương thức
khác. 2 Thông báo không đồng bộ:
- Một đối tác gửi một phương thức mà không chờ đợi phản hồi.
- Các phương thức không đồng bộ được sử dụng khi hiệu suất là yếu tố quan trọng.
- Đối tác tiếp tục thực hiện các phương thức mà không cần đợi phản hồi.
Để đơn giản hóa xử lý phương thức, chúng tôi đã định nghĩa các phản hồi riêng biệt cho mỗi
yêu cầu-phản hồi đồng bộ. Điều này có nghĩa là mỗi yêu cầu có một phản hồi đồng bộ tương
ứng, và không có phương thức nào được sử dụng làm phản hồi cho hai yêu cầu khác nhau.
Điều này giúp đối tác có thể chấp nhận và xử lý các phương thức đến cho đến khi nhận được
một trong những phản hồi đồng bộ hợp lệ. Điều này tạo ra sự khác biệt giữa AMQP và các giao
thức RPC truyền thống hơn.
Mỗi phương thức được định nghĩa chính thức có thể là yêu cầu-phản hồi đồng bộ, một phản
hồi đồng bộ (đối với một yêu cầu cụ thể) hoặc không đồng bộ. Cuối cùng, mỗi phương thức
cũng được xác định là ở phía khách hàng (từ máy chủ đến máy khách) hoặc ở phía máy chủ (từ
máy khách đến máy chủ), giúp định rõ trách nhiệm của từng bên trong cuộc giao tiếp.
2.2.2. Ánh xạ AMQP tới API phần mềm trung gian
Chúng tôi đã thiết kế AMQP để có thể ánh xạ được với một API middleware. Ánh xạ này có
một số sự thông minh (không phải tất cả các phương thức và đối số đều hợp lý với ứng dụng)
nhưng cũng là cơ học (với một số quy tắc, tất cả các phương thức có thể được ánh xạ mà không
cần can thiệp thủ công).
Ưu điểm của điều này là sau khi đã hiểu rõ AMQP semantics (các lớp được mô tả trong phần
này), các nhà phát triển sẽ thấy cùng một semantics được cung cấp trong bất kỳ môi trường nào
họ sử dụng.
Ví dụ, dưới đây là một ví dụ về phương thức Queue.Declare:
Điều này có thể được truyền dưới dạng khung cấp dây:
35

Hoặc dưới dạng API cấp cao hơn:
Logic mã giả để ánh xạ một phương thức không đồng bộ là:
Logic mã giả để ánh xạ một phương thức đồng bộ là:
Đáng chú ý rằng đối với hầu hết các ứng dụng, middleware có thể được hoàn toàn ẩn đi trong
các lớp kỹ thuật, và việc API thực tế được sử dụng quan trọng ít hơn so với việc middleware là
mạnh mẽ và có khả năng.
2.2.3. Không có xác nhận
Giao thức tán tụ thường đối mặt với vấn đề về tốc độ truyền thông. Để giải quyết vấn đề này,
chúng tôi áp dụng đồng bộ hóa mạnh mẽ trong những trường hợp nơi hiệu suất là một yếu tố
quan trọng. Đặc biệt, khi chúng tôi truyền nội dung từ một đối tác sang một đối tác khác, chúng
tôi ưu tiên việc gửi các phương thức càng nhanh càng tốt mà không cần đợi xác nhận.
Chúng tôi thiết lập một quy trình gửi không đồng bộ, tăng cường hiệu suất và giảm thời gian
chờ đợi. Trong một số trường hợp, chúng tôi thực hiện cửa sổ (windowing) để kiểm soát lưu
lượng tại mức độ cao hơn, chẳng hạn như ở mức tiêu thụ. Điều này giúp chúng tôi duy trì một
quy trình truyền thông linh hoạt mà không làm suy giảm hiệu suất.
Quan trọng hơn, chúng tôi đã chọn bỏ qua quá trình xác nhận trong AMQP để tối ưu hóa hiệu
suất. Mô hình của chúng tôi dựa trên việc khẳng định mọi hành động. Điều này có nghĩa là khi
chúng tôi thực hiện một hành động, chúng tôi tin rằng nó sẽ thành công hoặc sẽ có một ngoại lệ
cần được xử lý, ví dụ như đóng kênh hoặc thiết lập lại kết nối.
Trong AMQP, không có xác nhận rõ ràng. Sự thành công thường được biểu thị bằng im lặng,
trong khi thất bại tạo ra ồn ào hoặc thông báo lỗi. Đối với các ứng dụng yêu cầu theo dõi rõ
36

ràng về thành công và thất bại, chúng tôi khuyến khích sử dụng giao dịch. Giao dịch cung cấp
một cơ chế linh hoạt để đảm bảo tính toàn vẹn dữ liệu và theo dõi kết quả của các hoạt động.
Điều này giúp ứng dụng theo dõi mọi tình huống và đảm bảo tính đồng nhất trong quá trình
truyền thông và xử lý dữ liệu.
2.2.4. Lớp kết nối

Giao thức AMQP (Advanced Message Queuing Protocol) được xây dựng như một giao thức
kết nối với một vòng đời kết nối chi tiết và rõ ràng. Dưới đây là mô tả đầy đủ về vòng đời kết
nối trong AMQP:
1 Mở Kết Nối:
- Khách hàng mở một kết nối TCP/IP đến máy chủ và gửi một tiêu đề giao thức.
- Máy chủ phản hồi với phiên bản giao thức của mình và các thuộc tính khác, bao gồm
danh sách các cơ chế bảo mật mà nó hỗ trợ thông qua phương thức Start.
2 Chọn Cơ Chế Bảo Mật:
- Khách hàng chọn một trong các cơ chế bảo mật được hỗ trợ và gửi phản hồi bằng
phương thức Start-Ok.
- Máy chủ bắt đầu quá trình xác thực sử dụng mô hình thách thức-phản ứng SASL, gửi
một thách thức (Secure) đến khách hàng.
3 Xác Thực và Đàm Phán:
- Khách hàng gửi phản ứng xác thực (Secure-Ok), chẳng hạn sử dụng cơ chế "plain" với
tên đăng nhập và mật khẩu.
- Máy chủ có thể lặp lại thách thức hoặc chuyển sang đàm phán, gửi tập hợp các tham số
như kích thước khung tối đa thông qua phương thức Tune.
- Khách hàng chấp nhận hoặc giảm tham số này thông qua phương thức Tune-
Ok. 4 Mở Kết Nối Chính Thức:
- Khách hàng mở kết nối chính thức và chọn một ổ ảo thông qua phương thức Open.
- Máy chủ xác nhận rằng ổ ảo là một lựa chọn hợp lệ thông qua phương thức Open-
Ok. 5 Sử Dụng Kết Nối:
- Sau quá trình đàm phán, kết nối đã được thiết lập và đối tác có thể sử dụng nó cho việc
truyền thông.
37

6 Kết Thúc Kết Nối:
- Một trong hai đối tác (khách hàng hoặc máy chủ) có thể kết thúc kết nối bằng phương
thức Close.
- Đối tác còn lại phản hồi bằng cách chấp nhận chấm dứt kết nối thông qua phương thức
Close-Ok.
7 Xử Lý Lỗi và Đóng Kết Nối:
- Trong quá trình sử dụng kết nối, nếu xảy ra lỗi hoặc ngoại lệ, đối tác có thể chọn đóng
kết nối thông qua phương thức Close với thông điệp lỗi tương ứng.
- Đối tác còn lại phản hồi bằng cách chấp nhận chấm dứt kết nối thông qua phương thức
Close-Ok.
8 Xác Nhận Thành Công và Thất Bại:
- Khi các hoạt động hoặc giao tiếp được thực hiện, mỗi đối tác có thể gửi phản hồi thành
công hoặc thất bại theo yêu cầu.
9 Đóng Kết Nối Socket:
- Sau khi bước bắt tay chấm dứt kết nối, cả máy chủ và khách hàng đóng kết nối socket
của họ.
- Quá trình này giúp đảm bảo rằng việc thiết lập và sử dụng kết nối trong AMQP là một
quá trình tin cậy và kiểm soát được, đồng thời giúp duy trì tính ổn định trong quá trình
truyền thông.
2.2.5. Lớp kênh
Giao thức AMQP được thiết kế với khả năng sử dụng nhiều kênh, mở rộng khả năng kết nối và
giúp tối ưu hóa hiệu suất truyền thông. Việc này có nhiều ưu điểm, làm cho AMQP trở nên
"thân thiện với tường lửa" hơn và dễ dàng quản lý trong môi trường mạng.
1 Đa Kênh và "Thân Thiện Với Tường Lửa":
- Các kênh trong AMQP cho phép nhiều kết nối TCP/IP nặng nề được đa kênh hóa
thành nhiều kết nối nhẹ.
- Việc này giúp dự đoán được cổng sử dụng, làm cho giao thức trở nên dễ quản lý hơn
trong các tường lửa và các môi trường mạng có hạn chế.
2 Độc Lập và Đồng Thời:
38

- Các kênh trong AMQP là độc lập và có thể thực hiện các chức năng khác nhau đồng
thời.
- Băng thông khả dụng được chia sẻ giữa các kênh, cho phép hoạt động đồng thời mà
không ảnh hưởng đến hiệu suất chung.
3 Mô Hình "Kênh-Cho-Mỗi-Luồng":
- Mô hình này khuyến khích việc sử dụng nhiều kênh trong ứng dụng đa luồng.
- Các kênh có thể được mở và sử dụng độc lập, giúp tăng cường hiệu suất và khả năng
xử lý đa nhiệm của ứng dụng.
4 Vòng Đời Kênh:
Vòng đời của một kênh trong AMQP bao gồm các bước sau:
+ Khách hàng mở một kênh mới (Open).
+ Máy chủ xác nhận rằng kênh mới đã sẵn sàng (Open-Ok).
+ Khách hàng và máy chủ sử dụng kênh như mong muốn.
+ Một trong hai đối tác (khách hàng hoặc máy chủ) có thể đóng kênh (Close).
+ Đối tác còn lại phản hồi bằng cách chấp nhận chấm dứt đóng kênh thông qua
phương thức Close-Ok.
Việc này tạo ra một môi trường linh hoạt và có thể mở rộng, giúp ứng dụng AMQP thích ứng
tốt với các yêu cầu đa nhiệm và đa kênh của môi trường mạng hiện đại.
2.2.6. Lớp trao đổi
Lớp Exchange trong AMQP cho phép ứng dụng quản lý các sàn (Exchange) trên máy chủ.
Việc này mang lại khả năng tự định hình kết nối của ứng dụng mà không phụ thuộc vào một
giao diện cấu hình cụ thể nào đó. Tuy nhiên, cần lưu ý rằng đa số các ứng dụng không cần đến
mức độ phức tạp này, và middleware cũ có thể không hỗ trợ chức năng này.
Vòng Đời của Sàn:
1 Khởi Tạo Sàn (Declare):
- Khách hàng yêu cầu máy chủ đảm bảo rằng sàn tồn tại thông qua phương thức Declare.
- Khách hàng có thể điều chỉnh yêu cầu này thành "tạo sàn nếu nó không tồn tại" hoặc
"cảnh báo nhưng đừng tạo nó, nếu nó không tồn tại".
39

- Quá trình này đảm bảo sàn được tạo ra hoặc kiểm tra sự tồn tại của nó trên máy
chủ. 2 Xuất Bản Thông Điệp Đến Sàn:
- Khách hàng sau đó xuất bản các thông điệp đến sàn đã được khởi tạo.
- Thông điệp này sẽ được chuyển đến các hàng đợi liên kết với sàn để chuyển tiếp đến
các ứng dụng tiêu thụ hoặc sử lý.
3 Xóa Sàn (Delete):
- Khách hàng có thể chọn xóa sàn khi không cần thiết nữa thông qua phương thức
Delete.
- Quá trình này giúp giải phóng tài nguyên trên máy chủ và kết thúc việc sử dụng sàn cụ
thể.
Việc quản lý vòng đời của sàn trong AMQP mang lại linh hoạt và quyền lực cho ứng dụng, đặc
biệt là khi cần tùy chỉnh và quản lý động các thành phần trên máy chủ AMQP. Tuy nhiên, đối
với các ứng dụng đơn giản, sử dụng mặc định có thể là lựa chọn thuận tiện và hiệu quả.
2.2.7. Lớp xếp hang
Lớp Queue trong AMQP cung cấp khả năng quản lý các hàng đợi thông điệp trên máy chủ, là
một bước quan trọng đối với hầu hết các ứng dụng tiêu thụ thông điệp. Việc này ít nhất là giúp
xác minh rằng một hàng đợi thông điệp cụ thể thực sự tồn tại. Dưới đây là mô tả chi tiết về
vòng đời của một hàng đợi thông điệp trong AMQP:
Vòng Đời cho Một Hàng Đợi Thông Điệp Bền Vững:
1 Xác Nhận Tồn Tại (Declare - Passive):
+ Khách hàng khẳng định rằng hàng đợi thông điệp tồn tại thông qua phương thức
Declare với đối số "passive".
+ Máy chủ xác nhận rằng hàng đợi thông điệp đã tồn tại thông qua phương thức
Declare-Ok.
2 Đọc Thông Điệp từ Hàng Đợi:
+ Sau khi xác nhận sự tồn tại, khách hàng có thể đọc các thông điệp từ hàng đợi thông
điệp.
Vòng Đời cho Một Hàng Đợi Thông Điệp Tạm Thời:
1 Tạo và Xác Nhận (Declare):
40

+ Khách hàng tạo hàng đợi thông điệp thông qua phương thức Declare, thường là
không có tên hàng đợi để máy chủ tự động gán một tên.
+ Máy chủ xác nhận rằng hàng đợi thông điệp đã được tạo thông qua phương thức
Declare-Ok.
2 Bắt Đầu Người Tiêu Thụ (Consume):
+ Khách hàng bắt đầu một người tiêu thụ trên hàng đợi thông điệp thông qua phương
thức Consume.
+ Chức năng chính xác của một người tiêu thụ được định nghĩa bởi lớp Basic.
3 Hủy Người Tiêu Thụ (Cancel hoặc Đóng Kênh/Kết Nối):
+ Khách hàng có thể hủy người tiêu thụ, rõ ràng hoặc bằng cách đóng kênh và/hoặc
kết nối.
4 Xóa Hàng Đợi (Auto-Delete):
+ Khi người tiêu thụ cuối cùng biến mất khỏi hàng đợi, và sau một khoảng thời gian
lịch sự, máy chủ xóa hàng đợi thông điệp.
5 Giao Hàng Theo Dõi:
+ AMQP thực hiện cơ chế giao hàng cho đăng ký theo dõi dưới dạng hàng đợi thông
điệp. Điều này cho phép một đăng ký theo dõi có thể được phân phối tải giữa một
nhóm các ứng dụng đăng ký theo dõi cộng tác.
Vòng Đời cho Một Đăng Ký Theo Dõi:
1 Tạo Hàng Đợi và Xác Nhận (Declare):
+ Khách hàng tạo hàng đợi thông điệp thông qua phương thức Declare và máy chủ xác
nhận (Declare-Ok).
2 Liên Kết Hàng Đợi với Sàn (Bind):
+ Khách hàng liên kết hàng đợi thông điệp với một sàn chủ đề thông qua phương thức
Bind và máy chủ xác nhận (Bind-Ok).
3 Sử Dụng Hàng Đợi Như Bình Thường:
+ Khách hàng có thể sử dụng hàng đợi thông điệp như trong các bước trước đó.
Điều này tạo ra một môi trường linh hoạt cho quản lý hàng đợi thông điệp, có thể thích ứng với
nhiều tình huống và yêu cầu sử dụng khác nhau.
41

2.2.8. Lớp cơ bản
Lớp Basic trong AMQP đóng vai trò quan trọng trong việc thực hiện các khả năng truyền
thông giữa khách hàng và máy chủ. Dưới đây là mô tả chi tiết về các ngữ nghĩa chính được hỗ
trợ bởi Lớp Basic:
1 Gửi Thông Điệp từ Khách Hàng Đến Máy Chủ (Publish):
- Khách hàng có khả năng gửi các thông điệp đến máy chủ thông qua phương thức
Publish.
- Thông điệp được gửi đi bất đồng bộ, cho phép khách hàng tiếp tục công việc mà không
cần đợi xác nhận.
2 Bắt Đầu và Dừng Người Tiêu Thụ (Consume, Cancel):
- Khách hàng có thể bắt đầu một người tiêu thụ trên hàng đợi thông điệp để nhận các
thông điệp từ máy chủ thông qua phương thức Consume.
- Cũng có khả năng hủy bỏ người tiêu thụ thông qua phương thức Cancel khi không cần
thiết nữa.
3 Gửi Thông Điệp từ Máy Chủ Đến Khách Hàng (Deliver, Return):
- Máy chủ có khả năng gửi các thông điệp đến khách hàng thông qua phương thức
Deliver.
- Nếu có thông điệp không thể được gửi đến hàng đợi đích, máy chủ có thể trả thông
điệp về cho khách hàng thông qua phương thức Return.
4 Xác Nhận Thông Điệp (Ack, Reject):
- Khách hàng có khả năng xác nhận (Acknowledge) hoặc từ chối (Reject) các thông điệp
đã nhận.
- Xác nhận thông điệp là quyết định của khách hàng về việc xử lý thành công thông
điệp, trong khi từ chối là quyết định về việc từ chối xử lý thông điệp và có thể quyết
định việc chuyển thông điệp đến một hàng đợi khác.
5 Lấy Thông Điệp Từ Hàng Đợi Thông Điệp Một Cách Đồng Bộ (Get):
- Khách hàng có thể đồng bộ lấy một thông điệp từ hàng đợi thông điệp thông qua
phương thức Get.
- Điều này cho phép khách hàng lấy thông điệp mà không cần tạo một người tiêu thụ
đồng thời.
42

Lớp Basic cung cấp một tập hợp đầy đủ các chức năng để quản lý và tương tác với các thông
điệp trong môi trường AMQP, từ việc gửi thông điệp đến nhận và xử lý chúng. Các khả năng
này cung cấp sự linh hoạt và kiểm soát cao đối với quá trình truyền thông giữa các thành phần
của hệ thống.
2.2.9. Lớp giao dịch
AMQP hỗ trợ hai loại giao dịch:
1 Giao dịch tự động, trong đó mỗi thông điệp được xuất bản và xác nhận được xử lý như là một
giao dịch độc lập.
2 Giao dịch cục bộ của máy chủ, trong đó máy chủ sẽ lưu thông điệp được xuất bản và các xác
nhận và thực hiện chúng theo yêu cầu từ phía khách hàng.
Lớp Transaction ("tx") cung cấp ứng dụng quyền truy cập vào loại thứ hai, tức là giao dịch của
máy chủ. Ngữ nghĩa của lớp này như sau:
1 Ứng dụng yêu cầu giao dịch của máy chủ trong mỗi kênh nơi nó muốn thực hiện giao dịch
này (Select).
2 Ứng dụng thực hiện công việc (Publish, Ack).
3 Ứng dụng cam kết hoặc hủy công việc (Commit, Roll-back).
4 Ứng dụng thực hiện công việc, vô hạn.
Giao dịch bao gồm nội dung được xuất bản và các xác nhận, không phải là giao dịch của việc
giao hàng. Do đó, một hủy giao dịch không đặt lại hay giao lại bất kỳ thông điệp nào, và một
khách hàng có quyền xác nhận lại những thông điệp này trong một giao dịch tiếp theo.
2.3. KIẾN TRÚC GIAO THÔNG AMQP
Phần này giải thích cách các lệnh được ánh xạ tới giao thức cấp dây.
2.3.1. Mô tả chung
AMQP (Advanced Message Queuing Protocol) là một giao thức nhị phân, trong đó thông tin
được tổ chức thành các "frames" của nhiều loại khác nhau. Mỗi frame chứa các phương thức
giao thức và thông tin khác nhau, và tất cả các frames đều có cùng một định dạng tổng quát,
bao gồm tiêu đề frame, dữ liệu và kết thúc frame. Định dạng dữ liệu của frame phụ thuộc vào
loại frame đó.
Giao thức giả định sự tồn tại của một lớp truyền dữ liệu mạng có độ tin cậy và hướng luồng,
chẳng hạn như TCP/IP hoặc tương đương. Trong một kết nối socket duy nhất, có thể có nhiều
luồng kiểm soát độc lập, được gọi là "channels". Mỗi frame được đánh số với một số channel,
43

và các channel khác nhau chia sẻ kết nối bằng cách xen kẽ frames của họ. Mỗi channel có một
chuỗi nghiêm ngặt của các frames có thể được sử dụng để điều khiển một bộ phân tích giao
thức, thường là một máy trạng thái.
Việc tạo frames được thực hiện bằng cách sử dụng một bộ nhỏ các loại dữ liệu như bit, số
nguyên, chuỗi và bảng trường. Các trường của frame được đóng gói chặt chẽ để không làm
chúng trở nên chậm chạp hoặc phức tạp để phân tích. Quá trình tạo lớp framing từ các quy tắc
đặc tả giao thức được mô tả như là một quá trình đơn giản.
Định dạng cấp wire của AMQP được thiết kế để có khả năng mở rộng và tổng quát đủ để sử
dụng cho các giao thức cấp cao tùy ý, không chỉ là AMQP. Giao thức giả định rằng AMQP sẽ
tiếp tục được mở rộng, cải thiện và biến đổi theo thời gian, và định dạng cấp wire sẽ hỗ trợ điều
này. Điều này giúp đảm bảo tính linh hoạt và khả năng thích ứng của AMQP trong tương lai.
2.3.2. Các kiểu dữ liệu
Các loại dữ liệu AMQP được sử dụng trong framing của phương thức và bao gồm:
- Số Nguyên (Integer):
+ Số nguyên có kích thước từ 1 đến 8 octets.
+ Số nguyên được sử dụng để biểu diễn các giá trị như kích thước, số lượng, giới hạn,
v.v.
+ Số nguyên luôn là không dấu và có thể không được căn chỉnh trong frame.
- Bit:
+ Bit được sử dụng để biểu diễn giá trị bật/tắt (true/false).
+ Bit được đóng gói vào các octet, mỗi bit chiếm một bit trong octet.
- Chuỗi Ngắn (Short String):
+ Chuỗi ngắn được sử dụng để giữ các thuộc tính văn bản ngắn.
+ Chuỗi ngắn giới hạn đến 255 octets và có thể được phân tích mà không có rủi ro tràn
bộ đệm.
- Chuỗi Dài (Long String):
+ Chuỗi dài được sử dụng để giữ các đoạn dữ liệu nhị phân.
+ Chuỗi dài không có giới hạn kích thước cụ thể và có thể chứa các dữ liệu lớn.
- Bảng Trường (Field Table):
44

+ Bảng trường chứa các cặp tên-giá trị, tương tự như một bảng hash hoặc đối số chức
năng.
+ Giá trị của trường có thể được định kiểu như chuỗi, số nguyên, v.v.
Các loại dữ liệu này được sử dụng để biểu diễn các thông tin khác nhau trong các frames giao
thức AMQP. Sự đa dạng của chúng cho phép giao thức xử lý nhiều loại dữ liệu và thực hiện
các chức năng khác nhau, giúp cung cấp tính linh hoạt và khả năng mở rộng trong quá trình
truyền thông.
2.3.3. Đàm phán giao thức
Trong AMQP, quá trình đàm phán giữa khách hàng và máy chủ là một phần quan trọng của
quá trình kết nối. Điều này đồng nghĩa với việc khi một khách hàng kết nối, máy chủ đề xuất
một số tùy chọn mà khách hàng có thể chấp nhận hoặc điều chỉnh theo nhu cầu của mình. Quá
trình đàm phán này cho phép xác định các giả định và điều kiện tiên quyết cho việc thiết lập
kết nối.
Trong quá trình đàm phán AMQP, có nhiều khía cạnh cụ thể được xem xét:
1 Giao Thức và Phiên Bản:
- Máy chủ có thể chứa nhiều giao thức trên cùng một cổng.
- Quá trình đàm phán giúp xác định phiên bản cụ thể của giao thức được sử
dụng. 2 Đối Số Mã Hóa và Xác Thực:
- Đàm phán liên quan đến các thông số liên quan đến mã hóa và xác thực giữa cả hai
bên.
- Các yếu tố này là một phần của tầng chức năng đã được giải thích trước
đó. 3 Kích Thước Frame Tối Đa và Các Giới Hạn Vận Hành Khác:
- Quá trình đàm phán bao gồm các thông số như kích thước frame tối đa, số lượng kênh,
và các giới hạn vận hành khác.
- Các giới hạn được đồng ý nhằm xác định trước bộ đệm và tránh tình trạng kẹt cứng.
- Mỗi frame tuân theo các giới hạn đã đồng ý, đảm bảo tính an toàn hoặc ngắt kết nối
nếu vượt quá giới hạn.
Cả hai đối tác đều tham gia đàm phán về các giới hạn, với quy tắc như sau:
Máy Chủ Phải Thông Báo Giới Hạn Đề Xuất:
45

- Máy chủ đề xuất các giới hạn mà nó đề xuất cho khách hàng.
- Khách Hàng Phản Hồi và Có Thể Giảm Giới Hạn:
- Khách hàng có thể phản hồi và giảm giới hạn nếu cần thiết cho kết nối của mình.
- Quá trình đàm phán này đảm bảo rằng cả hai đối tác đồng thuận với các điều kiện
chung và thiết lập một kết nối AMQP có hiệu suất ổn định và an toàn.
2.3.4. Khung phân định
Trong TCP/IP, một giao thức dòng, việc phân đoạn frame không được tích hợp sẵn. Điều này
đặt ra một thách thức cho việc truyền thông tin trong các frame qua mạng. Các giao thức như
AMQP cần xử lý vấn đề này và sử dụng các chiến lược khác nhau để đảm bảo truyền thông
hiệu quả. Dưới đây là một số cách tiếp cận phổ biến:
1 Gửi Một Frame Duy Nhất Cho Mỗi Kết Nối:
- Cách tiếp cận này đơn giản nhưng có thể làm chậm quá trình truyền thông vì mỗi
frame cần phải chờ đến khi frame trước đó hoàn thành trước khi được gửi đi. Điều này
làm giảm hiệu suất của kết nối.
2 Thêm Dấu Phân Cách Frame Vào Luồng:
- Cách tiếp cận này bao gồm việc thêm dấu phân cách frame vào luồng dữ liệu. Điều này
giúp phân đoạn các frame mà không cần chờ đợi frame trước đó hoàn thành.
- Tuy nhiên, việc phân tích có thể trở nên phức tạp hơn vì cần phải xác định nơi mà mỗi
frame bắt đầu và kết thúc trong luồng dữ liệu.
3 Gửi Kích Thước Frame Trước Mỗi Frame:
- Cách tiếp cận này là gửi kích thước của frame trước khi gửi frame thực tế. Điều này
giúp cả hai bên biết trước kích thước của frame và chuẩn bị sẵn sàng để nhận frame
tiếp theo.
- Đây là lựa chọn phổ biến vì nó đơn giản, nhanh chóng và giúp tránh được tình trạng
chậm do việc chờ đợi.
Mỗi chiến lược có ưu và nhược điểm của mình, và sự lựa chọn giữa chúng phụ thuộc vào yêu
cầu cụ thể của ứng dụng và môi trường mạng.
46

2.3.4.1 Chi tiết khung
Tất cả các khung bao gồm một tiêu đề (7 octet), tải trọng có kích thước tùy ý và một octet 'cuối
khung' để phát hiện khung không đúng định dạng:
Để đọc một frame, chúng ta thực hiện các bước sau:

1 Đọc phần tiêu đề và kiểm tra loại frame và kênh.
2 Tùy thuộc vào loại frame, chúng ta đọc phần payload và xử lý nó.
3 Đọc octet cuối cùng của frame.
Trong các triển khai thực tế nơi hiệu suất là một vấn đề, chúng ta sẽ sử dụng "đọc trước" hoặc
"đọc tập trung" để tránh thực hiện ba cuộc gọi hệ thống riêng biệt để đọc một frame.
2.3.4.2 Khung phương thức
Các khung phương thức mang các lệnh giao thức cấp cao (mà chúng tôi gọi là "phương thức").
Một khung phương thức mang một lệnh. Tải trọng khung phương thức có định dạng sau:
Để xử lý một frame phương thức, chúng ta thực hiện các bước sau:
1 Đọc phần payload của frame phương thức.
2 Giải nén nó thành một cấu trúc. Một phương thức cụ thể luôn có cấu trúc giống nhau, vì vậy
chúng ta có thể giải nén phương thức nhanh chóng.
3 Kiểm tra xem phương thức có được phép trong ngữ cảnh hiện tại hay không.
4 Kiểm tra xem các đối số của phương thức có hợp lệ hay không.
5 Thực hiện phương thức.
47

Các thân frame phương thức được xây dựng dưới dạng một danh sách các trường dữ liệu
AMQP (bit, số nguyên, chuỗi và bảng chuỗi). Mã đóng gói được tạo ra một cách đơn giản trực
tiếp từ các quy định của giao thức và có thể rất nhanh chóng.
2.3.4.3 Khung nội dung
Dữ liệu là dữ liệu ứng dụng chúng ta chuyển từ client sang client thông qua máy chủ AMQP.
Dữ liệu, nói chung, là một bộ các thuộc tính cộng với một phần dữ liệu nhị phân. Bộ các thuộc
tính được phép được xác định bởi lớp Basic, và chúng tạo thành "content header frame". Dữ
liệu có thể có kích thước bất kỳ và CÓ THỂ được chia thành nhiều (hoặc nhiều) phần, mỗi
phần tạo thành một "content body frame".
Nhìn vào các frame cho một kênh cụ thể, khi chúng chuyển qua wire, chúng ta có thể thấy một
cái gì đó như sau:
Các phương thức cụ thể (như Basic.Publish, Basic.Deliver, vv.) được định nghĩa chính thức để
chứa nội dung. Khi một peer gửi một frame phương thức như vậy, nó luôn theo sau bởi một
header nội dung và không có hoặc nhiều frame thân nội dung.
Một frame header nội dung có định dạng như sau:
Chúng ta đặt thân nội dung trong các frame riêng biệt (thay vì bao gồm nó trong phương thức)
để AMQP có thể hỗ trợ các kỹ thuật "zero copy" trong đó nội dung không bao giờ được đóng
gói hoặc mã hóa. Chúng ta đặt các thuộc tính nội dung trong frame riêng của chúng để người
nhận có thể chọn lọc các nội dung mà họ không muốn xử lý.
2.3.4.4 Khung nhịp tim
Heartbeating là một kỹ thuật quan trọng được thiết kế để đảm bảo tính liên tục của kết nối
trong môi trường mạng. Trong môi trường AMQP và nhiều giao thức khác, heartbeating không
chỉ đơn giản là việc kiểm tra xem kết nối còn mở hay không, mà còn bao gồm việc kiểm tra
tính khả dụng của đối tác kết nối.
48

Mục tiêu chính của heartbeating là đảm bảo rằng cả hai đối tác đều còn hoạt động và sẵn sàng
giao tiếp. Nếu một đối tác không gửi hoặc nhận được bất kỳ frame nào trong khoảng thời gian
được đặt trước (khoảng thời gian heartbeating), kết nối được coi là không còn hiệu lực và có
thể được đóng và thiết lập lại.
Thay vì triển khai heartbeating như một phương thức của lớp, trong AMQP, nó được thực hiện
ở mức giao vận dưới dạng các frame đặc biệt. Những frame này chứa thông điệp heartbeating
và được trao đổi giữa các đối tác để kiểm tra sự liên tục của kết nối.
Heartbeating giúp giảm độ trễ trong việc phát hiện và xử lý các vấn đề kết nối, đồng thời cung
cấp cơ hội cho các đối tác để kiểm soát và định cấu hình thời gian heartbeating dựa trên yêu
cầu cụ thể của ứng dụng và môi trường mạng.
2.3.5. Xử lý lỗi
AMQP sử dụng cơ chế xử lý lỗi thông qua việc ánh xạ các lỗi vào các ngoại lệ tương ứng. Các
loại lỗi được phân thành hai nhóm chính: lỗi hoạt động và lỗi cấu trúc.
1 Lỗi Hoạt Động (Operational Errors):
- Khi xảy ra lỗi trong quá trình thực hiện các hoạt động như tìm kiếm message queue
không tồn tại, quyền truy cập không đủ, và các vấn đề hoạt động khác, một ngoại lệ
kênh sẽ được kích phát.
- Các lỗi này chủ yếu liên quan đến các vấn đề vận hành và quyền truy cập của ứng
dụng.
2 Lỗi Cấu Trúc (Structural Errors):
- Khi có lỗi trong cấu trúc của các phương thức, ví dụ như đối số không hợp lệ, chuỗi
phương thức không đúng, một ngoại lệ kết nối sẽ được kích phát.
- Các lỗi cấu trúc này thường liên quan đến việc gửi các frame không đúng hoặc không
hợp lệ.
Mỗi ngoại lệ sẽ dẫn đến việc đóng kênh hoặc kết nối và trả về một mã phản hồi 3 chữ số cùng
với văn bản phản hồi. Hệ thống mã phản hồi này được thiết kế để cung cấp thông tin chi tiết về
lỗi và trạng thái của kết nối, giúp ứng dụng khách hiểu rõ vấn đề và có thể thực hiện các biện
pháp xử lý phù hợp.
Sự sử dụng của hệ thống mã phản hồi 3 chữ số cũng tạo ra tính tương thích với các giao thức
khác như HTTP, giúp đơn giản hóa quá trình xử lý lỗi và tương tác với các thành phần hệ
thống khác.
49

2.3.6. Đóng kênh và kết nối
Một kết nối hoặc kênh được coi là "mở" đối với client khi nó đã gửi Open, và đối với server
khi nó đã gửi Open-Ok. Từ điểm này trở đi, một đối tác muốn đóng kênh hoặc kết nối PHẢI
làm như vậy bằng cách sử dụng một giao thức hand-shake được mô tả ở đây.
Việc đóng một kênh hoặc kết nối vì bất kỳ lý do nào - bình thường hoặc ngoại lệ - phải được
thực hiện cẩn thận. Đóng đột ngột không luôn được phát hiện nhanh chóng, và sau một ngoại
lệ, chúng ta có thể mất mã phản hồi lỗi.
Thiết kế đúng là hand-shake tất cả các thao tác đóng cửa để chúng ta chỉ đóng sau khi chắc
chắn rằng bên kia đã nhận thức được tình hình. Khi một đối tác quyết định đóng một kênh hoặc
kết nối, nó gửi một phương thức Close. Đối tác nhận phải phản hồi với Close-Ok, sau đó cả hai
bên mới có thể đóng kênh hoặc kết nối của họ. Lưu ý rằng nếu đối tác bỏ qua Close, có thể xảy
ra tình trạng đình bị khi cả hai đối tác gửi Close cùng một lúc.
2.4. KIẾN TRÚC MÁY KHÁCH AMQP
Có thể đọc và viết các khung AMQP trực tiếp từ ứng dụng nhưng điều này sẽ là thiết kế kém
chất lượng. Ngay cả cuộc đối thoại AMQP đơn giản nhất cũng phức tạp hơn nhiều so với, ví
dụ, HTTP, và nhà phát triển ứng dụng không nên cần phải hiểu những thứ như định dạng
khung nhị phân để gửi một thông điệp đến hàng đợi thông điệp. Kiến trúc khách hàng AMQP
được khuyến nghị bao gồm một số tầng trừu tượng:
1 Một tầng framing. Tầng này lấy các phương thức giao thức AMQP, trong một định dạng cụ
thể cho từng ngôn ngữ (cấu trúc, lớp, v.v.) và biểu diễn chúng dưới dạng các khung cấp độ dây
dẫn. Tầng framing có thể được tạo cơ bản từ các đặc tả AMQP (được định nghĩa trong một
ngôn ngữ mô hình hóa giao thức, được thực hiện trong XML và được thiết kế đặc biệt cho
AMQP).
2 Một tầng quản lý kết nối. Tầng này đọc và ghi các khung AMQP và quản lý toàn bộ logic kết
nối và phiên. Trong tầng này, chúng ta có thể đóng gói toàn bộ logic mở kết nối và phiên, xử lý
lỗi, truyền và nhận nội dung, v.v. Nhiều phần lớn của tầng này có thể được tạo tự động từ các
đặc tả AMQP. Ví dụ, các đặc tả xác định phương thức nào mang nội dung, vì vậy logic "gửi
phương thức và sau đó tùy chọn là gửi nội dung" có thể được tạo tự động.
50

3 Một tầng API. Tầng này tiếp xúc một API cụ thể để các ứng dụng làm việc với. Tầng API có
thể phản ánh một số tiêu chuẩn hiện có, hoặc có thể tiếp xúc với các phương thức AMQP cấp
cao, tạo một ánh xạ như đã mô tả trước đây trong phần này. Các phương thức AMQP được
thiết kế để làm cho ánh xạ này đồng thời đơn giản và hữu ích. Tầng API có thể chính mình
được tạo thành từ nhiều tầng, ví dụ, một API cấp cao hơn được xây dựng trên cơ sở của API
phương thức AMQP.
Ngoài ra, thường có một loại tầng I/O nào đó, có thể rất đơn giản (đọc và ghi socket đồng bộ)
hoặc phức tạp (đa luồng I/O hoàn toàn không đồng bộ). Sơ đồ này cho thấy kiến trúc tổng quan
được khuyến nghị:
51

CHƯƠNG 3. ĐẶC ĐIỂM KỸ THUẬT CHỨC NĂNG
3.1. ĐẶC ĐIỂM KỸ THUẬT CHỨC NĂNG MÁY CHỦ

3.1.1. Thông điệp và nội dung
Một thông điệp là đơn vị nguyên tử của quá trình xử lý hệ thống định tuyến và xếp hàng
trung gian. Tin nhắn mang nội dung, bao gồm tiêu đề nội dung, chứa một tập hợp các thuộc
tính và nội dung nội dung, chứa một khối dữ liệu nhị phân mờ đục. Thông điệp AMQP là một
đơn vị dữ liệu được truyền giữa các ứng dụng sử dụng giao thức AMQP. Thông điệp bao gồm
hai phần chính:
- Header: Chứa thông tin về thông điệp, chẳng hạn như loại thông điệp, người gửi, người
nhận, và các thuộc tính khác.
- Body: Chứa nội dung của thông điệp, có thể là bất kỳ dữ liệu nào, chẳng hạn như văn
bản, nhị phân, hoặc đối tượng. Header của thông điệp AMQP
Header của thông điệp AMQP có chứa các thông tin sau:
- Type: Loại thông điệp.
- AppId: ID của ứng dụng gửi thông điệp.
- CorrelationId: ID để liên kết các thông điệp với nhau.
- ReplyTo: Hàng đợi để gửi phản hồi.
- Expiration: Thời hạn tồn tại của thông điệp.
- Priority: Độ ưu tiên của thông điệp.
- BodySize: Kích thước của nội dung thông điệp.
- Properties: Các thuộc tính tùy chọn
khác. Body của thông điệp AMQP:
- Body của thông điệp AMQP có chứa nội dung của thông điệp, có thể là bất kỳ dữ liệu
nào. Nội dung thông điệp có thể được định dạng bằng bất kỳ định dạng nào, chẳng hạn
như văn bản, nhị phân, hoặc đối tượng.
Nội dung AMQP:
- Nội dung AMQP là nội dung của thông điệp AMQP. Nó có thể được định dạng bằng
bất kỳ định dạng nào, chẳng hạn như văn bản, nhị phân, hoặc đối tượng.
52

Khi sử dụng giao thức AMQP, các ứng dụng cần phải xác định định dạng của nội dung
thông điệp. Điều này có thể được thực hiện bằng cách sử dụng các thuộc tính header của thông
điệp, hoặc bằng cách sử dụng các định dạng tiêu chuẩn, chẳng hạn như XML hoặc JSON.
Dưới đây là một số ví dụ về nội dung AMQP:
- Văn bản: Nội dung thông điệp là một chuỗi văn bản.
- Nhị phân: Nội dung thông điệp là một chuỗi nhị phân.
- Đối tượng: Nội dung thông điệp là một đối tượng Java, Python, hoặc ngôn ngữ lập
trình khác.
Ví dụ, một message có thể tương ứng với nhiều thực thể ứng dụng khác nhau:
- Thông báo cấp ứng dụng
- Một tập tin để chuyển
- Một khung của luồng dữ liệu, v.v.
Tin nhắn có thể liên tục. Một tin nhắn liên tục được giữ an toàn trên đĩa và đảm bảo được
gửi ngay cả khi có lỗi mạng nghiêm trọng, sự cố máy chủ, tràn, v.v.
Tin nhắn có thể có mức độ ưu tiên. Một tin nhắn có mức độ ưu tiên cao được gửi trước
các thư có mức độ ưu tiên thấp hơn đang chờ trong cùng một hàng đợi thư. Khi tin nhắn phải
được loại bỏ để duy trì mức chất lượng dịch vụ cụ thể, trước tiên máy chủ sẽ loại bỏ các tin
nhắn có mức độ ưu tiên thấp.
Máy chủ KHÔNG ĐƯỢC sửa đổi nội dung tin nhắn mà nó nhận và chuyển đến các ứng
dụng tiêu dùng. Máy chủ CÓ THỂ thêm thông tin vào tiêu đề nội dung nhưng KHÔNG
ĐƯỢC xóa hoặc sửa đổi thông tin hiện có.
3.1.2. Máy chủ ảo

Máy chủ ảo (vhost) là một vùng chứa logic trong một máy chủ trung gian AMQP (AMQP
Broker). Nó cung cấp một cách để tách biệt các ứng dụng khác nhau sử dụng cùng một máy
chủ trung gian. Mỗi vhost có các đặc quyền riêng, chẳng hạn như quyền truy cập vào các hàng
đợi, chủ đề và các tài nguyên khác.
Một máy chủ ảo bao gồm không gian tên riêng của nó, một tập hợp các trao đổi, hàng đợi
tin nhắn và tất cả các đối tượng liên quan. Mỗi kết nối PHẢI được liên kết với một máy chủ ảo
duy nhất.
53

Máy chủ ảo là một tính năng quan trọng của AMQP vì nó cho phép các ứng dụng chia sẻ
một máy chủ trung gian mà không cần lo lắng về việc xung đột với nhau. Ví dụ: một ứng dụng
có thể sử dụng một vhost để xử lý các thông điệp kinh doanh, trong khi một ứng dụng khác có
thể sử dụng một vhost khác để xử lý các thông điệp hệ thống.
Máy khách chọn máy chủ ảo trong phương thức Connection.Open, sau khi xác thực.
Điều này ngụ ý rằng sơ đồ xác thực của máy chủ được chia sẻ giữa tất cả các máy chủ ảo trên
máy chủ đó. Tuy nhiên, lược đồ ủy quyền được sử dụng CÓ THỂ là duy nhất cho mỗi máy
chủ ảo. Điều này nhằm mục đích hữu ích cho cơ sở hạ tầng lưu trữ được chia sẻ. Quản trị viên
cần các sơ đồ xác thực khác nhau cho mỗi máy chủ ảo nên sử dụng các máy chủ riêng biệt.
Tất cả các kênh trong kết nối hoạt động với cùng một máy chủ ảo. Không có cách nào để
giao tiếp với một máy chủ ảo khác trên cùng một kết nối, cũng như không có cách nào để
chuyển sang một máy chủ ảo khác mà không phá bỏ kết nối và bắt đầu lại.
Giao thức không cung cấp cơ chế để tạo hoặc định cấu hình máy chủ ảo - điều này được
thực hiện theo cách không xác định trong máy chủ và hoàn toàn phụ thuộc vào việc thực hiện.
Để tạo một máy chủ ảo trong AMQP, bạn cần sử dụng lệnh rabbitmqctl. Ví dụ: để tạo
một máy chủ ảo có tên là myvhost, bạn có thể chạy lệnh sau:
rabbitmqctl add_vhost myvhost
Sau khi tạo máy chủ ảo, bạn có thể thêm các ứng dụng vào nó bằng cách chỉ định tên
vhost khi kết nối với máy chủ trung gian. Ví dụ: để kết nối với máy chủ trung gian với tên
vhost là myvhost, bạn có thể sử dụng lệnh sau:
amqp://guest:guest@localhost:5672/myvhost
Các ứng dụng trong cùng một vhost có thể truy cập lẫn nhau bằng cách sử dụng tên vhost
làm tiền tố cho tên của tài nguyên. Ví dụ, để truy cập một hàng đợi có tên là myqueue trong
vhost myvhost, bạn có thể sử dụng tên sau:
myvhost/myqueue
Bạn có thể quản lý các máy chủ ảo trong AMQP bằng cách sử dụng lệnh rabbitmqctl. Ví dụ, để
liệt kê tất cả các máy chủ ảo trong một máy chủ trung gian, bạn có thể chạy lệnh sau:
rabbitmqctl list_vhosts
Để xóa một máy chủ ảo, bạn có thể sử dụng lệnh rabbitmqctl delete_vhost. Ví dụ, để xóa
máy chủ ảo có tên là myvhost, bạn có thể chạy lệnh sau:
rabbitmqctl delete_vhost myvhost
54

Dưới đây là một số lợi ích của việc sử dụng máy chủ ảo trong AMQP:
- Nó cho phép các ứng dụng khác nhau sử dụng cùng một máy chủ trung gian mà không
cần lo lắng về việc xung đột với nhau.
- Nó giúp bảo mật các ứng dụng bằng cách cho phép bạn cấp quyền truy cập vào các tài
nguyên khác nhau cho các nhóm người dùng khác nhau.
- Nó giúp quản lý các ứng dụng bằng cách cho phép bạn nhóm các ứng dụng có liên
quan lại với nhau.
3.1.3. Trao đổi
Trao đổi là một tác nhân định tuyến tin nhắn trong một máy chủ ảo. Một phiên bản trao
đổi (mà chúng ta thường gọi là "trao đổi") chấp nhận tin nhắn và thông tin định tuyến - chủ yếu
là khóa định tuyến - và chuyển tin nhắn đến hàng đợi tin nhắn hoặc đến các dịch vụ nội bộ.
Các sàn giao dịch được đặt tên trên cơ sở mỗi máy chủ ảo.
Các ứng dụng có thể tự do tạo, chia sẻ, sử dụng và phá hủy các phiên bản trao đổi, trong
giới hạn thẩm quyền của chúng.
Các sàn giao dịch có thể bền, tạm thời hoặc tự động xóa. Các sàn giao dịch bền vững kéo
dài cho đến khi chúng bị xóa. Trao đổi tạm thời kéo dài cho đến khi máy chủ tắt. Các trao đổi
tự động xóa kéo dài cho đến khi chúng không còn được sử dụng nữa.
Máy chủ cung cấp một tập hợp các loại trao đổi cụ thể. Mỗi loại trao đổi thực hiện một
thuật toán và kết hợp cụ thể, như được định nghĩa trong phần tiếp theo. AMQP yêu cầu một số
lượng nhỏ các loại trao đổi và khuyến nghị thêm một số loại khác. Hơn nữa, mỗi triển khai
máy chủ có thể thêm các loại trao đổi riêng.
Một trao đổi có thể định tuyến một tin nhắn duy nhất đến nhiều hàng đợi tin nhắn song
song. Điều này tạo ra nhiều trường hợp của tin nhắn được tiêu thụ độc lập.
Có bốn loại trao đổi trong AMQP:
- Direct exchange: Định tuyến tin nhắn đến một hàng đợi dựa trên khóa định tuyến
(routing key).
- Fanout exchange: Định tuyến tin nhắn đến tất cả các hàng đợi được ràng buộc với trao
đổi.
- Topic exchange: Định tuyến tin nhắn đến một hoặc nhiều hàng đợi dựa trên một mẫu
khóa định tuyến.
55

- Header exchange: Định tuyến tin nhắn đến một hoặc nhiều hàng đợi dựa trên các tiêu
đề của tin nhắn
Để tạo một trao đổi trong AMQP, bạn cần sử dụng lệnh rabbitmqctl. Ví dụ: để tạo một
trao đổi trực tiếp có tên my_exchange, bạn có thể chạy lệnh sau:
rabbitmqctl exchange_declare -p my_vhost direct my_exchange
Sau khi tạo trao đổi, bạn có thể ràng buộc trao đổi với một hoặc nhiều hàng đợi. Để ràng
buộc một trao đổi với một hàng đợi, bạn cần sử dụng lệnh rabbitmqctl. Ví dụ: để ràng buộc trao
đổi my_exchange với hàng đợi my_queue, bạn có thể chạy lệnh sau:
rabbitmqctl queue_bind my_vhost my_exchange my_queue
Bạn có thể quản lý các trao đổi trong AMQP bằng cách sử dụng lệnh rabbitmqctl. Ví dụ,
để liệt kê tất cả các trao đổi trong một máy chủ trung gian, bạn có thể chạy lệnh sau:
rabbitmqctl list_exchanges
Để xóa một trao đổi, bạn có thể sử dụng lệnh rabbitmqctl. Ví dụ: để xóa trao đổi
my_exchange, bạn có thể chạy lệnh sau:
rabbitmqctl exchange_delete -p my_vhost my_exchange
Dưới đây là một số lợi ích của việc sử dụng trao đổi trong AMQP:
- Nó cho phép bạn định tuyến tin nhắn đến các hàng đợi khác nhau một cách linh hoạt.
- Nó giúp bạn tách biệt các ứng dụng với nhau.
- Nó giúp bạn quản lý các tin nhắn một cách hiệu quả.
3.1.3.1 Loại The Direct Exchange Type
Direct exchange là loại trao đổi phổ biến nhất. Nó được sử dụng khi bạn muốn gửi một tin
nhắn đến một hàng đợi cụ thể dựa trên khóa định tuyến. Ví dụ: nếu bạn có một trao đổi có tên
order_exchange, bạn có thể gửi một tin nhắn đến hàng đợi order_completed_queue với khóa
định tuyến completed.
Các tính năng chính:
- Định tuyến khớp chính xác: Các tin nhắn chỉ được chuyển đến các hàng đợi có khóa
ràng buộc khớp chính xác với khóa định tuyến của tin nhắn.
- Định tuyến rõ ràng: Các nhà sản xuất phải biết chính xác các khóa định tuyến được sử
dụng bởi người tiêu dùng.
- Hiệu quả và xác định: Các quyết định định tuyến đơn giản và nhanh chóng.
56

Loại trao đổi trực tiếp hoạt động như sau:
- Một hàng đợi tin nhắn liên kết với trao đổi bằng khóa định tuyến, K.
- Nhà xuất bản gửi cho sàn giao dịch một tin nhắn với khóa định tuyến R.
- Tin nhắn được chuyển đến hàng đợi tin nhắn nếu K = R.
Máy chủ PHẢI thực hiện loại trao đổi trực tiếp và PHẢI khai báo trước trong mỗi máy
chủ ảo ít nhất hai trao đổi trực tiếp: một có tên amq.direct và một không có tên công khai đóng
vai trò là trao đổi mặc định cho các phương thức Publish.
Các trường hợp sử dụng phổ biến:
- Cân bằng tải
- Phân phối tác vụ
- Lọc tin nhắn
Lợi ích của trao đổi trực tiếp
- Đơn giản
- Hiệu suất
- Dự đoán
Các cân nhắc:
- Yêu cầu kiến thức trước về các khóa định tuyến.
- Không lý tưởng cho các kịch bản định tuyến phức tạp (xem xét trao đổi chủ đề hoặc
phát tán).
- Thông tin bổ sung:
Thể hiện trực quan:
Trao đổi mặc định: Các nhà môi giới AMQP thường cung cấp một trao đổi trực tiếp mặc
định có tên "amq.direct".
Hết hạn thông báo: Các thông báo có thể được cấu hình để hết hạn nếu không được tiêu
thụ trong một khoảng thời gian xác định.
Khả năng tồn tại của thông báo: Các thông báo có thể được duy trì trên đĩa để đảm bảo
tính bền vững.
57

Lưu ý rằng hàng đợi tin nhắn có thể liên kết bằng cách sử dụng bất kỳ giá trị khóa định
tuyến hợp lệ nào, nhưng hầu hết các hàng đợi tin nhắn sẽ liên kết bằng cách sử dụng tên riêng
của chúng làm khóa định tuyến.
Đặc biệt, tất cả các hàng đợi tin nhắn PHẢI ĐƯỢC tự động ràng buộc với trao đổi không
tên bằng cách sử dụng tên của hàng đợi tin nhắn làm khóa định tuyến
Ưu điểm và khuyết điểm khi sử dụng trao đổi trực tiếp:
Ưu điểm:
- Đơn giản để hiểu và triển khai
- Hiệu quả trong việc định tuyến các tin nhắn
- Đảm bảo giao hàng tin nhắn đáng tin cậy và nhất quán
Nhược điểm:
- Yêu cầu kiến thức trước về các khóa định tuyến
- Không lý tưởng cho các kịch bản định tuyến phức tạp
3.1.3.2 Loại Fanout Exchange
Fanout exchange được sử dụng khi bạn muốn gửi một tin nhắn đến tất cả các hàng đợi
được ràng buộc với trao đổi. Ví dụ: nếu bạn có một trao đổi có tên alert_exchange, bạn có thể
gửi một tin nhắn đến tất cả các hàng đợi được ràng buộc với trao đổi, chẳng hạn như
email_queue, sms_queue và slack_queue.
Các tính năng chính:
- Hoàn toàn bỏ qua khóa định tuyến: Khóa định tuyến không liên quan đối với trao đổi
phát tán. Mọi tin nhắn được xuất bản cho trao đổi phát tán đều được chuyển đến tất cả
các hàng đợi được ràng buộc, bất kể khóa ràng buộc của chúng.
- Phân phối không điều kiện: Các tin nhắn được phân phối đến tất cả người tiêu dùng mà
không có bất kỳ bộ lọc nào.
- Lý tưởng cho giao tiếp theo kiểu phát sóng: Là ví dụ về mô hình "xuất bản-đăng ký" để
phân phối tin nhắn rộng rãi.
Triển khai trao đổi Fanout

Bước 1
58

Tạo một thể hiện của Connectionlớp dưới dạng đối tượng đơn lẻ. Việc chia sẻ cùng một
phiên bản duy nhất của đối tượng Connection là an toàn và đây là phương pháp được khuyến
nghị.
package com.amqp.exchanges.all;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
public class ConnectionManager {
private static Connection connection = null;
public static Connection getConnection()
{ if (connection == null) {
try {
ConnectionFactory connectionFactory = new ConnectionFactory();
connection = connectionFactory.newConnection();
} catch (IOException | TimeoutException e) {
e.printStackTrace();
}
}
return connection;
}
}
Bước-2
Tạo/khai báo Fanout Exchange với tên my-fanout-exchange. Chúng ta sẽ sử dụng
Channel.exchangeDeclarephương pháp như dưới đây. Tạo một lớp có tên FanoutExchangevà
thêm mã bên dưới làm phương thức trong đó.
public static void declareExchange() throws IOException, TimeoutException
{ Channel channel = ConnectionManager.getConnection().createChannel();
59

//Declare my-fanout-exchange
channel.exchangeDeclare("my-fanout-exchange", BuiltinExchangeType.FANOUT, true);
channel.close();
}
Bước-3
Khai báo Hàng đợi sẽ được liên kết với trao đổi này với các khóa định tuyến trống.
Chúng ta sẽ tạo 3 hàng đợi là MobileQ, ACQvà LightQsử dụng Channel.queueDeclarephương
thức như bên dưới.
public static void declareQueues() throws IOException, TimeoutException {
//Create a channel - do no't share the Channel instance
Channel channel = ConnectionManager.getConnection().createChannel();
//Create the Queues
channel.queueDeclare("MobileQ", true, false, false, null);
channel.queueDeclare("ACQ", true, false, false, null);
channel.queueDeclare("LightQ", true, false, false, null);
channel.close();
}
Bước-4
Cho đến bây giờ chúng ta đã khai báo Hàng đợi và Trao đổi Fanout. Đã đến lúc liên kết
Hàng đợi với các khóa định tuyến trống. Bạn không nên đặt các khóa là null, thay vào đó hãy
sử dụng Chuỗi trống ""như bên dưới.
public static void declareBindings() throws IOException, TimeoutException
//Create bindings - (queue, exchange, routingKey) - routingKey != null
channel.queueBind("MobileQ", "my-fanout-exchange", "");
channel.queueBind("ACQ", "my-fanout-exchange", "");
channel.queueBind("LightQ", "my-fanout-exchange", "");
channel.close();
60

}
Bước-5
Bây giờ bạn cần người tiêu dùng lắng nghe từng Hàng đợi để xem họ nhận được thông
báo gì. Như bạn có thể thấy có 2 lệnh gọi lại, lệnh đầu tiên là DeliverCallback– với các tham số
(consumerTag, message)và lệnh thứ hai là CancelCallbackvới tham số – consumerTag.
public static void subscribeMessage() throws IOException, TimeoutException
channel.basicConsume("LightQ", true, ((consumerTag, message) -> {
System.out.println(consumerTag);
System.out.println("LightQ: " + new String(message.getBody()));
}), consumerTag -> {
});
channel.basicConsume("ACQ", true, ((consumerTag, message) -> {
System.out.println("ACQ: " + new String(message.getBody()));
});
channel.basicConsume("MobileQ", true, ((consumerTag, message) -> {
System.out.println("MobileQ: " + new String(message.getBody()));
});
}
Bước-6
61

Hãy xuất bản thông báo tới my-fanout-exchangeviệc sử dụng channel.basicPublish().
public static void publishMessage() throws IOException, TimeoutException {
Channel channel = ConnectionManager.getConnection().createChannel();
String message = "Main Power is ON";
channel.basicPublish("my-fanout-exchange", "", null, message.getBytes());
channel.close();
}
Bước-7
Cuối cùng, chúng ta sẽ tập hợp tất cả lại để làm việc. Chúng ta sẽ gọi từng phương thức
bên trong a public static void main()như dưới đây. Tôi sẽ sử dụng hai luồng riêng biệt để chạy
không đồng bộ các phương thức xuất bản và đăng ký.
public static void main(String[] args) throws IOException, TimeoutException {
FanoutExchange.declareQueues();
FanoutExchange.declareExchange();
FanoutExchange.declareBindings();
//Threads created to publish-subscribe asynchronously
Thread subscribe = new Thread() {
@Override
public void run()
{ try {
FanoutExchange.subscribeMessage();
}
}
};
Thread publish = new Thread() {
62

@Override
public void run()
{ try {
FanoutExchange.publishMessage();
}
}
};
subscribe.start();
publish.start();
}
Đầu ra:
amq.ctag-TH1MQlvM7o8aoVTH-E5g0w
LightQ: Main Power is ON
amq.ctag-EQ4HZrsj7SqzQhfS2lAFEw
ACQ: Main Power is ON
amq.ctag-y1Qns3gFs8fj_t6sq6qtBw
MobileQ: Main Power is ON
Như bạn có thể thấy ở đầu ra, một trao đổi fanout sẽ chuyển tiếp tin nhắn vô điều kiện tới
tất cả các Hàng đợi được liên kết. Điều này hữu ích khi bạn muốn phát một tin nhắn tới tất cả
Hàng đợi, một loại mô hình xuất bản/đăng ký.
Loại trao đổi fanout hoạt động như sau:
- Một hàng đợi tin nhắn liên kết với trao đổi mà không có đối số.
- Một nhà xuất bản gửi tin nhắn cho sàn giao dịch.
- Tin nhắn được chuyển đến hàng đợi tin nhắn vô điều kiện.
63

Việc trao đổi fanout là tầm thường để thiết kế và thực hiện. Loại trao đổi này và một sàn
giao dịch được khai báo trước được gọi là amq.fanout, là bắt buộc.
- Thông báo phát sóng: Gửi cảnh báo hoặc cập nhật cho nhiều người nhận.
- Tập hợp nhật ký: Thu thập nhật ký từ nhiều nguồn vào một kho lưu trữ tập trung.
- Ứng dụng trò chuyện: Phân phối tin nhắn cho tất cả người tham gia trong phòng trò
chuyện.
- Đồng bộ hóa trên nhiều hệ thống: Duy trì tính nhất quán giữa các hệ thống phân tán.
- Lợi ích:
- Đơn giản: Dễ dàng triển khai và hiểu.
- Phát sóng hiệu quả: Lý tưởng để phân phối tin nhắn đến nhiều đối tượng với chi phí
thấp.
- Khả năng mở rộng: Quản lý số lượng lớn người tiêu dùng mà không làm giảm hiệu
suất.
Các cân nhắc:
- Kiểm soát hạn chế: Không có định tuyến chọn lọc dựa trên nội dung hoặc sở thích của
người tiêu dùng.
- Khả năng quá tải: Người tiêu dùng nhận được tất cả các tin nhắn, ngay cả khi không
liên quan.
Ví dụ:
- Một ứng dụng thị trường chứng khoán có thể sử dụng trao đổi phát tán để phát sóng
cập nhật giá cho tất cả người tiêu dùng quan tâm.
- Một dịch vụ tin tức có thể sử dụng trao đổi phát tán để gửi tiêu đề tin tức mới nhất cho
tất cả người đăng ký.
Ưu điểm:
- Đơn giản để hiểu và triển khai
- Hiệu quả trong việc phân phối tin nhắn rộng rãi
- Có thể mở rộng để xử lý nhiều người tiêu
dùng Nhược điểm:
64

- Không có kiểm soát đối với việc phân phối tin nhắn
- Người tiêu dùng có thể nhận được các tin nhắn không liên quan
3.1.3.3 Loại trao đổi chủ đề
Topic exchange được sử dụng khi bạn muốn gửi một tin nhắn đến một hoặc nhiều hàng
đợi dựa trên một mẫu khóa định tuyến. Ví dụ: nếu bạn có một trao đổi có tên
product_exchange, bạn có thể gửi một tin nhắn đến hàng đợi product_details_queue với khóa
định tuyến product.*.
Trong bối cảnh hệ thống nhắn tin: Topic exchange là một loại cơ chế định tuyến được sử
dụng trong các hệ thống nhắn tin như RabbitMQ. Nó cho phép các nhà xuất bản gửi tin nhắn
đến các chủ đề cụ thể và người tiêu dùng đăng ký các chủ đề đó. Điều này khác với các cuộc
trao đổi trực tiếp, nơi các tin nhắn được gửi đến các hàng đợi cụ thể và các cuộc trao đổi
fanout, nơi các tin nhắn được gửi đến tất cả các hàng đợi được kết nối.
Trong bối cảnh xử lý ngôn ngữ tự nhiên: Topic exchange là một cách trao đổi thông tin về
các chủ đề khác nhau. Điều này có thể được thực hiện theo nhiều cách, chẳng hạn như thông
qua trò chuyện, đọc hoặc viết. Khi mọi người trao đổi thông tin về các chủ đề khác nhau, họ có
thể học hỏi những điều mới và mở rộng kiến thức của mình.
Cách thức hoạt động của topic exchange được mô tả như sau:
- Nhà xuất bản gửi tin nhắn đến topic exchange với một khóa định tuyến. Khóa định
tuyến là một chuỗi ký tự được sử dụng để xác định chủ đề của tin nhắn.
- Topic exchange sử dụng khóa định tuyến để định tuyến tin nhắn đến các hàng đợi đã
đăng ký với các chủ đề tương ứng.
- Người tiêu dùng đăng ký với topic exchange với một khóa định tuyến. Khi một tin
nhắn được gửi đến topic exchange với khóa định tuyến khớp với khóa định tuyến của
người tiêu dùng, tin nhắn sẽ được gửi đến người tiêu dùng.
Loại trao đổi chủ đề hoạt động như sau:
- Một hàng đợi tin nhắn liên kết với trao đổi bằng cách sử dụng mẫu định tuyến, P.
- Nhà xuất bản gửi cho sàn giao dịch một tin nhắn với khóa định tuyến R.
- Tin nhắn được chuyển đến hàng đợi tin nhắn nếu R khớp với P.
65

Khóa định tuyến được sử dụng để trao đổi chủ đề PHẢI bao gồm không hoặc nhiều từ
được phân tách bằng dấu chấm. Mỗi từ có thể chứa các chữ cái A-Z và a-z và các chữ số 0-9.
Mẫu định tuyến tuân theo các quy tắc tương tự như khóa định tuyến với phần bổ sung *
khớp với một từ và # khớp với 0 từ trở lên. Do đó, mô hình định tuyến *.stock.# khớp với các
khóa định tuyến usd.stock và eur.stock.db nhưng không khớp với stock.nasdaq.
Một thiết kế được đề xuất cho việc trao đổi chủ đề là giữ tập hợp tất cả các khóa định
tuyến đã biết và cập nhật điều này khi nhà xuất bản sử dụng khóa định tuyến mới. Có thể xác
định tất cả các ràng buộc cho một khóa định tuyến nhất định và do đó nhanh chóng tìm thấy
hàng đợi tin nhắn cho một tin nhắn. Loại trao đổi này là tùy chọn.
Máy chủ NÊN thực hiện kiểu trao đổi chủ đề và trong trường hợp đó, máy chủ PHẢI khai
báo trước trong mỗi máy chủ ảo ít nhất một trao đổi chủ đề, có tên là amq.topic.
Ví dụ: giả sử chúng ta có một topic exchange với các chủ đề sau:
weather.forecast
weather.news
weather.alerts
Một nhà xuất bản có thể gửi tin nhắn đến topic exchange với khóa định tuyến
weather.forecast để gửi dự báo thời tiết. Một người tiêu dùng có thể đăng ký với topic
exchange với khóa định tuyến weather.forecast để nhận tất cả các tin nhắn dự báo thời tiết.
3.1.3.4 Loại Headers Exchange
Headers Exchange là một cơ chế định tuyến linh hoạt trong các hệ thống nhắn tin như
RabbitMQ cho phép các tin nhắn được định tuyến dựa trên giá trị tiêu đề của chúng, thay vì chỉ
dựa trên khóa định tuyến. Điều này cung cấp một cách phân phối tin nhắn mạnh mẽ và linh
hoạt hơn đến các hàng đợi khác nhau dựa trên các tiêu chí cụ thể.
Headers Exchange được sử dụng khi bạn muốn gửi một tin nhắn đến một hoặc nhiều hàng
đợi dựa trên các tiêu đề của tin nhắn. Ví dụ: nếu bạn có một trao đổi có tên auth_exchange, bạn
có thể gửi một tin nhắn đến hàng đợi auth_success_queue với các tiêu đề status có giá trị
success.
Loại trao đổi tiêu đề hoạt động như sau:
66

- Hàng đợi thư được liên kết với trao đổi với một bảng đối số chứa các tiêu đề được
khớp cho ràng buộc đó và tùy chọn các giá trị mà chúng nên giữ. Khóa định tuyến
không được sử dụng.
- Nhà xuất bản gửi thư đến sàn giao dịch trong đó thuộc tính 'headers' chứa bảng tên và
giá trị.
- Thông báo được chuyển đến hàng đợi nếu thuộc tính headers khớp với các đối số mà
hàng đợi được liên kết.
Thuật toán khớp được điều khiển bởi một đối số ràng buộc đặc biệt được truyền dưới
dạng cặp giá trị tên trong bảng đối số. Tên của đối số này là 'x-match'. Nó có thể lấy một trong
hai giá trị, cho biết cách xử lý phần còn lại của các cặp giá trị tên trong bảng trong quá trình
khớp:
- 'all' ngụ ý rằng tất cả các cặp khác phải khớp với thuộc tính headers của thư để thư đó
được định tuyến (tức là và AND khớp)
- 'any' ngụ ý rằng thông báo sẽ được định tuyến nếu bất kỳ trường nào trong thuộc tính
headers khớp với một trong các trường trong bảng đối số (tức là khớp OR)
Một trường trong đối số liên kết khớp với một trường trong thư nếu trường trong đối số
liên kết không có giá trị và trường cùng tên có trong tiêu đề thư hoặc nếu trường trong đối số
liên kết có giá trị và trường cùng tên tồn tại trong tiêu đề thư và có cùng giá trị đó.
Bất kỳ trường nào bắt đầu bằng 'x-' ngoài 'x-match' đều được dành riêng để sử dụng trong
tương lai và sẽ bị bỏ qua.
Máy chủ NÊN thực hiện kiểu trao đổi tiêu đề và trong trường hợp đó, máy chủ PHẢI khai
báo trước trong mỗi máy chủ ảo ít nhất một trao đổi tiêu đề, có tên là amq.match.
Các tính năng chính của Headers Exchange:
- Định tuyến linh hoạt: Cho phép phân phối tin nhắn phức tạp dựa trên nhiều thuộc tính.
- Định tuyến dựa trên nội dung: Có thể kiểm tra nội dung tin nhắn trong tiêu đề để đưa
ra quyết định định tuyến.
- Lọc nâng cao: Hỗ trợ các mẫu khớp tiêu đề phức tạp để kiểm soát chi tiết.
- Định tuyến động: Các ràng buộc có thể được thêm hoặc sửa đổi khi chạy, thích ứng với
luồng tin nhắn thay đổi.
67

- Định tuyến tin nhắn dựa trên nội dung tin nhắn hoặc siêu dữ liệu (ví dụ: loại tin nhắn,
mức độ ưu tiên, ứng dụng nguồn).
- Triển khai lọc và ưu tiên dựa trên nội dung.
- Hỗ trợ các kịch bản định tuyến động dựa trên các sự kiện hoặc điều kiện bên ngoài.
- Tích hợp với các hệ thống khác sử dụng tiêu đề để phân loại và định tuyến tin nhắn.
3.1.3.5 Loại trao đổi hệ thống
Loại trao đổi hệ thống hoạt động như sau:
- Nhà xuất bản gửi cho sàn giao dịch một tin nhắn với khóa định tuyến S.
- Trao đổi hệ thống chuyển điều này đến một dịch vụ hệ thống S.
Các dịch vụ hệ thống bắt đầu bằng "amq." được dành riêng cho việc sử dụng AMQP. Tất
cả các tên khác có thể được sử dụng tự do bởi việc triển khai máy chủ. Loại trao đổi này là tùy
chọn.
3.1.3.6 Các loại Exchange được xác định triển khai
Tất cả các loại trao đổi không quy phạm PHẢI được đặt tên bắt đầu bằng "x-". Các loại
trao đổi không bắt đầu bằng "x-" được dành riêng để sử dụng trong tương lai trong tiêu chuẩn
AMQP.
3.1.4. Hàng đợi tin nhắn
Hàng đợi tin nhắn là một loại trung gian cho phép giao tiếp không đồng bộ giữa các ứng
dụng. Chúng hoạt động như một bộ đệm tạm thời cho tin nhắn, cho phép các ứng dụng gửi và
nhận tin nhắn mà không cần phải kết nối trực tiếp với nhau. Điều này khiến hàng đợi tin nhắn
trở thành một công cụ có giá trị để xây dựng các hệ thống phân tán có thể mở rộng và đáng tin
cậy.
Hàng đợi tin nhắn bao gồm ba thành phần chính:
- Nhà sản xuất: Các ứng dụng gửi tin nhắn đến hàng đợi.
- Hàng đợi: Một khu vực lưu trữ tạm thời cho tin nhắn.
- Người tiêu dùng: Các ứng dụng nhận và xử lý tin nhắn từ hàng đợi.
Các nhà sản xuất thêm tin nhắn vào hàng đợi và người tiêu dùng xóa tin nhắn khỏi hàng
đợi và xử lý chúng. Thứ tự xử lý tin nhắn thường là trước vào trước, ra trước (FIFO).
Lưu ý rằng với sự hiện diện của nhiều người đọc từ một hàng đợi hoặc giao dịch của
khách hàng, hoặc sử dụng các trường ưu tiên hoặc sử dụng bộ chọn tin nhắn hoặc tối ưu hóa
68

phân phối cụ thể triển khai, hàng đợi CÓ THỂ KHÔNG thể hiện các đặc điểm FIFO thực sự.
Cách duy nhất để đảm bảo FIFO là chỉ có một người tiêu dùng được kết nối với hàng đợi.
Hàng đợi có thể được mô tả là "FIFO yếu" trong những trường hợp này.
Lợi ích của việc sử dụng hàng đợi tin nhắn
Có nhiều lợi ích khi sử dụng hàng đợi tin nhắn, bao gồm:
- Tách biệt các ứng dụng: Hàng đợi tin nhắn tách biệt các ứng dụng với nhau, khiến
chúng trở nên độc lập và dễ bảo trì hơn.
- Giao tiếp không đồng bộ: Hàng đợi tin nhắn cho phép các ứng dụng giao tiếp không
đồng bộ, điều này có thể cải thiện hiệu suất và khả năng mở rộng.
- Giao hàng tin nhắn đáng tin cậy: Hàng đợi tin nhắn có thể đảm bảo rằng tin nhắn được
gửi đến người tiêu dùng, ngay cả khi người tiêu dùng không khả dụng khi tin nhắn
được gửi.
- Khả năng mở rộng: Hàng đợi tin nhắn có thể dễ dàng mở rộng để xử lý khối lượng tin
nhắn ngày càng tăng.
Hàng đợi tin nhắn được sử dụng trong nhiều ứng dụng khác nhau, bao gồm:
- Kiến trúc microservices: Hàng đợi tin nhắn là một cách phổ biến để giao tiếp giữa các
microservices trong một hệ thống phân tán.
- Xử lý sự kiện: Hàng đợi tin nhắn có thể được sử dụng để xử lý các sự kiện theo thời
gian thực, chẳng hạn như cập nhật thị trường chứng khoán hoặc bài đăng trên mạng xã
hội.
- Tự động hóa quy trình làm việc: Hàng đợi tin nhắn có thể được sử dụng để tự động hóa
quy trình làm việc, chẳng hạn như xử lý đơn hàng hoặc hỗ trợ khách hàng.
- Tích hợp dữ liệu: Hàng đợi tin nhắn có thể được sử dụng để tích hợp dữ liệu từ các
nguồn khác nhau.
Hàng đợi tin nhắn có thể bền, tạm thời hoặc tự động xóa. Hàng đợi tin nhắn bền vững
kéo dài cho đến khi chúng bị xóa. Hàng đợi tin nhắn tạm thời kéo dài cho đến khi máy chủ tắt.
Hàng đợi tin nhắn tự động xóa kéo dài cho đến khi chúng không còn được sử dụng nữa.
Hàng đợi tin nhắn giữ tin nhắn của họ trong bộ nhớ, trên đĩa hoặc một số kết hợp của
chúng. Hàng đợi tin nhắn được đặt tên trên cơ sở mỗi máy chủ ảo.
69

Hàng đợi tin nhắn giữ tin nhắn và phân phối chúng giữa một hoặc nhiều khách hàng tiêu
dùng. Một tin nhắn được định tuyến đến một hàng đợi tin nhắn không bao giờ được gửi đến
nhiều hơn một khách hàng trừ khi nó bị phẫn nộ sau khi thất bại hoặc từ chối.
Một hàng đợi tin nhắn có thể chứa các loại nội dung khác nhau cùng một lúc và độc lập.
Nghĩa là, nếu nội dung Basic và File được gửi đến cùng một hàng đợi tin nhắn, chúng sẽ được
gửi đến các ứng dụng tiêu thụ một cách độc lập theo yêu cầu.
3.1.5. Bindings
Ràng buộc là mối quan hệ giữa hàng đợi tin nhắn và trao đổi. Ràng buộc chỉ định các đối
số định tuyến cho trao đổi biết hàng đợi sẽ nhận được thư nào. Các ứng dụng tạo và phá hủy
các ràng buộc khi cần thiết để điều khiển luồng tin nhắn vào hàng đợi tin nhắn của chúng. Tuổi
thọ của các ràng buộc phụ thuộc vào hàng đợi tin nhắn mà chúng được xác định - khi hàng đợi
tin nhắn bị hủy, các ràng buộc của nó cũng bị phá hủy. Ngữ nghĩa cụ thể của phương thức
Queue.Bind phụ thuộc vào kiểu trao đổi.
Lợi ích của ràng buộc:
- Định tuyến linh hoạt: Cho phép các mẫu phân phối tin nhắn phức tạp ngoài thông điệp
điểm-điểm đơn giản.
- Tách biệt nhà sản xuất và người tiêu dùng: Nhà sản xuất không cần biết các hàng đợi
cụ thể đang tiêu thụ tin nhắn của họ, thúc đẩy sự liên kết lỏng lẻo.
- Khả năng mở rộng: Các hàng đợi bổ sung có thể được thêm và ràng buộc với các
exchange một cách động để xử lý khối lượng tin nhắn tăng lên.
- Kiểm soát quản trị: Các ràng buộc có thể được thao tác để điều chỉnh luồng tin nhắn
mà không cần sửa đổi mã nhà sản xuất hoặc người tiêu dùng.
Ràng buộc có thể được sử dụng trong nhiều trường hợp sử dụng khác nhau, bao gồm:
- Kiến trúc microservices: Ràng buộc cho phép các microservices giao tiếp với nhau một
cách linh hoạt và có thể mở rộng.
- Xử lý sự kiện: Ràng buộc cho phép các sự kiện được phân phối đến các ứng dụng xử
lý sự kiện thích hợp.
- Tự động hóa quy trình làm việc: Ràng buộc cho phép các quy trình làm việc được tự
động hóa một cách hiệu quả.
- Tích hợp dữ liệu: Ràng buộc cho phép dữ liệu được tích hợp từ các nguồn khác nhau.
70

3.1.6. Người tiêu dùng
Chúng tôi sử dụng thuật ngữ "người tiêu dùng" để chỉ cả ứng dụng máy khách và thực thể
kiểm soát cách một ứng dụng máy khách cụ thể nhận tin nhắn từ hàng đợi tin nhắn. Khi máy
khách "bắt đầu một người tiêu dùng", nó sẽ tạo ra một thực thể người tiêu dùng trong máy chủ.
Khi máy khách "hủy bỏ một người tiêu dùng", nó sẽ phá hủy một thực thể tiêu dùng trong máy
chủ. Người tiêu dùng thuộc về một kênh khách hàng duy nhất và khiến hàng đợi tin nhắn gửi
tin nhắn không đồng bộ đến khách hàng.
Các loại người tiêu dùng:
- Người tiêu dùng lâu dài: Giữ đăng ký của họ cho một hàng đợi ngay cả khi họ ngắt kết
nối. Họ nhận bất kỳ tin nhắn nào được xuất bản trong khi họ ngoại tuyến khi họ kết nối
lại.
- Người tiêu dùng không lâu dài: Chỉ đăng ký khi đang kết nối tích cực. Họ không nhận
được tin nhắn được xuất bản trong quá trình ngắt kết nối.
- Người tiêu dùng độc quyền: Có quyền truy cập độc quyền vào hàng đợi. Chỉ một người
tiêu dùng độc quyền có thể tiêu thụ từ một hàng đợi tại một thời điểm.
- Người tiêu dùng chia sẻ: Cho phép nhiều người tiêu dùng nhận tin nhắn từ cùng một
hàng đợi đồng thời.
Các tính năng bổ sung:
- Xác nhận tin nhắn: Người tiêu dùng có thể xác nhận tin nhắn riêng lẻ hoặc theo nhóm.
- Từ chối tin nhắn: Người tiêu dùng có thể từ chối các tin nhắn họ không thể xử lý hoặc
xếp hàng lại để xử lý sau.
- Ưu tiên người tiêu dùng: Gán các ưu tiên khác nhau cho người tiêu dùng để ảnh hưởng
đến phân phối tin nhắn.
- Kiểm soát lưu lượng: Người tiêu dùng có thể điều chỉnh tốc độ họ nhận tin nhắn để
ngăn quá tải.
Lợi ích của việc sử dụng người tiêu dùng trong AMQP:
- Tách biệt: Nhà sản xuất và người tiêu dùng không cần có sẵn đồng thời, thúc đẩy giao
tiếp không đồng bộ.
- Khả năng mở rộng: Nhiều người tiêu dùng có thể xử lý khối lượng tin nhắn tăng lên.
71

- Khả năng phục hồi: Người tiêu dùng lâu dài đảm bảo phân phối tin nhắn ngay cả trong
trường hợp người tiêu dùng gặp lỗi hoặc ngắt kết nối.
- Cân bằng tải: Người tiêu dùng chia sẻ phân phối khối lượng công việc xử lý tin nhắn
trên nhiều quy trình hoặc máy.
3.1.7. Chất lượng dịch vụ (QoS)
Các mức QoS: Định nghĩa các đảm bảo được cung cấp bởi bộ định tuyến tin nhắn về việc
phân phối và xử lý tin nhắn.
Đảm bảo phân phối: Đảm bảo rằng các tin nhắn được phân phối cho người tiêu dùng theo
mức được chỉ định.
Sắp xếp tin nhắn: Xác định liệu các tin nhắn có được phân phối theo thứ tự giống như khi
được xuất bản hay không.
Tính tin cậy: Đo lường khả năng tin nhắn bị mất hoặc bị trùng lặp.
Các mức QoS trong AMQP:
- At most once:
- Các tin nhắn được phân phối tối đa một lần.
- Không có đảm bảo phân phối.
- Tùy chọn nhanh nhất, nhưng tin nhắn có thể bị mất.
- At least once:
- Các tin nhắn được phân phối ít nhất một lần.
- Có thể xảy ra trùng lặp.
- Cân bằng giữa tốc độ và độ tin cậy.
- Exactly once:
- Các tin nhắn được phân phối chính xác một lần.
- Không có trùng lặp hoặc mất mát.
- Tùy chọn đáng tin cậy nhất, nhưng thường yêu cầu các tính năng và chi phí bổ
sung. Chọn mức QoS phù hợp:
- Xem xét các yếu tố như:
- Tầm quan trọng của đảm bảo phân phối tin nhắn
72

- Yêu cầu hiệu suất
- Mức độ phức tạp của hệ thống
- Sự đánh đổi giữa độ tin cậy và hiệu suất: Các mức QoS cao hơn thường yêu cầu nhiều
tài nguyên hơn và có thể ảnh hưởng đến hiệu suất.
Các tính năng QoS bổ sung trong AMQP:
- Khả năng tồn tại: Các tin nhắn có thể được lưu trữ trên đĩa để đảm bảo.
- Giao dịch: Nhiều thao tác tin nhắn có thể được nhóm để phân phối nguyên tử.
- Kiểm soát lưu lượng: Người tiêu dùng có thể quản lý tốc độ phân phối tin nhắn để
tránh quá tải.
Sử dụng phù hợp với:
- Phù hợp QoS với nhu cầu ứng dụng: Chọn mức phù hợp với yêu cầu của ứng dụng của
bạn.
- Xem xét các tác động của từng cấp: Hiểu sự đánh đổi giữa độ tin cậy và hiệu suất.
- Sử dụng các tính năng bổ sung khi cần thiết: Khả năng tồn tại, giao dịch và kiểm soát
lưu lượng có thể tăng cường độ tin cậy và khả năng quản lý.
Chất lượng dịch vụ kiểm soát tốc độ gửi tin nhắn. Chất lượng dịch vụ phụ thuộc vào loại
nội dung được phân phối. Nói chung, chất lượng dịch vụ sử dụng khái niệm "tìm nạp trước" để
chỉ định có bao nhiêu tin nhắn hoặc bao nhiêu octet dữ liệu sẽ được gửi trước khi khách hàng
xác nhận tin nhắn. Mục đích là để gửi dữ liệu tin nhắn trước, để giảm độ trễ.
3.1.8. Acknowledgements (ACK)
ACK là tín hiệu được người tiêu dùng gửi lại cho bộ định tuyến tin nhắn sau khi họ xử lý
thành công một tin nhắn. Điều này thông báo cho bộ định tuyến rằng tin nhắn có thể được xóa
khỏi hàng đợi, ngăn chặn xử lý trùng lặp và lãng phí tài nguyên.
Các loại ACK:
- Basic.ack: Cho biết việc xử lý thành công một tin nhắn duy nhất.
- Basic.nack: Cho biết một tin nhắn không thể được xử lý thành công và nên được
chuyển lại hàng đợi.
- Basic.reject: Cho biết một tin nhắn nên bị loại bỏ và không được chuyển
lại. Tầm qaunt trong ACK:
73

- Đảm bảo phân phối đáng tin cậy: Nếu không có ACK, bộ định tuyến sẽ không biết liệu
một tin nhắn đã được xử lý thành công hay không, có thể dẫn đến chuyển lại hoặc mất
mát.
- Ngăn chặn xử lý trùng lặp: Bằng cách xóa các tin nhắn khỏi hàng đợi sau ACK, người
tiêu dùng không thể vô tình xử lý chúng nhiều lần.
- Thúc đẩy xử lý lỗi: NACK và reject cho phép người tiêu dùng báo hiệu các vấn đề với
các tin nhắn cụ thể, cho phép các cơ chế xử lý lỗi hoạt động.
Cấu hình ACK:
- ACK tự động: Một số người tiêu dùng tự động gửi ACK sau khi nhận tin nhắn. Điều
này đơn giản hóa quá trình xử lý nhưng có thể dẫn đến vấn đề nếu tin nhắn bị lỗi sau
này.
- ACK thủ công: Người tiêu dùng có thể trì hoãn việc gửi ACK cho đến khi họ chắc
chắn rằng tin nhắn đã được xử lý thành công. Điều này cung cấp khả năng kiểm soát
tốt hơn nhưng thêm phức tạp.
Các cân nhắc bổ sung:
- Giao dịch: ACK có thể được nhóm trong giao dịch, đảm bảo tất cả các tin nhắn trong
giao dịch được xử lý thành công trước khi xác nhận hoặc lùi lại nếu xảy ra lỗi.
- Kiểm soát lưu lượng: Người tiêu dùng có thể sử dụng ACK để điều chỉnh tốc độ họ
nhận tin nhắn từ bộ định tuyến để tránh quá tải.
- Hiểu và sử dụng ACK đúng cách là điều cần thiết để xây dựng các hệ thống nhắn tin
mạnh mẽ và đáng tin cậy bằng AMQP. Việc triển khai chiến lược ACK phù hợp dựa
trên nhu cầu và mức độ quan trọng của tin nhắn có thể cải thiện đáng kể hiệu quả và độ
chính xác tổng thể của việc xử lý tin nhắn.
Một số ví dụ về cách sử dụng ACK trong AMQP:
- Đối với các tin nhắn không quan trọng: Bạn có thể sử dụng ACK tự động để tăng tốc
độ phân phối.
- Đối với các tin nhắn quan trọng: Bạn có thể sử dụng ACK thủ công để đảm bảo rằng
các tin nhắn sẽ được xử lý thành công, ngay cả khi có lỗi tạm thời.
- Đối với các tin nhắn có giá trị cao: Bạn có thể sử dụng ACK giao dịch để đảm bảo rằng
tất cả các tin nhắn trong giao dịch được xử lý thành công, ngay cả khi xảy ra lỗi.
74

Xác nhận là một tín hiệu chính thức từ ứng dụng khách đến hàng đợi tin nhắn rằng nó đã
xử lý thành công một tin nhắn. Có hai mô hình xác nhận có thể:
- Tự động, trong đó máy chủ xóa nội dung khỏi hàng đợi tin nhắn ngay khi nó gửi nội
dung đó đến một ứng dụng (thông qua các phương thức Phân phối hoặc Nhận Ok).
- Rõ ràng, trong đó ứng dụng khách phải gửi một phương thức Ack cho mỗi tin nhắn,
hoặc hàng loạt tin nhắn, mà nó đã xử lý.
Các lớp máy khách có thể tự thực hiện xác nhận rõ ràng theo nhiều cách khác nhau, ví dụ:
ngay khi nhận được tin nhắn hoặc khi ứng dụng chỉ ra rằng nó đã xử lý nó. Những khác biệt
này không ảnh hưởng đến AMQP hoặc khả năng tương tác.
3.1.9. Kiểm soát lưu lượng
Kiểm soát luồng là một thủ tục khẩn cấp được sử dụng để ngăn chặn luồng tin nhắn từ
một đồng nghiệp. Nó hoạt động theo cùng một cách giữa máy khách và máy chủ và được thực
hiện bởi lệnh Channel.Flow. Kiểm soát luồng là cơ chế duy nhất có thể ngăn chặn một nhà
xuất bản sản xuất quá mức. Người tiêu dùng có thể sử dụng cơ chế thanh lịch hơn của cửa sổ
tìm nạp trước, nếu nó sử dụng xác nhận tin nhắn (thường có nghĩa là sử dụng các giao dịch).
Cách kiểm soát lưu lượng hoạt động trong AMQP:
- Dựa trên người tiêu dùng: Người tiêu dùng khởi xướng kiểm soát lưu lượng bằng cách
báo hiệu sự sẵn sàng nhận tin nhắn.
- Hệ thống dựa trên tín dụng:
- Người tiêu dùng cấp "tín dụng" cho bộ định tuyến, cho biết khả năng xử lý tin nhắn
của họ.
- Mỗi tín dụng đại diện cho một tin nhắn mà bộ định tuyến có thể phân phối.
- Khi người tiêu dùng xử lý một tin nhắn, họ sẽ trả lại một tín dụng cho bộ định tuyến.
- Tự động điều chỉnh: Bộ định tuyến theo dõi mức tín dụng của người tiêu dùng và điều
chỉnh tốc độ phân phối cho phù hợp.
- Lùi lại: Nếu tín dụng của người tiêu dùng giảm xuống 0, nó sẽ báo hiệu lùi lại cho bộ
định tuyến để tạm dừng phân phối cho đến khi có thêm tín dụng khả dụng.
Lợi ích của kiểm soát lưu lượng:
- Ngăn chặn quá tải người tiêu dùng: Bảo vệ người tiêu dùng khỏi nhận nhiều tin nhắn
hơn họ có thể xử lý, giảm lỗi và mất dữ liệu.
75

- Duy trì ổn định hệ thống: Giúp giữ cho toàn bộ hệ thống nhắn tin ổn định và hiệu quả
bằng cách ngăn chặn tắc nghẽn và tranh chấp tài nguyên.
- Cải thiện tính phản hồi: Cho phép người tiêu dùng xử lý các đợt tin nhắn một cách lịch
sự mà không trở nên không phản hồi.
Thực hiện trong AMQP:
- Kiểm soát lưu lượng cấp kênh: Hoạt động trên các kênh riêng lẻ giữa người tiêu dùng
và bộ định tuyến.
- Kiểm soát lưu lượng toàn cầu: Áp dụng cho tất cả các kênh trên một kết nối.
- Các tham số có thể cấu hình: Người tiêu dùng có thể điều chỉnh cài đặt kiểm soát lưu
lượng dựa trên khả năng xử lý và khối lượng công việc của họ.
Tầm quan trọng của kiểm soát lưu lượng:
- Vô cùng quan trọng đối với các hệ thống nhắn tin đáng tin cậy và hiệu quả, đặc biệt là
những hệ thống xử lý khối lượng tin nhắn cao hoặc khối lượng công việc thay đổi.
- Giúp đảm bảo phân phối và xử lý tin nhắn trơn tru, ngay cả khi chịu tải nặng.
3.1.10. Quy ước đặt tên
Quy ước đặt tên giúp duy trì tính nhất quán và rõ ràng trong các hệ thống dựa trên
AMQP, cải thiện giao tiếp và hiểu biết giữa các thành phần.Các quy ước này chi phối việc đặt
tên cho các thực thể AMQP. Máy chủ và máy khách PHẢI tôn trọng các quy ước sau:
- Các loại trao đổi do người dùng xác định PHẢI có tiền tố là "x-"
- Phiên bản trao đổi tiêu chuẩn có tiền tố là "amq".
- Các dịch vụ hệ thống tiêu chuẩn có tiền tố là "amq".
- Hàng đợi tin nhắn tiêu chuẩn có tiền tố là "amq".
- Tất cả các tên hàng đợi trao đổi, hệ thống và tin nhắn khác đều nằm trong không gian
ứng dụng.
3.2. ĐẶC TẢ LỆNH AMQP (LỚP & PHƯƠNG PHÁP)
3.2.1. Ghi chú giải thích
Các phương pháp AMQP có thể xác định các giá trị tối thiểu cụ thể (chẳng hạn như số
lượng người tiêu dùng trên mỗi hàng đợi tin nhắn) vì lý do tương tác. Các cực tiểu này được
định nghĩa trong mô tả của mỗi lớp.
76

Việc triển khai AMQP phù hợp NÊN thực hiện các giá trị hào phóng hợp lý cho các lĩnh
vực như vậy, mức tối thiểu chỉ dành cho sử dụng trên các nền tảng có khả năng kém nhất.
Các ngữ pháp sử dụng ký hiệu này:
- • 'S:' cho biết dữ liệu hoặc phương thức được gửi từ máy chủ đến máy khách;
- • 'C:' cho biết dữ liệu hoặc phương thức được gửi từ máy khách đến máy chủ; 
+term hoặc +(...) biểu thức có nghĩa là '1 hoặc nhiều trường hợp';  *term hoặc *(...)
biểu thức có nghĩa là 'không có hoặc nhiều trường hợp'. Chúng tôi định nghĩa các
phương thức là:
+ • một yêu cầu đồng bộ ("yêu cầu syn"). Đồng nghiệp gửi NÊN đợi phương thức trả
lời cụ thể, nhưng CÓ THỂ thực hiện điều này không đồng bộ;  trả lời đồng bộ
("trả lời đồng bộ cho XYZ");  yêu cầu hoặc trả lời không đồng bộ ("không đồng
bộ").
3.2.2. Chi tiết lớp và phương thức
ID lớp và phương thức sau đây được định nghĩa trong đặc tả:
Lớp I Mô tả lớp học ngắn Phương I Mô tả phương pháp ngắn

D pháp D
Kết nối 10 Làm việc với các kết nối ổ cắm bắt đầu 10 Bắt đầu đàm phán kết nối
giật mình 11 Chọn cơ chế bảo mật và ngôn ngữ
an toàn 20 Thách thức về cơ chế bảo mật
an toàn 21 Cơ chế bảo mật đáp ứng
giai điệu 30 Đề xuất các thông số điều chỉnh kết nối
Tuneok 31 Thương lượng các thông số điều chỉnh kết nối
mở 40 Mở kết nối với máy chủ ảo
mở cửa 41 báo hiệu rằng kết nối đã sẵn sàng
đóng 50 Yêu cầu đóng kết nối
đóng cửa 51 Xác nhận đóng kết nối
kênh 20 Làm việc với các kênh mở 10 Mở kênh để sử dụng
mở cửa 11 báo hiệu rằng kênh đã sẵn sàng
Lớp ID Mô tả lớp học ngắn Phương ID Mô tả phương pháp ngắn
77

pháp
chảy 20 Bật/tắt luồng từ Peer
chảy 21 Xác nhận phương thức luồng
đóng 40 Yêu cầu đóng kênh
đóng cửa 41 Xác nhận đóng kênh
trao đổi 40 Làm việc với các sàn giao dịch tuyên bố 10 Xác minh Exchange tồn tại, tạo nếu cần
Tuyên bố 11 Xác nhận khai báo trao đổi
xóa 20 Xóa sàn giao dịch
xóaok 21 Xác nhận xóa sàn giao dịch
hàng 50 Làm việc với hàng đợi tuyên bố 10 Khai báo hàng đợi, tạo nếu cần
Tuyên bố 11 Xác nhận định nghĩa hàng đợi
ràng buộc 20 Ràng buộc hàng đợi với một sàn giao dịch
Bindok 21 Xác nhận liên kết thành công
Cởi trói 50 Hủy liên kết hàng đợi khỏi sàn giao dịch
Unbindok 51 Xác nhận hủy ràng buộc thành công
tẩy 30 Thanh lọc hàng đợi
Purgeok 31 xác nhận thanh lọc hàng đợi
xóa 40 Xóa hàng đợi
xóaok 41 Xác nhận xóa hàng đợi
cơ bản 60 Làm việc với nội dung cơ bản QoS 10 Chỉ định chất lượng dịch vụ
Qosok 11 Xác nhận QoS được yêu cầu
tiêu thụ 20 Bắt đầu một trình tiêu thụ hàng đợi
Người tiêu dùng 21 Xác nhận người tiêu dùng mới
hủy 30 Kết thúc trình tiêu thụ hàng đợi
Hủy bỏ 31 Xác nhận người tiêu dùng bị hủy
xuất bản 40 Phát hành thư
về 50 Trả về thư không thành công
giải thoát 60 Thông báo cho khách hàng về tin nhắn của
người tiêu dùng
được 70 Truy cập trực tiếp vào hàng đợi
nhận được 71 Cung cấp cho khách hàng một tin nhắn
nhận được trống 72 cho biết không có thư nào khả dụng
78

rỗng
Ack 80 Xác nhận một hoặc nhiều tin nhắn
bác bỏ 90 Từ chối thư đến
Khôi phục đồng 100 Gửi lại tin nhắn không được thừa nhận
bộ
phục hồi 110 Gửi lại tin nhắn không được thừa nhận
phục hồi 111 Xác nhận phục hồi
Tx 90 Làm việc với các giao dịch lựa 10 Chọn chế độ giao dịch tiêu chuẩn
Selectok 11 Xác nhận phương thức giao dịch
cam kết 20 cam kết giao dịch hiện tại
Lớp I Mô tả lớp học ngắn Phương I Mô tả phương pháp ngắn

D pháp D
cam kết 21 Xác nhận cam kết thành công
Rollback 30 Từ bỏ giao dịch hiện tại
Rollbackok 31 Xác nhận khôi phục thành công
3.3. THÔNG SỐ KỸ THUẬT

3.3.1. Số cổng được gán IANA
Số cổng AMQP tiêu chuẩn đã được IANA gán là 5672 cho cả TCP và UDP. Cổng UDP được
dành riêng để sử dụng trong triển khai đa diễn viên trong tương lai.
3.3.2. Định dạng cấp dây AMQP
3.3.2.1 Ngữ pháp giao thức chính thức
Chúng tôi cung cấp một ngữ pháp hoàn chỉnh cho AMQP (điều này được cung cấp để
tham khảo và bạn có thể thấy thú vị hơn khi bỏ qua các phần tiếp theo nêu chi tiết các loại
khung khác nhau và định dạng của chúng):
79

amqp = tiêu đề giao thức * amqp-unit
protocol-header = literal-AMQP protocol-

id protocol-version literal-AMQP =
%d65.77.81.80 ; "AMQP" protocol-id = %d0
; Phải là 0 protocol-version = %d0.9.1 ;
0-9-1
method = method-frame [ nội dung ]
method-frame = %d1 frame-properties method-payload frame-

end frame-properties = channel payload-size
kênh = ngắn uint ; Kích thước tải trọng

không bằng không = long-uint
method-payload = class-id
method-id *amqp-field class-
id = %x00.01-%xFF.FF method-
id = %x00.01-%xFF.FF amqp-
field = BIT / OCTET
/ uint ngắn / uint dài / dài-dài-uint
/ chuỗi ngắn / chuỗi dài
/ dấu thời
gian / bảng
trường
uint ngắn = 2 * OCTET dài uint

= 4 * OCTET dài-dài-uint = 8 *
OCTET
80

chuỗi ngắn = OCTET *string-char; chiều dài + chuỗi nội
dung-char = %x01 .. %xFF
chuỗi dài = long-uint *OCTET ; độ dài

+ dấu thời gian nội dung = dài-dài-
uint; 64-bit POSIX field-table = long-
uint *field-value-pair field-value-
pair = field-name-field-value field-
name = short-string field-value = 't'
boolean
/ 'b' ngắn-ngắn-nguyên
/ 'B' ngắn-ngắn-uint
/ 'U' số nguyên ngắn
/ 'u' ngắn uint
/ 'Tôi' long-int
/ 'tôi' long-uint
/ 'L' dài-dài nguyên
/ 'l' dài-dài-uint
/ 'f' phao
/ 'd' đôi
/ Giá trị thập phân 'D'
/ 's' chuỗi ngắn

Chúng tôi sử dụng cú pháp Augmented BNF được xác định trong IETF RFC 2234. Tóm lại,
• Tên của một quy tắc chỉ đơn giản là tên của chính nó.
• Thiết bị đầu cuối được chỉ định bởi một hoặc nhiều ký tự số với cách giải thích cơ bản
của các ký tự đó được biểu thị là 'd' hoặc 'x'.
81

• Một quy tắc có thể xác định một chuỗi giá trị đơn giản, có thứ tự bằng cách liệt kê một
chuỗi các tên quy tắc.
• Một loạt các giá trị số thay thế có thể được chỉ định nhỏ gọn, sử dụng dấu gạch ngang
("-") để chỉ ra phạm vi của các giá trị thay thế.
• Các yếu tố được đặt trong ngoặc đơn được coi là một yếu tố duy nhất, có nội dung
được sắp xếp nghiêm ngặt.
• Các phần tử được phân tách bằng dấu gạch chéo ("/") là các lựa chọn thay thế.
• Toán tử "*" đứng trước một phần tử cho biết sự lặp lại. Dạng đầy đủ là:
"<a>*<b>element", trong đó <a> và <b> là các giá trị thập phân tùy chọn, cho biết ít nhất <a>
và nhiều nhất là <b> lần xuất hiện của phần tử.
• Một quy tắc có dạng: "<n>element" tương đương với <n>*<n>element.
• Dấu ngoặc vuông bao quanh một chuỗi phần tử tùy chọn.
3.3.2.2 Tiêu đề giao thức
Máy khách PHẢI bắt đầu kết nối mới bằng cách gửi tiêu đề giao thức. Đây là một dãy 8 octet:
+---+---+---+---+---+---+---+---+
|' A'|' M'|' Hỏi'|' P'| 0 | 0 | 9 | 1 |
+---+---+---+---+---+---+---+---+
8 octet
Tiêu đề giao thức bao gồm các chữ cái viết hoa "AMQP" theo sau là hằng số %d0 thì:
1. Phiên bản chính của giao thức, được sử dụng theo mục 1.4.2.
2. Phiên bản phụ về giao thức, được sử dụng theo mục 1.4.2.
3. Bản sửa đổi giao thức, được sử dụng theo mục 1.4.2.
Mô hình đàm phán giao thức tương thích với các giao thức hiện có như HTTP khởi tạo kết nối
với chuỗi văn bản không đổi và với tường lửa đánh hơi sự khởi đầu của giao thức để quyết định
áp dụng quy tắc nào cho nó.
Máy khách và máy chủ đồng ý về một giao thức và phiên bản như sau:
• Máy khách mở một kết nối socket mới đến máy chủ AMQP và gửi tiêu đề giao thức.
82

• Máy chủ chấp nhận hoặc từ chối tiêu đề giao thức. Nếu nó từ chối, tiêu đề giao thức sẽ
ghi một tiêu đề giao thức hợp lệ vào ổ cắm và sau đó đóng ổ cắm.
• Nếu không, nó để ổ cắm mở và thực hiện giao thức cho phù hợp. Ví dụ:
Client gửi: Server phản hồi:
AMQP%d0.0.9.1 Phương pháp Connection.Start AMQP
%d0.1.0.0 AMQP%d0.0.9.1<Kết nối gần>
HTTP AMQP%d0.0.9.1<Đóng kết nối>
Hướng dẫn đối với người thực hiện:

• Máy chủ CÓ THỂ chấp nhận các giao thức không phải AMQP như HTTP.
• Nếu máy chủ không nhận ra 5 octet dữ liệu đầu tiên trên socket hoặc không hỗ trợ
phiên bản giao thức cụ thể mà máy khách yêu cầu, nó PHẢI ghi tiêu đề giao thức hợp lệ vào
socket, sau đó xả socket (để đảm bảo ứng dụng khách sẽ nhận được dữ liệu) và sau đó đóng kết
nối socket. Máy chủ CÓ THỂ in thông báo chẩn đoán để hỗ trợ gỡ lỗi.
• Máy khách CÓ THỂ phát hiện phiên bản giao thức máy chủ bằng cách cố gắng kết nối
với phiên bản được hỗ trợ cao nhất và kết nối lại với phiên bản thấp hơn nếu nhận được thông
tin đó từ máy chủ.
• Máy khách và máy chủ triển khai nhiều phiên bản AMQP nên sử dụng tất cả tám octet
của tiêu đề giao thức để xác định giao thức.
3.3.2.3 Định dạng khung chung
Tất cả các khung bắt đầu bằng tiêu đề 7-octet bao gồm trường kiểu (octet), trường kênh (số
nguyên ngắn) và trường kích thước (số nguyên dài):
0 1 3 7 cỡ + 7 cỡ + 8
+------+---------+----------------+ +-----------------------+
+-------------------+
| Loại | Kênh | Kích thước | | Tải trọng | |

Khung kết thúc | +------+---------+---------+ +
83

+-------------+ +-----------+ octet ngắn dài 'kích
thước' octet octet
AMQP định nghĩa các loại khung sau:

• Loại = 1, "METHOD": khung phương thức.
• Loại = 2, "HEADER": khung tiêu đề nội dung.
• Loại = 3, "BODY": khung nội dung.
• Loại = 4, "HEARTBEAT": khung nhịp tim.
Số kênh là 0 cho tất cả các khung hình toàn cầu cho kết nối và 1-65535 cho các khung tham
chiếu đến các kênh cụ thể.
Trường kích thước là kích thước của tải trọng, không bao gồm octet cuối khung. Mặc dù
AMQP giả định một giao thức được kết nối đáng tin cậy, chúng tôi sử dụng đầu khung để phát
hiện lỗi khung do triển khai máy khách hoặc máy chủ không chính xác.
• Octet cuối khung PHẢI luôn là giá trị thập lục phân %xCE.
• Nếu một peer nhận được một frame với một loại không phải là một trong những loại
được xác định này, nó PHẢI coi đây là một lỗi giao thức nghiêm trọng và đóng kết nối mà
không gửi thêm bất kỳ dữ liệu nào về nó
• Khi một người ngang hàng đọc một khung, nó PHẢI kiểm tra xem đầu khung có hợp
lệ hay không trước khi cố gắng giải mã khung. Nếu frame-end không hợp lệ, nó PHẢI coi đây
là lỗi giao thức nghiêm trọng và đóng kết nối mà không gửi thêm bất kỳ dữ liệu nào về nó. Nó
NÊN ghi lại thông tin về vấn đề, vì điều này cho thấy lỗi trong việc triển khai mã khung máy
chủ hoặc máy khách.
• Người ngang hàng KHÔNG ĐƯỢC gửi khung lớn hơn kích thước đã thỏa thuận. Một
ngang hàng nhận được một khung quá khổ PHẢI báo hiệu một ngoại lệ kết nối với mã trả lời
501 (lỗi khung).
• Số kênh PHẢI bằng 0 cho tất cả các khung nhịp tim và cho các khung phương thức,
tiêu đề và nội dung tham chiếu đến lớp Kết nối. Một peer nhận được số kênh khác không cho
một trong các khung này PHẢI báo hiệu ngoại lệ kết nối với mã trả lời 503 (lệnh không hợp
lệ).
84

3.3.2.4 Phương pháp tải trọng
Các cơ quan khung phương thức bao gồm một danh sách bất biến các trường dữ liệu, được gọi
là "đối số". Tất cả các cơ quan phương thức bắt đầu bằng số định danh cho lớp và phương
thức:
0 2 4
+----------+-----------+-------------- - -
| Class-ID | method-id | lập luận... +----------

+-----------+-------------- - ngắn ngắn ...

• Class-id và method-id là các hằng số được định nghĩa trong lớp AMQP và đặc tả
phương thức.
• Các đối số là một tập hợp các trường AMQP cụ thể cho từng phương thức.
• Giá trị id lớp từ %x00.01-%xEF.FF được dành riêng cho các lớp tiêu chuẩn AMQP.
• Giá trị id lớp từ %xF0.00-%xFF.FF (%d61440-%d65535) có thể được sử dụng bằng
cách triển khai cho các lớp mở rộng không chuẩn.
3.3.2.5 Trường dữ liệu AMQP
AMQP có hai cấp độ đặc tả trường dữ liệu: trường dữ liệu gốc được sử dụng cho các đối số
phương thức và các trường dữ liệu được truyền giữa các ứng dụng trong bảng trường. Bảng
trường chứa một siêu tập hợp các trường dữ liệu gốc.
3.3.2.5.1 Số nguyên
AMQP định nghĩa các kiểu số nguyên gốc sau:
• octet không dấu (8 bit).
• Số nguyên ngắn không dấu (16 bit).
• Số nguyên dài không dấu (32 bit).
• Số nguyên dài không dấu (64 bit).
Số nguyên và độ dài chuỗi luôn không được ký và được giữ theo thứ tự byte mạng. Chúng tôi
không cố gắng tối ưu hóa trường hợp khi hai hệ thống thấp-cao (ví dụ: hai CPU Intel) nói
chuyện với nhau.
85

• Người triển khai KHÔNG ĐƯỢC giả định rằng các số nguyên được mã hóa trong một
khung được căn chỉnh trên ranh giới từ bộ nhớ.
3.3.2.5.2 Bit
AMQP định nghĩa một loại trường bit gốc. Các bit được tích lũy thành toàn bộ octet. Khi hai
hoặc nhiều bit liền kề nhau trong một khung, chúng sẽ được đóng gói thành một hoặc nhiều
octet, bắt đầu từ bit thấp trong mỗi octet. Không có yêu cầu rằng tất cả các giá trị bit trong một
khung phải liền kề, nhưng điều này thường được thực hiện để giảm thiểu kích thước khung.
3.3.2.5.3 Dây
Chuỗi AMQP có độ dài thay đổi và được biểu thị bằng độ dài số nguyên theo sau là 0 hoặc
nhiều octet dữ liệu. AMQP định nghĩa hai loại chuỗi gốc:
• Chuỗi ngắn, được lưu trữ dưới dạng độ dài số nguyên không dấu 8 bit, theo sau là 0
hoặc nhiều octet dữ liệu. Các chuỗi ngắn có thể mang tới 255 octet dữ liệu UTF-8, nhưng có
thể không chứa octet bằng 0 nhị phân.
• Chuỗi dài, được lưu trữ dưới dạng độ dài số nguyên không dấu 32 bit theo sau là 0
octet dữ liệu trở lên. Chuỗi dài có thể chứa bất kỳ dữ liệu nào.
3.3.2.5.4 Timestamps
Dấu thời gian được giữ ở định dạng POSIX 64-bit time_t với độ chính xác là một giây. Bằng
cách sử dụng 64 bit, chúng tôi tránh được các vấn đề bao quanh trong tương lai liên quan đến
các giá trị time_t 31 bit và 32 bit.
3.3.2.5.5 Bảng hiện trường
Bảng trường là chuỗi dài chứa các cặp tên-giá trị được đóng gói. Các cặp tên-giá trị được mã
hóa dưới dạng chuỗi ngắn xác định tên và octet xác định loại giá trị và sau đó là chính giá trị.
Các loại trường hợp lệ cho bảng là phần mở rộng của các loại số nguyên, bit, chuỗi và dấu thời
gian gốc và được hiển thị trong ngữ pháp. Các trường số nguyên đa octet luôn được giữ theo
thứ tự byte mạng.
• Tên trường PHẢI bắt đầu bằng chữ cái, '$' hoặc '#' và có thể tiếp tục bằng chữ cái, '$'
hoặc '#', chữ số hoặc gạch chân, với độ dài tối đa là 128 ký tự.
• Máy chủ NÊN xác thực tên trường và khi nhận được tên trường không hợp lệ, nó NÊN
báo hiệu ngoại lệ kết nối với mã trả lời 503 (lỗi cú pháp).
• Giá trị thập phân không nhằm mục đích hỗ trợ các giá trị dấu phẩy động, mà là các giá
trị kinh doanh điểm cố định như tỷ giá tiền tệ và số tiền. Chúng được mã hóa dưới dạng octet
86

đại diện cho số lượng địa điểm theo sau là một số nguyên được ký dài. Số octet 'thập phân'
không được ký.
• Các trường trùng lặp là bất hợp pháp. Hành vi của một peer đối với một bảng chứa
các trường trùng lặp là không xác định.
3.3.2.5.6 Khung nội dung
Một số phương pháp cụ thể (Xuất bản, Phân phối, v.v.) mang nội dung. Vui lòng tham khảo
chương "Thông số kỹ thuật chức năng" để biết thông số kỹ thuật của từng phương pháp và liệu
phương pháp có mang nội dung hay không. Các phương pháp mang nội dung làm như vậy vô
điều kiện.
Nội dung bao gồm danh sách từ 1 khung trở lên như sau:
1. Chính xác là một khung tiêu đề nội dung cung cấp các thuộc tính cho nội dung.
2. Tùy chọn, một hoặc nhiều khung nội dung nội dung.
Khung nội dung trên một kênh cụ thể hoàn toàn tuần tự. Nghĩa là, chúng có thể được trộn lẫn
với các khung cho các kênh khác, nhưng không có hai khung nội dung nào từ cùng một kênh
có thể bị trộn lẫn hoặc chồng chéo, cũng như không thể trộn lẫn khung nội dung cho một nội
dung với các khung phương pháp trên cùng một kênh.
Lưu ý rằng bất kỳ khung không phải nội dung nào cũng đánh dấu rõ ràng phần cuối của nội
dung. Mặc dù kích thước của nội dung nổi tiếng từ tiêu đề nội dung (và do đó cũng là số lượng
khung nội dung), điều này cho phép người gửi hủy bỏ việc gửi nội dung mà không cần phải
đóng kênh.
 Một ứng dụng ngang hàng nhận được nội dung không đầy đủ hoặc có định dạng xấu PHẢI
đưa ra ngoại lệ kết nối với mã trả lời 505 (khung không mong muốn). Điều này bao gồm thiếu
tiêu đề nội dung, ID lớp sai trong tiêu đề nội dung, thiếu khung nội dung, v.v.
3.3.2.5.7 Tiêu đề nội dung
Tải trọng tiêu đề nội dung có định dạng sau:
0 2 4 12 14
+----------+--------+-----------+----------------
+------------- - | Class-ID | Trọng lượng | Kích thước
cơ thể | Cờ chỗ nghỉ | danh sách tài sản... +----------
87

+--------+-----------+----------------+------------- -
ngắn, ngắn, dài, dài, ngắn...

• Class-id PHẢI khớp với method frame class id. Peer PHẢI phản hồi class-id không
hợp lệ bằng cách đưa ra ngoại lệ kết nối với mã trả lời 501 (lỗi khung).
• Trường trọng lượng không được sử dụng và phải bằng không.
• Kích thước cơ thể là giá trị 64 bit xác định tổng kích thước của nội dung nội dung,
nghĩa là tổng kích thước nội dung cho các khung nội dung sau. Số 0 chỉ ra rằng không có
khung nội dung nội dung.
• Cờ thuộc tính là một mảng các bit cho biết sự hiện diện hay vắng mặt của từng giá trị
thuộc tính theo trình tự. Các bit được sắp xếp từ cao nhất đến thấp nhất - bit 15 cho biết thuộc
tính đầu tiên.
• Cờ thuộc tính có thể chỉ định hơn 16 thuộc tính. Nếu bit cuối cùng (0) được đặt, điều
này cho biết rằng trường cờ thuộc tính khác theo sau. Có nhiều trường cờ thuộc tính khi cần
thiết.
• Giá trị thuộc tính là các trường dữ liệu AMQP dành riêng cho lớp.
• Thuộc tính bit CHỈ được biểu thị bằng cờ thuộc tính tương ứng của chúng (1 hoặc 0)
và không bao giờ có trong danh sách thuộc tính.
• Số kênh trong khung nội dung KHÔNG ĐƯỢC bằng không. Một ứng dụng ngang
hàng nhận được số kênh bằng không trong khung nội dung PHẢI báo hiệu ngoại lệ kết nối với
mã trả lời 504 (lỗi kênh).
3.3.2.5.8 Nội dung
Tải trọng nội dung là một khối nhị phân mờ đục theo sau là một octet cuối khung:
+-----------------------+ +--------------------+
| Tải trọng nhị phân mờ đục | | Khung kết thúc |
+-----------------------+ +--------------------+
Nội dung có thể được chia thành nhiều khung nếu cần. Kích thước tối đa của tải trọng khung
được cả hai đồng nghiệp thỏa thuận trong quá trình đàm phán kết nối.
88

 Một người ngang hàng PHẢI xử lý nội dung được chia thành nhiều khung bằng cách lưu trữ
các khung này dưới dạng một tập hợp duy nhất và truyền lại chúng nguyên trạng, chia thành
các khung nhỏ hơn hoặc được ghép thành một khối duy nhất để gửi đến một ứng dụng.
3.3.2.5.9 Khung nhịp tim
Khung nhịp tim cho người nhận biết rằng người gửi vẫn còn sống. Tốc độ và thời gian của
khung nhịp tim được thương lượng trong quá trình điều chỉnh kết nối.
• Khung nhịp tim PHẢI có số kênh bằng không. Một ngang hàng nhận được khung
nhịp tim không hợp lệ PHẢI đưa ra ngoại lệ kết nối với mã trả lời 501 (lỗi khung).
• Nếu đồng nghiệp không hỗ trợ nhịp tim, nó PHẢI loại bỏ khung nhịp tim mà không
báo hiệu bất kỳ lỗi hoặc lỗi nào.
• Máy khách sẽ bắt đầu gửi nhịp tim sau khi nhận được phương pháp Connection.Tune
và bắt đầu theo dõi nhịp tim sau khi nhận được Connection.Open. Máy chủ sẽ bắt đầu gửi và
theo dõi nhịp tim sau khi nhận được Connection.Tune-Ok.
• Đồng nghiệp nên nỗ lực hết sức để gửi nhịp tim trong khoảng thời gian quy định. Nhịp
tim có thể được gửi bất cứ lúc nào. Bất kỳ octet được gửi nào cũng là sự thay thế hợp lệ cho
nhịp tim, do đó nhịp tim chỉ phải được gửi nếu không có lưu lượng AMQP không nhịp tim nào
được gửi lâu hơn một khoảng thời gian nhịp tim. Nếu một peer phát hiện không có lưu lượng
truy cập đến (tức là octet nhận được) trong hai khoảng thời gian nhịp tim hoặc lâu hơn, nó sẽ
đóng kết nối mà không cần tuân theo bắt tay Connection.Close / Close-Ok và ghi lại lỗi.
• Nhịp tim nên tiếp tục cho đến khi đóng ổ cắm kết nối, kể cả trong và sau khi bắt tay
Connection.Close/Close-Ok.
3.3.2.6 Ghép kênh
AMQP cho phép các đồng nghiệp tạo ra nhiều luồng kiểm soát độc lập. Mỗi kênh hoạt động
như một kết nối ảo chia sẻ một ổ cắm duy nhất:
khung khung khung khung + ----------- +-----------------------+
----------- +---------------------+
| Kênh | Kênh | Kênh | Kênh |
+-----------+-----------+-----------+--------------------+
| ổ cắm |
+------------------------------------------------------------------------------------+
89

• Một đồng đẳng AMQP CÓ THỂ hỗ trợ nhiều kênh. Số lượng kênh tối đa được xác
định khi đàm phán kết nối và một người ngang hàng CÓ THỂ thương lượng điều này xuống
còn 1.
• Mỗi người ngang hàng NÊN cân bằng lưu lượng truy cập trên tất cả các kênh mở một
cách công bằng. Việc cân bằng này có thể được thực hiện trên cơ sở mỗi khung hình hoặc trên
cơ sở lượng lưu lượng truy cập trên mỗi kênh. Một người ngang hàng KHÔNG NÊN cho phép
một kênh rất bận rộn bỏ đói tiến trình của một kênh ít bận rộn hơn.
3.3.2.7 Đảm bảo khả năng hiển thị
Máy chủ phải đảm bảo rằng các quan sát của khách hàng về trạng thái máy chủ là nhất
quán. Ví dụ sau minh họa ý nghĩa của quan sát khách hàng trong bối cảnh này:
• Client 1 và Client 2 được kết nối với cùng một vhost
• Khách hàng 1 khai báo hàng đợi
• Khách hàng 1 nhận được Declare.Ok (một ví dụ về 'quan sát')
• Khách hàng 1 nói với Khách hàng 2 về nó
• Khách hàng 2 thực hiện khai báo thụ động của cùng một hàng đợi
Đảm bảo khả năng hiển thị đảm bảo rằng Khách hàng 2 nhìn thấy hàng đợi (trong trường hợp
không xóa)
3.3.2.8 Đóng kênh
Máy chủ sẽ xem xét một kênh đóng khi bất kỳ điều nào trong số này xảy ra:
1. Ngang hàng đóng kênh hoặc kết nối chính bằng cách sử dụng bắt tay Đóng/Đóng-Ok.
2. Đồng nghiệp đưa ra ngoại lệ trên kênh hoặc kết nối dành cho phụ huynh.
3. Một trong hai ngang hàng đóng ổ cắm kết nối cha mà không cần bắt tay Close/Close-
Ok.
Khi máy chủ đóng kênh, mọi thư không được xác nhận trên kênh đều được đánh dấu để gửi lại.
Khi máy chủ đóng kết nối, nó sẽ xóa mọi tính năng tự động xóa thuộc sở hữu của kết nối đó.
3.3.2.9 Đồng bộ hóa nội dung
Trong một số trường hợp nhất định, các phương thức yêu cầu-phản hồi đồng bộ có tác động
đến việc phân phối nội dung không đồng bộ trên cùng một kênh, bao gồm:
90

• Các phương thức Basic.Consumption và Basic.Cancel, bắt đầu và dừng luồng tin nhắn
từ hàng đợi thư.
• Phương thức Basic.Recover, yêu cầu máy chủ gửi lại tin nhắn đến một kênh.
• Các phương thức Queue.Bind, Queue.Unbind và Queue.Purge, ảnh hưởng đến luồng
thư vào hàng đợi thư.
• Ảnh hưởng của yêu cầu-phản hồi KHÔNG ĐƯỢC hiển thị trên kênh trước phương
thức phản hồi và PHẢI hiển thị sau đó.
3.3.2.10 Đảm bảo đặt hàng nội dung
Thứ tự của các phương thức chảy qua một kênh là ổn định: các phương thức được nhận theo
cùng thứ tự khi chúng được gửi. Điều này được đảm bảo bởi truyền tải TCP / IP được sử dụng
bởi AMQP. Hơn nữa, nội dung được xử lý một cách ổn định bởi máy chủ. Cụ thể, nội dung
chảy qua một đường dẫn duy nhất trong máy chủ sẽ vẫn được sắp xếp. Đối với nội dung của
một mức độ ưu tiên nhất định chảy qua một đường dẫn duy nhất, chúng tôi xác định đường dẫn
xử lý nội dung bao gồm một kênh đến, một trao đổi, một hàng đợi và một kênh đi.
+ Máy chủ PHẢI duy trì thứ tự nội dung chảy qua một đường dẫn xử lý nội dung duy nhất, trừ
khi trường được phân phối lại được đặt trên phương thức Basic.Deliver hoặc Basic.Get-Ok và
theo các quy tắc chi phối các điều kiện theo đó trường đó có thể được đặt.
3.3.2.11 Xử lý lỗi
3.3.2.11.1 Ngoại lệ
Sử dụng mô hình lập trình 'ngoại lệ' tiêu chuẩn, AMQP không báo hiệu thành công, chỉ thất
bại. AMQP xác định hai mức ngoại lệ :
1. Ngoại lệ kênh. Những điều này đóng kênh gây ra lỗi. Ngoại lệ kênh thường là do lỗi
'mềm' không ảnh hưởng đến phần còn lại của ứng dụng.
2. Ngoại lệ kết nối. Chúng đóng kết nối ổ cắm và thường là do lỗi 'cứng' cho thấy lỗi lập
trình, cấu hình xấu hoặc trường hợp khác cần can thiệp.
Chúng tôi ghi lại các khẳng định một cách chính thức trong định nghĩa của từng lớp và phương
thức.
91

3.3.2.11.2 Định dạng mã trả lời
Mã trả lời AMQP phù hợp với định nghĩa "Lý thuyết và mức độ nghiêm trọng của mã trả lời"
từ IETF RFC 2821.
3.3.2.12 Hạn chế
Các thông số kỹ thuật AMQP áp đặt các giới hạn này đối với các phần mở rộng trong tương lai
của AMQP hoặc các giao thức từ cùng một định dạng cấp dây:
• Số kênh trên mỗi kết nối: Số kênh 16 bit.
• Số lớp giao thức: ID lớp 16 bit.
• Số phương thức trên mỗi lớp giao thức: ID phương thức 16 bit. Các thông số kỹ thuật
AMQP áp đặt các giới hạn này đối với dữ liệu:
• Kích thước tối đa của một chuỗi ngắn: 255 octet.
• Kích thước tối đa của một chuỗi dài hoặc bảng trường: Kích cỡ 32 bit.
• Kích thước tối đa của tải trọng khung: kích thước 32 bit.
• Kích thước tối đa của nội dung: Kích thước 64 bit.
Máy chủ hoặc máy khách cũng có thể áp đặt các giới hạn riêng về tài nguyên như số lượng kết
nối đồng thời, số lượng người tiêu dùng trên mỗi kênh, số lượng hàng đợi, v.v. Những điều
này không ảnh hưởng đến khả năng tương tác và không được chỉ định.
3.3.2.13 An ninh
3.3.2.13.1 Mục tiêu và nguyên tắc
Chúng tôi bảo vệ chống lại việc khai thác tràn bộ đệm bằng cách sử dụng bộ đệm được chỉ
định độ dài ở tất cả các nơi. Tất cả dữ liệu được cung cấp bên ngoài có thể được xác minh dựa
trên độ dài tối đa cho phép bất cứ khi nào bất kỳ dữ liệu nào được đọc. Dữ liệu không hợp lệ
có thể được xử lý rõ ràng, bằng cách đóng kênh hoặc kết nối.
3.3.2.13.2 Tấn công từ chối dịch vụ
AMQP xử lý lỗi bằng cách trả về mã trả lời và sau đó đóng kênh hoặc kết nối. Điều này tránh
các trạng thái mơ hồ sau lỗi. Máy chủ nên giả định rằng các điều kiện ngoại lệ trong giai đoạn
đàm phán kết nối là do nỗ lực thù địch để có quyền truy cập vào máy chủ. Phản ứng chung đối
với bất kỳ điều kiện ngoại lệ nào trong đàm phán kết nối là tạm dừng kết nối đó (có lẽ là một
luồng) trong khoảng thời gian vài giây và sau đó đóng kết nối mạng. Điều này bao gồm lỗi cú
pháp, dữ liệu quá khổ và số lần xác thực không thành công. Máy chủ NÊN ghi lại tất cả các
ngoại lệ như vậy và gắn cờ hoặc chặn máy khách gây ra nhiều lỗi
92

93

Giao Thuc Amqp Ky Thuat Ket Noi Mang

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Giao Thuc Amqp Ky Thuat Ket Noi Mang

Uploaded by

Copyright:

Available Formats

Giao-thfíc-AMQP - Kỹ thuật kết nối mạng

Mạng máy tính (Trường Đại học Thăng Long)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

GIAO THỨC AMQP VÀ ỨNG DỤNG

MÔN HỌC: KỸ THUẬT KẾT NỐI MẠNG

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

CHƯƠNG 1. GIỚI THIỆU CHUNG......................................................................................

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

1.1. TỔNG QUAN VỀ IOT

1.1.1. Khái niệm IoT

1.1.2. Cấu trúc của một hệ thống IoT

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

1.1.3. Cách hoạt động của IoT

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

1.1.4. Ưu và nhược điểm của IoT

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

1.1.5. Lợi ích của IoT

+ Tăng cường tính bảo mật:

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

+ Đưa ra các giải pháp khác biệt:

Ví dụ về các thiết bị IoT?

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

+ Tự Quyết Định Quyền Riêng Tư:

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

• Phần Mềm Bảo Mật:

• Cập Nhật Phần Mềm Định Kỳ:

• Quản Lý Khóa và Đăng Nhập:

• Chính Sách Bảo Mật:

1.2. TỔNG QUAN VỀ GIAO THỨC AMQP

1.2.1. Khái niệm AMQP

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

1.4.1. Tại sao chọn AMQP?

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

- Để tương thích với các phiên bản tương lai.

1.4.5. Quy mô Triển khai

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

1.5.1. Hướng dẫn cho Người triển khai

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

2.1. KIẾN TRÚC CHUNG

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)

2.1.2.3.3 Ràng buộc

Downloaded by Thanh Lê (thanhcanmu1234@gmail.com)