Amqp0 9 1

Machine Translated by Google
AMQP
Giao thức xếp hàng tin nhắn nâng cao
Đặc tả giao thức
Phiên bản 0-9-1, ngày 13 tháng 11 năm 2008
Tiêu chuẩn nhắn tin có mục đích chung
Người đóng góp kỹ thuật
Sanjay Aiyagari hệ thống Cisco Alexis Richardson Công nghệ thỏ
Matthew Arrott Đổi mới quy trình xoắn Martin Ritchie JPMorgan Chase
Đánh dấu Atwell JPMorgan Chase Shahrokh Sadjadi hệ thống Cisco
Jason Brome Công nghệ đặc phái viên Rafael Schloming Mũ đỏ
Alan Conway Mũ đỏ Steven Shaw JPMorgan Chase
Robert Godfrey JPMorgan Chase Martin Sustrik Tập đoàn iMatix
Robert Greig JPMorgan Chase Carl Trieloff Mũ đỏ
Pieter Hintjens Tập đoàn iMatix Kim van der Riet Mũ đỏ
John O'Hara JPMorgan Chase Steve Vinoski Công nghệ IONA
Công nghệ thỏ Matthias Radestock

Bản quyền (c) 2006-2008. Đã đăng ký Bản quyền. Xem Thông báo và Giấy phép.
Thông báo Bản quyền Bản

quyền © 2006-2008 Cisco Systems, Credit Suisse, Deutsche Börse Systems, Envoy Technologies, Inc.,
Goldman Sachs, IONA Technologies PLC, iMatix Corporation, JPMorgan Chase Bank Inc. NA, Novell,
Rabbit Technologies Ltd., Red Hat, Inc., TWIST Process Innovations Ltd, WS02, Inc. và 29West Inc.
Mọi quyền được bảo lưu.
Giấy phép
Cisco Systems, Credit Suisse, Deutsche Börse Systems, Envoy Technologies, Inc., Goldman Sachs, IONA Technologies PLC, iMatix
Corporation, JPMorgan Chase Bank Inc. NA, Novell, Rabbit Technologies Ltd., Red Hat, Inc., TWIST Process Innovations Ltd. , WS02, Inc.
và 29West Inc. (gọi chung là "Tác giả"), mỗi bên qua đây cấp cho bạn giấy phép toàn cầu, vĩnh viễn, miễn phí bản quyền, không thể
chuyển nhượng, không độc quyền để (i) sao chép, hiển thị, phân phối và triển khai Hàng đợi Nhắn tin Nâng cao Giao thức ("AMQP")
Thông số kỹ thuật và (ii) các Tuyên bố được cấp phép do Tác giả nắm giữ, tất cả đều nhằm mục đích triển khai Đặc tả giao thức hàng đợi
tin nhắn nâng cao. Giấy phép của bạn và mọi quyền theo Thỏa thuận này sẽ chấm dứt ngay lập tức mà không cần thông báo từ bất kỳ Tác
giả nào nếu bạn đưa ra bất kỳ khiếu nại, vụ kiện, yêu cầu hoặc hành động nào liên quan đến Đặc tả Giao thức Hàng đợi Tin nhắn Nâng cao
chống lại bất kỳ Tác giả nào. Sau khi chấm dứt, bạn sẽ hủy tất cả các bản sao của Đặc tả Giao thức Hàng đợi Tin nhắn Nâng cao mà bạn
sở hữu hoặc kiểm soát.
Như được sử dụng dưới đây, "Khiếu nại được cấp phép" có nghĩa là những tuyên bố về bằng sáng chế hoặc đơn xin cấp bằng sáng chế trên
toàn thế giới, không bao gồm bằng sáng chế thiết kế và đăng ký thiết kế, được sở hữu hoặc kiểm soát hoặc có thể được cấp phép lại miễn
phí và tuân thủ các yêu cầu của Thỏa thuận này, bởi Tác giả hoặc các chi nhánh của Tác giả bây giờ hoặc bất kỳ thời điểm nào trong
tương lai và điều này nhất thiết sẽ bị vi phạm khi triển khai Đặc tả giao thức hàng đợi tin nhắn nâng cao. Một khiếu nại nhất thiết
chỉ bị vi phạm dưới đây khi không thể tránh vi phạm vì không có giải pháp thay thế hợp lý không vi phạm nào để triển khai các phần bắt
buộc của Đặc tả giao thức hàng đợi tin nhắn nâng cao. Bất kể những điều đã nói ở trên, Khiếu nại được cấp phép sẽ không bao gồm bất kỳ
khiếu nại nào ngoài những khiếu nại đã nêu ở trên ngay cả khi có cùng bằng sáng chế với Khiếu nại được cấp phép; hoặc chỉ đọc về mọi
triển khai của bất kỳ phần nào của Đặc tả giao thức hàng đợi tin nhắn nâng cao mà Đặc tả giao thức hàng đợi tin nhắn nâng cao không
được yêu cầu bởi Đặc tả giao thức hàng đợi tin nhắn nâng cao hoặc, nếu được cấp phép, sẽ yêu cầu người cấp phép thanh toán tiền bản
quyền cho các bên thứ ba không liên kết. Ngoài ra, Khiếu nại được cấp phép sẽ không bao gồm (i) bất kỳ công nghệ hỗ trợ nào có thể cần
thiết để tạo hoặc sử dụng bất kỳ Sản phẩm được cấp phép nào nhưng bản thân chúng không được quy định rõ ràng trong Đặc tả giao thức
hàng đợi tin nhắn nâng cao (ví dụ: công nghệ sản xuất chất bán dẫn, công nghệ trình biên dịch, hướng đối tượng). công nghệ, công nghệ
mạng, công nghệ hệ điều hành và những thứ tương tự); hoặc (ii) việc triển khai các tiêu chuẩn đã xuất bản khác được phát triển ở nơi
khác và chỉ được đề cập trong phần Đặc tả giao thức hàng đợi tin nhắn nâng cao hoặc (iii) bất kỳ Sản phẩm được cấp phép nào và mọi sự
kết hợp giữa chúng với mục đích hoặc chức năng không bắt buộc phải tuân thủ với Đặc tả giao thức hàng đợi tin nhắn nâng cao. Vì mục
đích của định nghĩa này, Đặc tả Giao thức Hàng đợi Nhắn tin Nâng cao sẽ được coi là bao gồm cả các yêu cầu về kiến trúc và kết nối cần
thiết cho khả năng tương tác và cũng có thể bao gồm các tạo phẩm mã nguồn hỗ trợ trong đó các yêu cầu về kiến trúc, kết nối và các tạo
tác mã nguồn đó được xác định rõ ràng là được yêu cầu hoặc tài liệu để đạt được sự tuân thủ với Đặc tả giao thức hàng đợi tin nhắn
nâng cao.
Như được sử dụng dưới đây, "Sản phẩm được cấp phép" chỉ có nghĩa là những phần cụ thể của sản phẩm (phần cứng, phần mềm hoặc sự kết
hợp của chúng) triển khai và tuân thủ tất cả các phần có liên quan của Đặc tả giao thức hàng đợi nhắn tin nâng cao.
Các tuyên bố miễn trừ trách nhiệm sau đây mà bạn cũng thừa nhận đối với bất kỳ việc sử dụng nào mà bạn có thể thực hiện đối với Đặc tả
Giao thức Hàng đợi Nhắn tin Nâng cao: THÔNG SỐ KỸ THUẬT HÀNG HẢI
TIN NHẮN NÂNG CAO ĐƯỢC CUNG CẤP "NGUYÊN TRẠNG"
VÀ CÁC TÁC GIẢ KHÔNG ĐẠI DIỆN HAY ĐẢM BẢO, RÕ RÀNG HAY NGỤ Ý, BAO GỒM NHƯNG KHÔNG GIỚI HẠN ĐẢM BẢO VỀ KHẢ NĂNG CÓ THỂ BÁN, SỰ PHÙ
HỢP CHO MỘT MỤC ĐÍCH CỤ THỂ, KHÔNG VI PHẠM HOẶC TIÊU ĐỀ; RẰNG NỘI DUNG CỦA THÔNG SỐ KỸ THUẬT HÀNG HẢI TIN NHẮN NÂNG CAO LÀ
Đặc tả giao thức xếp hàng tin nhắn nâng cao v0-9-1 Trang 2 trên 39
PHÙ HỢP VỚI MỌI MỤC ĐÍCH; CŨNG KHÔNG LÀ VIỆC THỰC HIỆN NÂNG CAO
THÔNG SỐ KỸ THUẬT GIAO THỨC HÀNG HÀNG SẼ KHÔNG VI PHẠM BẤT KỲ BÊN THỨ BA nào
BẰNG SÁNG CHẾ, BẢN QUYỀN, THƯƠNG HIỆU HOẶC CÁC QUYỀN KHÁC.
TÁC GIẢ SẼ KHÔNG CHỊU TRÁCH NHIỆM VỀ BẤT KỲ SỰ TRỰC TIẾP, GIÁN TIẾP, ĐẶC BIỆT, NGẪU NHIÊN NÀO
HOẶC CÁC THIỆT HẠI HẬU QUẢ PHÁT SINH TỪ HOẶC LIÊN QUAN ĐẾN BẤT KỲ VIỆC SỬ DỤNG NÀO,
TRIỂN KHAI HOẶC PHÂN PHỐI GIAO THỨC HÀNG TIN NHẮN NÂNG CAO
SỰ CHỈ RÕ.
Tên và nhãn hiệu của Tác giả KHÔNG được sử dụng dưới bất kỳ hình thức nào, bao gồm cả quảng cáo hoặc
công khai liên quan đến Đặc tả Giao thức Hàng đợi Tin nhắn Nâng cao hoặc nội dung của nó mà không có
cụ thể, có sự cho phép trước bằng văn bản. Tiêu đề về bản quyền trong Giao thức xếp hàng tin nhắn nâng cao
Thông số kỹ thuật sẽ luôn thuộc về Tác giả.
Không có quyền nào khác được cấp theo ngụ ý, phản đối hoặc bằng cách khác.
Khi chấm dứt giấy phép hoặc các quyền của bạn theo Thỏa thuận này, bạn sẽ hủy tất cả các bản sao của
Đặc tả giao thức hàng đợi tin nhắn nâng cao do bạn sở hữu hoặc kiểm soát.
Nhãn hiệu
"JPMorgan", "JPMorgan Chase", "Chase", logo JPMorgan Chase và Biểu tượng hình bát giác là
nhãn hiệu của JPMorgan Chase & Co.
IMATIX và logo iMatix là thương hiệu của iMatix Corporation sprl.
IONA, IONA Technologies và logo IONA là các nhãn hiệu của IONA Technologies PLC và/hoặc các logo của nó
các công ty con.
LINUX là thương hiệu của Linus Torvalds. RED HAT và JBOSS là thương hiệu đã đăng ký của Red Hat,
Inc. ở Mỹ và các nước khác.
Java, tất cả các nhãn hiệu dựa trên Java và OpenOffice.org là các nhãn hiệu của Sun Microsystems, Inc.
Hoa Kỳ, các nước khác, hoặc cả hai.
Tên công ty, sản phẩm hoặc dịch vụ khác có thể là thương hiệu hoặc nhãn hiệu dịch vụ của người khác.
Mục lục
1. Khái quát chung................................................ ................................................................. ................................................................. ............6
1.1 Mục tiêu của tài liệu này................................................................. ................................................................. .................................6
1.2 Tóm tắt................................................................................. ................................................................. ................................................................. .............6
1.2.1 Tại sao lại là AMQP?........... ................................................................. ................................................................. .............6 1.2.2 Phạm vi của
AMQP....................... ................................................................. ................................................................. ..6 1.2.3 Mô hình xếp hàng tin nhắn nâng
cao (mô hình AMQ)...................................... ......................6 1.2.4 Giao thức xếp hàng tin nhắn nâng cao (AMQP )................................................ ......................7
1.2.5 Quy mô triển khai............ ................................................................. ................................................................. ............8 1.2.6 Phạm vi chức
năng........... ................................................................. ................................................................. ............8 1.3 Bố cục của tài liệu
này................................................. ................................................................. ......................................8 1.4 Các quy
ước........... ................................................................. ................................................................. ...................................9 1.4.1 Hướng dẫn cho người
thực hiện.. ................................................................. ................................................................. ............9 1.4.2 Đánh số phiên
bản........... ................................................................. ................................................................. ....9 1.4.3 Thuật ngữ kỹ
thuật....................................... ................................................................. ...................................9
2 Kiến trúc chung................................................................................. ................................................................. .................................................11
2.1 Kiến trúc mô hình AMQ................................................................. ................................................................. ....................11 2.1.1 Các thực thể
chính............ ................................................................. ................................................................. ......................11 2.1.2 Luồng thông
báo........... ................................................................. ................................................................. ......................13 2.1.3 Trao
đổi........... ................................................................. ................................................................. ......................15 2.1.4 Hàng đợi tin
nhắn........... ................................................................. ................................................................. ......15 2.1.5 Ràng
buộc................................................. ................................................................. ................................................................. ....16 2.2 Kiến
trúc lệnh AMQP........... ................................................................. ...................................18 2.2.1 Lệnh giao thức (Các lớp & Phương
pháp)................................................................. ......................................18 2.2. 2 Ánh xạ AMQP tới API phần mềm trung
gian.................................. ................................................................. ......18 2.2.3 Không có xác
nhận....................... ................................................................. ...................................19 2.2.4 Lớp kết
nối................................................................................. ................................................................. ......................19 2.2.5 Lớp
kênh............ ................................................................. ................................................................. ....20 2.2.6 Lớp
Exchange........... ................................................................. ................................................................. ...20 2.2.7 Lớp hàng
đợi................................................. ................................................................. ...................................20 2.2.8 Cơ bản Lớp
học................................................. ................................................................. ......................21 2.2.9 Lớp giao
dịch....... ................................................................. ................................................................. ......................21
2.3 Kiến trúc vận tải AMQP................................................................. ................................................................. ....................22 2.3.1 Mô tả
chung....................... ................................................................. ................................................................. ............22 2.3.2 Kiểu dữ
liệu........... ................................................................. ................................................................. .............22 2.3.3 Đàm phán giao
thức........................... ................................................................. ....................................22 2.3.4 Khung phân
định ................................................................. ................................................................. ....................23 2.3.5 Chi tiết khung
hình............ ................................................................. ................................................................. ......................23 2.3.6 Xử lý
lỗi........... ................................................................. ................................................................. ......................24 2.3.7 Đóng kênh và kết
nối........... ................................................................. ....................24 2.4 Kiến trúc máy khách
AMQP........... ................................................................. ................................................................. ............25
3 Đặc điểm chức năng.................................................................................. ................................................................. ....................................26 3.1 Đặc
tả chức năng của máy chủ.. ................................................................. ................................................................. ....26 3.1.1 Thông điệp và nội
dung........... ................................................................. ................................................................. 26 3.1.2 Máy chủ
ảo................................................................. ................................................................. ...................................26 3.1.3 Trao
đổi................................................................................. ................................................................. ...................................26 3.1.4 Hàng
đợi tin nhắn.................................................................. ................................................................. ......................28 3.1.5 Các ràng
buộc............ ................................................................. ................................................................. ......................................29 3.1.6 Người
tiêu dùng...... ................................................................. ................................................................. ......................29 3.1.7 Chất lượng dịch
vụ...... ................................................................. ................................................................. ............29
3.1.8 Lời cảm ơn................................................................................. ................................................................. ....................29
3.1.9 Kiểm soát luồng............ ................................................................. ................................................................. ...................29
3.1.10 Quy ước đặt tên............ ................................................................. ................................................................. ............29 3.2
Đặc tả lệnh AMQP (Lớp & Phương thức)............ ................................................................. ......30 3.2.1 Chú thích giải
thích....................................... ................................................................. ...................................30 3.2.2 Lớp và Chi tiết phương
pháp.................................................................. ................................................................. ......................30
4 Thông số kỹ thuật................................................................................. ................................................................. ......................................31
4.1 Số cổng được chỉ định của IANA. ................................................................. ................................................................. ......................31
4.2 Định dạng cấp dây AMQP........... ................................................................. ................................................................. ......31 4.2.1 Ngữ pháp
giao thức hình thức....................... ................................................................. ....................31 4.2.2 Tiêu đề giao
thức............ ................................................................. ................................................................. ......................33 4.2.3 Định
dạng khung chung........... ................................................................. ................................................................. ......33 4.2.4 Tải trọng
phương thức....................................... ................................................................. ...................................34 4.2.5 Trường dữ liệu
AMQP.................................................................. ................................................................. ......................34 4.2.6 Đóng khung nội
dung.......... ................................................................. ................................................................. ......................36 4.2.7 Khung
hình nhịp tim........... ................................................................. ................................................................. ...................37 4.3 Ghép
kênh kênh................................................. ................................................................. ................................................................. ...37
4.4 Đảm bảo khả năng hiển thị.................................. ................................................................. ......................................38 Đóng kênh
4.5. ................................................................. ................................................................. ...................................38
4.6 Đồng bộ hóa nội dung................................................................. ................................................................. ......................38 4.7 Đảm bảo
đặt hàng nội dung........... ................................................................. ................................................................. ............38 4.8 Xử lý
lỗi.................................. ................................................................. ................................................................. ............38 4.8.1
Ngoại lệ................................. ................................................................. ................................................................. ...........38
4.8.2 Định dạng mã trả lời........... ................................................................. ...................................39 4.9 Hạn
chế................................................................................. ................................................................. ................................................................. ...39
4.10 Bảo mật................................................................. ................................................................. ................................................................. .......39
4.10.1 Mục tiêu và nguyên tắc....................... ................................................................. ......................................39 4.10.2 Tấn công từ chối
dịch vụ. ................................................................. ................................................................. ......................39
Bản quyền (c) 2006-2008. Đã đăng ký Bản quyền. Xem Thông báo và Giấy phép. Tổng quan
1. Khái quát chung
1.1 Mục tiêu của Tài liệu này
Tài liệu này xác định một giao thức mạng, Giao thức xếp hàng 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 tới đối tượng kỹ thuật có một số kinh nghiệm trong lĩnh vực này và chúng tôi cung cấp đầy đủ thông
số kỹ thuật cũng như nguyên tắc để một kỹ sư có kỹ năng phù hợp có thể xây dựng các giải pháp phù hợp trong bất kỳ
nền tảng phần cứng hoặc ngôn ngữ lập trình hiện đại nào.
1.2 Tóm tắt
1.2.1 Tại sao lại là AMQP?
AMQP tạo ra khả năng tương tác đầy đủ chức năng giữa các máy khách tuân thủ và máy chủ phần mềm trung gian nhắn tin
(còn được gọi là "nhà môi giới").
Mục tiêu của chúng tôi là cho phép phát triển và sử dụng công nghệ phần mềm trung gian nhắn tin được tiêu chuẩn hóa
trong toàn ngành nhằm giảm chi phí tích hợp hệ thống và doanh nghiệp, đồng thời cung cấp các dịch vụ tích hợp cấp
công nghiệp cho nhiều đối tượng. Mục tiêu của chúng tôi là thông qua khả năng của phần mềm trung gian nhắn tin AMQP
cuối cùng có thể được đưa vào chính mạng và thông qua tính sẵn có rộng rãi của phần mềm trung gian nhắn tin, các
loại ứng dụng hữu ích mới có thể được phát triển.
1.2.2 Phạm vi của AMQP Để kích
hoạt khả năng tương tác hoàn chỉnh 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ủ đều được chỉ định đầy đủ. Do đó, AMQP xác định cả giao thức mạng và 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 xếp hàng 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ữ tin nhắn trong dịch vụ môi
giới, cùng với một bộ quy tắc để kết nối các thành phần này với nhau.
Giao thức cấp dây 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à nó triển khai.
Người ta có thể ngụ ý 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 về các ngữ nghĩa này sẽ giúp hiểu được giao thức.
1.2.3 Mô hình xếp hàng tin nhắn nâng cao (mô hình AMQ)
Chúng tôi xác định ngữ nghĩa của máy chủ một cách rõ ràng, vì khả năng tương tác đòi hỏi những ngữ nghĩa này phải
giống nhau trong bất kỳ quá trình triển khai máy chủ cụ thể nào. Do đó, mô hình AMQ chỉ định một bộ mô-đun gồm các
thành phần và quy tắc tiêu chuẩn để kết nối các thành phần này. Có ba loại thành phần chính được kết nối vào chuỗi
xử lý trong máy chủ để tạo ra chức năng mong muốn:
" Trao đổi" nhận tin nhắn từ các ứng dụng của nhà xuất bản và định tuyến chúng đến "hàng đợi tin nhắn", dựa trên
tiêu chí tùy ý, thường là thuộc tính hoặc nội dung tin nhắn. " Hàng
đợi tin nhắn" lưu trữ các tin nhắn cho đến khi chúng có thể được khách hàng sử dụng xử lý một cách an toàn
ứng dụng (hoặc nhiều ứng dụng).
" Ràng buộc" xác định mối quan hệ giữa hàng đợi tin nhắn và trao đổi và cung cấp tiêu chí định tuyến tin nhắn.
Bằng cách sử dụng mô hình này, chúng ta có thể mô phỏng các khái niệm phần mềm trung gian hướng thông điệp cổ điển về hàng đợi lưu trữ
và chuyển tiếp cũng như đăng ký chủ đề một cách đơn giản. Chúng ta cũng có thể diễn đạt các khái niệm ít tầm thường 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 tổng thể, máy chủ AMQP tương tự như máy chủ email, trong đó mỗi sàn giao dịch đóng vai trò là tác nhân
chuyển thư và mỗi hàng đợi thư là một hộp thư. Các ràng buộc xác định các bảng định tuyến trong
từng đại lý chuyển nhượng. Nhà xuất bản gửi tin nhắn đến các đại lý chuyển giao cá nhân, sau đó chuyển tin nhắn
vào hộp thư. Người tiêu dùng nhận tin nhắn từ hộp thư. Ngược lại, trong nhiều hệ thống phần mềm trung gian tiền
AMQP, nhà xuất bản gửi tin nhắn trực tiếp đến từng hộp thư (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 trao đổi nằm dưới sự kiểm soát của kiến trúc sư
(chứ không phải được nhúng trong mã), thì có thể thực hiện những điều thú vị, chẳng hạn như xác định quy tắc có
nội dung "đặt một bản sao của tất cả các tin nhắn chứa một tiêu đề tương tự 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 được với các sản phẩm nhắn tin chính.
Để cung cấp mức hiệu suất tương đương với các sản phẩm nhắn tin chính. Để cho
phép ngữ nghĩa cụ thể của máy chủ được lập trình bởi ứng dụng thông qua giao thức. Linh hoạt và có
thể mở rộng nhưng lại đơn giản.
1.2.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:
+-----------------Lớp chức năng----------------+ | |
| Giao dịch cơ bản Trao đổi Hàng đợi tin nhắn | | |
+------------------------------------------------ -+
+-----------------Lớp vận chuyển-----------------+ | | | | | | | | | |
Đóng khung nội dung Trình bày dữ liệu
Lỗi xử lý Kênh Nhịp Tim
+------------------------------------------------ -+
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 vận chuyển mang các phương thức này từ ứng dụng đến máy chủ và ngược lại, đồng thời xử lý việc ghép 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.
Người ta có thể thay thế lớp vận chuyển bằng các vận chuyển tùy ý mà không thay đổi chức năng hiển thị trong
ứng dụng của giao thức. Người ta cũng có thể sử dụng cùng một lớp vận chuyển cho các giao thức cấp cao khác nhau.
Việc thiết kế 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 sự kiểm soát rõ ràng về chất lượng dịch vụ. Phải nhất
quán và rõ ràng trong cách đặt tên. Cho
phép cấu hình hoàn chỉnh hệ thống dây điện của máy chủ thông qua giao
thức. Để sử dụng ký hiệu lệnh dễ dàng ánh xạ tới API cấp ứng dụng. Nói rõ
hơn thì mỗi thao tác thực hiện chính xác một việc.
Thiết kế của lớp vận chuyển AMQP được thúc đẩy bởi các yêu cầu chính này, không theo thứ tự cụ thể:
Để gọn nhẹ, sử dụng mã hóa nhị phân để đóng gói và giải nén nhanh chóng.
Để xử lý các tin nhắn có kích thước bất kỳ 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ó hạn chế đáng kể nào được xây dựng
bên trong. Để cho phép nối ống lệnh không đồng bộ.
Dễ dàng mở rộng để đáp ứng các nhu cầu mới và thay đổi. Để
tương thích về phía trước với các phiên bản trong tương
lai. Có thể sửa chữa được, sử dụng mô hình khẳng định
mạnh. Trung lập với các ngôn ngữ lập trình. Để phù hợp
với quá trình tạo mã.
1.2.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 (36K
tin nhắn/giờ).
Ứng dụng quan trọng của nhiệm vụ phòng ban: 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 (360K/giờ).
Ứng dụng quan trọng trong khu vực: 16 máy chủ, 500-2.000 người dùng, 100-500 hàng đợi tin nhắn và chủ đề,
1000 tin nhắn mỗi giây (3,6M/giờ).
Ứng dụng quan trọng mang tính toàn cầu: 64 máy chủ, 2K-10K người dùng, 500-1000 hàng đợi tin nhắn và chủ đề,
10.000 tin nhắn mỗi giây (36M/giờ).
Dữ liệu thị trường (giao dịch): 200 máy chủ, 5K người dùng, 10K chủ đề, 100K tin nhắn mỗi giây (360M/giờ).
Cũng như âm lượng, độ trễ truyền tin nhắn có thể rất quan trọng. Ví dụ, dữ liệu thị trường trở nên vô giá
trị rất nhanh. Việc triển khai có thể tạo sự khác biệt bằng cách cung cấp 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ủ đầy đủ thông số kỹ thuật này.
1.2.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 tác giả và một trình đọc.
Phân bổ khối lượng công việc với nhiều người viết và nhiều độc
giả. Xuất bản-đăng ký với nhiều tác giả và nhiều độc giả.
Định tuyến dựa trên nội dung với nhiều người viết và nhiều người đọc.
Truyền tập tin theo hàng đợi với nhiều người viết và nhiều người
đọc. Kết nối điểm-điểm giữa hai thiết bị ngang
hàng. Phân phối dữ liệu thị trường với nhiều nguồn và nhiều độc giả.
1.3 Tổ chức của 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ế để bạn có thể đọc độc lập tùy theo mức độ
quan tâm của bạn:
1. “Tổng quan” (chương này). Đọc chương này để được giới thiệu.
2. "Kiến trúc chung", trong đó 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 thức hoạt động của AMQP.
3. "Thông số chức năng", trong đó chúng tôi xác định cách các ứng dụng hoạt động với AMQP. Chương này bao gồm phần thảo luận dễ đọc,
tiếp theo là thông số kỹ thuật chi tiết của từng lệnh giao thức, nhằm mục đích tham khảo cho người triển khai. Trước khi đọc
chương này bạn nên đọc Kiến trúc chung.
4. "Thông số kỹ thuật", trong đó chúng tôi xác định cách hoạt động của lớp vận chuyển AMQP. Chương này bao
gồm một cuộc thảo luận ngắn, theo sau là đặc tả chi tiết về cấu trúc cấp dây, nhằm mục đích tham khảo
cho những người triển khai. Bạn có thể đọc riêng chương này nếu muốn hiểu cách thức hoạt động của giao
thức cấp dây (nhưng không hiểu nó được sử dụng để làm gì).
1.4 Công ước
1.4.1 Hướng dẫn dành cho người thực hiện Chúng
tôi sử dụng các thuật ngữ PHẢI, PHẢI KHÔNG, NÊN, KHÔNG NÊN và CÓ THỂ theo định nghĩa của IETF
RFC 2119.
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ần có của một AMQP tuân thủ
máy chủ.
Chúng tôi sử dụng thuật ngữ "khách hàng" khi thảo luận về hành vi cụ thể cần có của một AMQP tuân thủ
khách hàng.
Chúng tôi sử dụng thuật ngữ "ngang hàng" có nghĩa là "máy chủ hoặc máy
khách". Tất cả các giá trị số đều là số 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. Việc triển khai AMQP NÊN sử dụng những 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ố của phương thức và trường khung được hiển thị dưới dạng tên viết thường. Việ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 sàn giao dịch khác với
“amq.direct”.
1.4.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ố sửa đổi tùy chọn. Theo quy ước, phiên bản được
thể hiện dưới dạng Major-minor[-revision] hoặc Major.minor[.revision]:
Các số chính, số phụ và số sửa đổi có thể nhận bất kỳ giá trị nào từ 0 đến 99 đối với thông số kỹ thuật chính thức.
Số chính, số phụ và số sửa đổi từ 100 trở lên được dành riêng cho việc thử nghiệm và phát triển nội bộ
mục đích.
Số phiên bản cho biết khả năng tương tác về mặt cú pháp và ngữ nghĩa. Phiên
bản 0-9-1 được biểu diễn dưới dạng chính = 0, phụ = 9, sửa đổi = 1. Phiên bản 1.1
sẽ được biểu diễn dưới dạng chính = 1, phụ = 1, sửa đổi = 0. Viết “AMQP/1.1” là
tương đương với cách viết “AMQP/1.1.0” hoặc AMQP/1-1-0.
1.4.3 Thuật ngữ kỹ thuật Những thuật ngữ
này có ý nghĩa đặc biệt trong ngữ cảnh của tài liệu này:
Kiến trúc lệnh AMQP: Lệnh giao thức cấp dây được mã hóa để thực thi 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ể và ngữ nghĩa chính phải được cung cấp khi triển
khai máy chủ tuân thủ AMQP, sao cho trạng thái máy chủ có thể được thao tác bởi máy khách để đạt được ngữ nghĩa
được xác định trong đặc tả này.
Kết nối: Kết nối mạng, ví dụ: kết nối ổ cắm TCP/IP. Kênh: Luồng liên lạc
hai chiều giữa hai đồng nghiệp AMQP. Các kênh được ghép kênh để một kết nối mạng 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. Khách hàng sản
xuất
và sử dụng tin nhắn trong khi máy chủ xếp hàng và định tuyến tin nhắn.
Máy chủ: Quá trình chấp nhận các kết nối máy khách và thực hiện việc xếp hàng tin nhắn AMQP và
các chức năng định tuyến. Còn được gọi là "nhà môi giới".
Peer: Một trong hai bên trong kết nối AMQP. Một kết nối AMQP bao gồm chính xác hai thiết bị ngang hàng (một là
máy khách, một 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 khung luôn được ghi và đọc liên tục - dưới dạng một
đơn vị - 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 vấn đề cụ thể
loại chức năng.
Phương thức: Một loại khung lệnh AMQP cụ thể chuyển hướng dẫn từ thiết bị ngang hàng này sang thiết bị ngang hàng
khác. Nội dung: Dữ liệu ứng dụng được truyền từ máy khách đến máy chủ và từ máy chủ đến máy khách. Thuật ngữ này
đồng nghĩa với "thông điệp".
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. Nội dung:
Một loại khung cụ thể chứa dữ liệu ứng dụng thô. Khung nội dung là
hoàn toàn mờ đục - máy chủ không kiểm tra hoặc sửa đổi những điều này theo bất kỳ
cách nào. Thông báo: Đồng nghĩa với “nội
dung”. Exchange: Thực thể trong máy chủ nhận tin nhắn từ các ứng dụng của nhà sản xuất và
tùy chọn định tuyến chúng đến hàng đợi tin nhắn trong máy chủ.
Loại trao đổi: Thuật toán và cách thực hiện một mô hình trao đổi cụ thể. Ngược lại với "phiên bản trao đổi", là thực thể nhận và
định tuyến các tin nhắn trong máy chủ. Hàng đợi tin nhắn: Một thực thể được đặt tên chứa các tin nhắn và chuyển tiếp
chúng đến các ứng dụng tiêu dùng. Binding: Một thực thể tạo ra mối quan hệ giữa hàng đợi tin nhắn và trao đổi. Routing key:
Một địa chỉ ảo mà một sàn giao dịch có thể sử dụng để quyết định cách định tuyến một tin nhắn cụ thể. Bền vững:
Tài nguyên máy chủ vẫn tồn tại sau khi khởi động lại máy chủ.
Tạm thời: Tài nguyên máy chủ hoặc thông báo bị xóa hoặc đặt lại sau khi máy chủ khởi động lại.
Persistent: Thông báo rằng máy chủ lưu giữ trên bộ lưu trữ đĩa đáng tin cậy và KHÔNG ĐƯỢC mất sau một
khởi động lại máy chủ.
Người tiêu dùng: Một ứng dụng khách yêu cầu tin nhắn từ hàng đợi tin nhắn. Nhà sản
xuất: Một ứng dụng khách xuất bản các thông báo tới một sàn giao dịch. Máy chủ
ảo: Một tập hợp các trao đổi, hàng đợi tin nhắn và các đối tượng liên quan. Máy chủ ảo là các miền máy chủ độc lập chia
sẻ môi trường mã hóa và xác thực chung.
Khẳng định: Một điều kiện phải đúng để quá trình xử lý tiếp tục. Ngoại lệ:
Xác nhận không thành công, được xử lý bằng cách đóng Kênh hoặc Kết nối.
Các thuật ngữ này không có ý nghĩa đặc biệt trong bối cảnh AMQP:
Chủ đề: Thường là phương tiện truyền tải thông điệp; AMQP triển khai các chủ đề bằng cách sử dụng một hoặc nhiều loại
trao đổi.
Đăng ký: Thường là yêu cầu nhận dữ liệu từ các chủ đề; AMQP triển khai đăng ký dưới dạng hàng đợi và ràng buộc tin
nhắn. Dịch vụ: Thường đồng
nghĩa với máy chủ. AMQP sử dụng "máy chủ" tuân thủ tiêu chuẩn IETF
danh pháp.
Nhà môi giới: đồng nghĩa với máy chủ. AMQP sử dụng thuật ngữ "máy khách" và "máy chủ" để phù hợp với danh pháp tiêu chuẩn IETF.
Router: Đôi khi được sử dụng để mô tả các hoạt động của một sàn giao dịch. Các sàn giao dịch cũng có thể đóng vai
trò là điểm cuối của tin nhắn và "bộ định tuyến" có ý nghĩa đặc biệt trong miền mạng nên AMQP không sử dụng nó.
Bản quyền (c) 2006-2008. Đã đăng ký Bản quyền. Xem Thông báo và Giấy phép. Kiến trúc tổng hợp
2 Kiến trúc chung
2.1 Kiến trúc mô hình AMQ

Phần này giải thích 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 việc triển khai AMQP.
2.1.1 Các thực thể chính
Sơ đồ này hiển thị mô hình AMQ tổng thể:
Máy chủ
+-----------------------------+
Máy chủ ảo |
| | +-------------------+ | | +------------- |
+ | | Trao đổi |
| |
+-------+ |
| Nhà xuất bản | ----------> | | | ứng dụng | | | +-------------+
| | | | | |
| | +-------------+ | | |
+---+---+ |
| | |
|
Tin nhắn |
| Xếp hàng |
|
+-------+ |
| Người tiêu dùng | <---------- +-------+ | | ứng dụng | | +-------+ | +-------------+ |
| | | +-------------------+ |
| |
+-------+ |
|
+-----------------------------+
Chúng ta có thể tóm tắt máy chủ phần mềm trung gian là gì: nó là một máy chủ dữ liệu chấp nhận tin nhắn và thực hiện hai
những điều chính với họ, nó định tuyến chúng đến những người tiêu dùng khác nhau tùy thuộc vào các tiêu chí tùy ý và nó đệm
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áy chủ tiền AMQP, các tác vụ này được thực hiện bởi các công cụ nguyên khối triển khai các loại định tuyến cụ thể
và đệm. Mô hình AMQ sử dụng cách tiếp cận các phần mô-đun nhỏ hơn có thể được kết hợp thành
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ò riêng biệt:
Exchange, nơi chấp nhận tin nhắn từ nhà sản xuất và định tuyến cho họ hàng đợi tin nhắn.
Hàng đợi tin nhắn, lưu trữ các tin nhắn và chuyển tiếp chúng đến các ứng dụng tiêu dùng.
Có một giao diện rõ ràng giữa trao đổi và hàng đợi tin nhắn, được gọi là "ràng buộc", mà chúng ta sẽ đề cập đến
sau đó. AMQP cung cấp ngữ nghĩa có thể lập trình theo thời gian chạy, thông qua hai khía cạnh chính:
1. Khả năng trong thời gian chạy thông qua giao thức để tạo các loại hàng đợi tin nhắn và trao đổi tùy ý (một số là
được xác định trong tiêu chuẩn, nhưng những cái khác có thể được thêm vào dưới dạng phần mở rộng máy chủ).
2. Khả năng trong thời gian chạy thông qua giao thức để kết nối các trao đổi và hàng đợi tin nhắn với nhau để tạo ra bất kỳ
hệ thống xử lý thông điệp cần thiết.
2.1.1.1 Hàng đợi tin nhắn
Hàng đợi tin nhắn lưu trữ các tin nhắn trong bộ nhớ hoặc trên đĩa và phân phối chúng theo trình tự tới một hoặc nhiều
ứng dụng tiêu dùng. 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.
Hàng đợi tin nhắn có nhiều thuộc tính khác nhau: riêng tư hoặc chia sẻ, lâu dài hoặc tạm thời, tên máy khách hoặc tên 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ể phần mềm trung gian thông
thường như:
Một hàng đợi lưu trữ và chuyển tiếp được chia sẻ, chứa các thông điệp và phân phối chúng giữa những người tiêu dùng trên cơ sở luân
phiên. Hàng đợi lưu trữ và chuyển tiếp thường bền và được chia sẻ giữa nhiều
người tiêu dùng.
Hàng đợi trả lời riêng, chứa các tin nhắn và chuyển tiếp chúng đến một người tiêu dùng. Hàng đợi trả lời thường là tạm thời, có tên
máy chủ và riêng tư đối với một người tiêu dùng.
Hàng đợi đăng ký riêng, chứa các tin nhắn được thu thập từ nhiều nguồn "đã đăng ký" khác nhau và
chuyển tiếp những thứ này đến một người tiêu dùng duy nhất.
Hàng đợi đăng ký thường là tạm thời, có tên máy chủ và riêng tư đối với một người tiêu dùng. Các danh mục này không được xác định
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 ra các thực thể mới chẳng hạn như hàng đợi đăng ký
dùng chung, bền vững là điều đơn giản.
2.1.1.2 Exchange Một Exchange chấp
nhận các tin nhắn từ ứng dụng của nhà sản xuất và định tuyến chúng đến 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à "ràng buộc". Trao đổi là công cụ kết hợp và định tuyến.
Nghĩa là, họ kiểm tra các tin nhắn và sử dụng các bảng ràng buộc của mình, quyết định cách chuyển tiếp các tin nhắn này đến hàng đợi
tin nhắn hoặc các trao đổi khác. Trao đổi không bao giờ lưu trữ tin nhắn.
Thuật ngữ "trao đổi" được sử dụng để chỉ cả một loại thuật toán và các trường hợp của thuật toán đó.
Nói đúng hơn, chúng ta nói về "loại trao đổi" và "phiên bản trao đổi".
AMQP xác định một số loại trao đổi 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 gửi tin nhắn chung. Máy chủ
AMQP sẽ cung cấp các phiên bả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 thêm các phiên bản trao đổi của riêng chúng. Các loại trao đổi được đặt tên để các ứng dụng tạo
trao đổi của riêng chúng có thể cho máy chủ biết nên sử dụng loại trao đổi nào.
Các phiên bản Exchange cũng được đặt tên để các ứng dụng có thể chỉ định cách liên kết hàng đợi và xuất bản
tin nhắn.
Trao đổi có thể làm được nhiều việc hơn là định tuyến tin nhắn. Họ có thể hoạt động như những tác nhân thông minh hoạt động từ bên
trong máy chủ, chấp nhận tin nhắn và tạo ra tin nhắn khi cần thiết. Khái niệm trao đổi nhằm xác định một mô hình để bổ sung khả năng
mở rộng cho máy chủ AMQP theo cách tiêu chuẩn hợp lý, vì khả năng mở rộng có một số tác động đến khả năng tương tác.
2.1.1.3 Khóa định tuyến
Trong trường hợp chung, sàn giao dịch sẽ kiểm tra các thuộc tính của tin nhắn, các trường tiêu đề và nội dung nội dung của nó, đồng
thời sử dụng dữ liệu này và có thể cả dữ liệu từ các nguồn khác để 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, sàn giao dịch sẽ kiểm tra một trường khóa duy nhất mà chúng tôi gọi là "khóa định tuyến".
Khóa định tuyến là một địa chỉ ảo mà sàn giao dịch 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, khóa định tuyến thường là tên của hàng đợi tin nhắn.
Đối với định tuyến pub-sub chủ đề, khóa định tuyến thường là giá trị phân cấp chủ đề.
Trong những trường hợp phức tạp hơn, khóa định tuyến có thể được kết hợp với định tuyến trên các trường tiêu đề thư và/hoặc nội dung của nó.
2.1.1.4 Tương tự với Email
Nếu chúng ta so sánh với hệ thống email, chúng ta sẽ thấy rằng các khái niệm AMQP không triệt để:
một tin nhắn AMQP tương tự như một tin nhắn email; hàng đợi tin
nhắn giống như một hộp thư; người tiêu dùng
giống như một ứng dụng thư khách tìm nạp và xóa email;
Exchange giống như một MTA (đại lý chuyển thư) kiểm tra email và quyết định, trên cơ sở định tuyến
các phím và bảng, cách gửi email đến một hoặc nhiều hộp thư;
khóa định tuyến tương ứng với địa chỉ email Đến: hoặc Cc: hoặc Bcc:, không có thông tin máy chủ
(định tuyến hoàn toàn nội bộ đối với máy chủ AMQP);
mỗi phiên bản trao đổi giống như một quy trình MTA riêng biệt, xử lý một số tên miền phụ email hoặc các
loại lưu lượng email;
một liên kết giống như một mục trong bảng định tuyến MTA.
Sức mạnh của AMQP đến từ khả năng tạo hàng đợi (hộp thư), trao đổi (quy trình MTA),
và các ràng buộc (mục định tuyến), trong thời gian chạy và xâu chuỗi chúng lại với nhau theo những cách vượt xa một cách đơn giản
ánh xạ từ địa chỉ "đến" tới tên hộp thư.
Chúng ta không nên đi quá xa sự tương tự giữa email-AMQP: có những khác biệt cơ bản. Thử thách ở
AMQP là định tuyến và lưu trữ tin nhắn trong máy chủ hoặc cách nói của SMTP (IETF RFC 821) gọi chúng
“các 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 thiết bị tự động
hệ thống.
Định tuyến trong một máy chủ và giữa các máy chủ là những vấn đề riêng biệt và có những giải pháp riêng biệt, nếu chỉ dành cho
những lý do tầm thường như duy trì hoạt động minh bạch.
Để định tuyến giữa các máy chủ AMQP thuộc sở hữu của các thực thể khác nhau, người ta sẽ thiết lập các cầu nối rõ ràng, trong đó một
Máy chủ AMQP hoạt động và máy khách của máy chủ khác nhằm mục đích chuyển tin nhắn giữa các máy chủ đó
Các thực thể riêng biệt. Cách làm việc này có xu hướng phù hợp với các loại hình kinh doanh mà AMQP dự kiến sẽ áp dụng.
được sử dụng vì những cầu nối này có thể được củng cố bởi các quy trình kinh doanh, nghĩa vụ hợp đồng và
những lo ngại về an ninh.
2.1.2 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:
+-------------+ +-------+
| Nhà xuất bản | ------------------> |Tin nhắn|
| ứng dụng | +---+---+
+-------------+ |
|
+----------+
|Trao đổi |
+----+----+
|
+-------------+-----------+
| | |
Tin nhắn Tin nhắn Tin nhắn

Xếp hàng Xếp hàng Xếp hàng
+-------------+ +-------+ +-------+ +-------+
| Người tiêu dùng | | +-------+ +-------+ +-------+
ứng dụng | <---- |Tin nhắn| +-------+ +-------+
+-------------+ +-------+ +-------+ +-------+
2.1.2.1 Vòng đời tin nhắn

Thông báo 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õ ràng.
Một “thông báo” mới được tạo bởi ứng dụng của nhà sản xuất bằng cách sử dụng API máy khách AMQP. Địa điểm của nhà sản xuất
“nội dung” trong tin nhắn và có thể đặt một số “thuộc tính” cho tin nhắn. Nhà sản xuất dán nhãn tin nhắn
với “thông tin định tuyến”, trông bề ngoài giống với một địa chỉ, nhưng hầu hết mọi sơ đồ đều có thể được
tạo. Sau đó, nhà sản xuất sẽ gửi tin nhắn đến một “trao đổi” trên máy chủ.
Khi tin nhắn đến máy chủ, sàn giao dịch (thường) sẽ định tuyến tin nhắn đến một tập hợp tin nhắn
“hàng đợi” cũng tồn tại trên máy chủ. Nếu tin nhắn không thể định tuyến được, sàn giao dịch có thể hủy nó một cách âm thầm hoặc
trả lại cho nhà sản xuất. Nhà sản xuất chọn cách xử lý các 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ý việc này theo nhiều cách khác nhau, bằng
cách sao chép tin nhắn, bằng cách sử dụng tính năng tham chiếu, v.v. Đ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ó sẽ giống hệt nhau trên mỗi hàng đợi tin nhắn.
Không có mã định danh duy nhất để phân biệt các bản sao khác nhau.
Khi một tin nhắn đến trong hàng đợi tin nhắn, hàng đợi tin nhắn sẽ cố gắng chuyển nó ngay lập tức đến ứng dụng tiêu dùng
thông qua AMQP. Nếu điều này là không thể, hàng đợi tin nhắn sẽ lưu tin nhắn (trong bộ nhớ hoặc trên đĩa theo yêu cầu của
nhà sản xuất) và đợi người tiêu dùng sẵn sàng. Nếu không có người tiêu dùng, hàng đợi tin nhắn có thể trả lại tin nhắn
cho nhà sản xuất thông qua AMQP (một lần nữa, nếu nhà sản xuất yêu cầu điều này).
Khi hàng đợi tin nhắn có thể gửi tin nhắn đến người tiêu dùng, nó sẽ xóa tin nhắn khỏi bộ đệm bên trong của nó. Điều này
có thể xảy ra ngay lập tức hoặc sau khi người tiêu dùng xác nhận rằng họ đã xử lý tin nhắn thành công. Người tiêu dùng
chọn cách thức và thời điểm tin nhắn được “xác nhận”. Người tiêu dùng cũng có thể từ chối một tin nhắn (xác nhận phủ định).
Thông điệp của nhà sản xuất và sự thừa nhận của người tiêu dùng được nhóm thành “giao dịch”. Khi một ứng dụng đóng cả hai
vai trò, điều này thường xảy ra, nó sẽ thực hiện kết hợp nhiều công việc: gửi tin nhắn và gửi xác nhận, sau đó thực hiện
hoặc khôi phục giao dịch.
Việc gửi tin nhắn từ máy chủ đến người tiêu dùng không được giao dịch; chỉ cần chuyển các xác nhận cho những tin nhắn này
là đủ
2.1.2.2 Những gì nhà sản xuất nhìn thấy
Tương tự với hệ thống email, chúng ta có thể thấy rằng nhà sản xuất không gửi tin nhắn trực tiếp đến hàng đợi tin nhắn.
Cho phép điều này sẽ phá vỡ tính trừu tượng trong mô hình AMQ. Nó giống như việc cho phép email bỏ qua bảng định tuyến
của MTA và đến thẳng hộp thư. Điều này sẽ làm cho không thể chèn tính năng lọc và xử lý trung gian, chẳng hạn như phát
hiện thư rác.
Mô hình AMQ sử dụng nguyên tắc tương tự như hệ thống email: tất cả thư được gửi đến một điểm duy nhất, trao đổi hoặc MTA,
kiểm tra thư dựa trên các quy tắc và thông tin được ẩn khỏi người gửi và định tuyến chúng đến các điểm gửi cũng bị ẩn
khỏi người gửi.
2.1.2.3 Người tiêu dùng nhìn thấy gì
Sự tương tự của chúng tôi với email bắt đầu bị phá vỡ khi chúng tôi nhìn vào người tiêu dùng. Ứng dụng email khách rất thụ động - chúng có
thể đọc hộp thư của mình nhưng không có bất kỳ ảnh hưởng nào đến cách các hộp thư này được lấp đầy. Người tiêu dùng AMQP cũng có thể thụ
động, giống như ứng dụng email. Nghĩa là, chúng ta có thể viết một ứng dụng mong muốn một hàng đợi tin nhắn cụ thể sẵn sàng và bị ràng buộc,
đồng thời sẽ chỉ xử lý các tin nhắn khỏi hàng đợi tin nhắn đó.
Tuy nhiên, chúng tôi cũng cho phép các ứng dụng khách AMQP:
tạo hoặc hủy hàng đợi tin nhắn; xác
định cách các hàng đợi tin nhắn này được lấp đầy bằng cách tạo các ràng buộc;
chọn các trao đổi khác nhau có thể thay đổi hoàn toàn ngữ nghĩa định tuyến.
Điều này giống như có một hệ thống email mà người ta có thể, thông qua giao
thức: tạo một hộp thư mới;
báo cho MTA biết rằng tất cả thư có trường tiêu đề cụ thể sẽ được sao chép vào hộp thư này; thay đổi hoàn
toàn cách hệ thống thư diễn giải các địa chỉ và các tiêu đề thư khác.
Chúng tôi thấy rằng AMQP giống 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. Đây là một phần mục
tiêu của chúng tôi, giúp lập trình hoạt động của máy chủ thông qua giao thức.
2.1.2.4 Chế độ tự độ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 này. Giống như nhiếp ảnh gia nghiệp dư, phần lớn người dùng AMQP đều cần
chế độ "ngắ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 trao đổi mặc định cho các nhà sản xuất tin nhắn;
một liên kết mặc định cho hàng đợi tin nhắn chọn tin nhắn dựa trên sự trùng khớp giữa khóa định tuyến và
tên hàng đợi tin nhắn.
Trên thực tế, ràng buộc mặc định cho phép nhà sản xuất gửi tin nhắn trực tiếp đến hàng đợi tin nhắn, được cấp quyền phù hợp - nó mô
phỏng sơ đồ địa chỉ “gửi đến đích” đơn giản nhất mà mọi người mong đợi ở phần mềm trung gian truyền thống.
Ràng buộc mặc định không ngăn việc sử dụng hàng đợi tin nhắn theo những cách phức tạp hơn. Tuy nhiên, nó cho phép một người sử dụng
AMQP mà không cần hiểu cách thức hoạt động của các trao đổi và ràng buộc.
2.1.3 Trao đổi
2.1.3.1 Các loại trao đổi
Mỗi loại trao đổi thực hiện một thuật toán định tuyến cụ thể. Có một số loại trao đổi tiêu chuẩn được giải thích trong chương "Thông
số chức năng", nhưng có hai loại đặc biệt quan trọng:
Kiểu trao đổi trực tiếp , định tuyến trên một khóa định tuyến. Trao đổi mặc định là trao đổi trực tiếp. kiểu trao đổi chủ
đề , định tuyến theo mẫu định tuyến.
Máy chủ sẽ tạo một tập hợp các trao đổi, bao gồm trao đổi trực tiếp và trao đổi chủ đề khi khởi động với những tên tuổi nổi tiếng
và các ứng dụng khách có thể phụ thuộc vào điều này.
2.1.3.2 Vòng đời trao đổi Mỗi máy chủ
AMQP tạo trước một số trao đổi (phiên bản). Những trao đổi này tồn tại khi máy chủ khởi động và không thể bị
hủy. Các ứng dụng AMQP cũng có thể tạo các sàn giao dịch của riêng mình. AMQP không sử dụng phương thức "tạo"
như vậy, nó sử dụng phương thức "khai báo" chắc chắn có nghĩa là "tạo nếu không có, nếu không thì tiếp tục".
Điều hợp lý là các ứng dụng sẽ tạo ra các sàn giao dịch để sử dụng riêng và hủy chúng khi công việc của chúng
hoàn tất. AMQP cung cấp một phương pháp để hủy bỏ các trao đổi nhưng nhìn chung các ứng dụng không làm được
điều này. Trong các ví dụ của chương này, chúng tôi sẽ giả định rằng tất cả các trao đổi đều được tạo bởi máy
chủ khi khởi động. Chúng tôi sẽ không hiển thị ứng dụng tuyên bố trao đổi của nó.
2.1.4 Hàng đợi tin nhắn
2.1.4.1 Thuộc tính hàng đợi tin nhắn
Khi một ứng dụng khách 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:
tên - nếu không được chỉ định, máy chủ sẽ chọn một tên và cung cấp tên này cho máy khách. Nói chung, khi các ứng dụng chia sẻ
hàng đợi tin nhắn, chúng sẽ đồng ý trước về tên hàng đợi tin nhắn và khi một ứng dụng cần hàng đợi tin nhắn cho mục đích riêng
của mình, nó sẽ cho phép máy chủ cung cấp tên. độc quyền - nếu được đặt, hàng đợi chỉ thuộc về kết nối hiện
tại và sẽ bị xóa khi kết nối

đóng lại.
bền vững - nếu được thiết lập, 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
thông báo tạm thời nếu máy chủ khởi động lại.
2.1.4.2 Vòng đời của hàng đợi
Có hai vòng đời của hàng đợi tin nhắn chính:
Hàng đợi tin nhắn lâu dài được nhiều người tiêu dùng chia sẻ 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 cho dù có người tiêu dùng nhận chúng hay không. Hàng đợi tin nhắn tạm thời riêng tư đối với một
người tiêu dùng và được gắn với người tiêu dùng đó. Khi mà
người tiêu dùng ngắt kết nối, hàng đợi tin nhắn sẽ bị xóa.
Có một số biến thể về những điều này, chẳng hạn như hàng đợi tin nhắn được chia sẻ sẽ bị xóa khi người tiêu dùng cuối cùng
ngắt kết nối. Sơ đồ này cho thấy cách tạo và xóa hàng đợi tin nhắn tạm thời:
Tin nhắn
Xếp hàng
+-------+
Khai báo +-------+ Hàng đợi tin nhắn được tạo --------> +-------+
+-------------+ +-------+
| Người tiêu dùng | Tiêu thụ | ứng

dụng | -------->
+-------------+ \ / +\\----/*
Hủy bỏ
--------> +--\\//-+ Hàng đợi tin nhắn bị xóa

+--//\\-+
+//----\* / \
2.1.5 Ràng buộc
Ràng buộc là mối quan hệ giữa một Exchange và một hàng đợi tin nhắn để cho Exchange biết cách định tuyến
các tin nhắn. Các ràng buộc được xây dựng từ các lệnh từ ứng dụng khách (ứ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ể thể hiện một lệnh ràng buộc bằng mã giả như sau:
Queue.Bind <queue> TO <exchange> WHERE <điều kiện>
Hãy xem xét ba trường hợp sử dụng điển hình: hàng đợi chia sẻ, hàng đợi trả lời riêng tư và đăng ký pub-sub.
2.1.5.1 Xây dựng hàng đợi dùng chung
Hàng đợi được chia sẻ là "hàng đợi điểm-điểm" cổ điển của phần mềm trung gian. Trong AMQP, chúng ta có thể sử dụng trao đổi
mặc định và ràng buộc mặc định. Giả sử hàng đợi tin nhắn của chúng tôi được gọi là "app.svc01". Đây là mã giả để tạo hàng
đợi chia sẻ:
Hàng đợi.Khai báo

hàng đợi=app.svc01
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:
Cơ bản.Tiêu thụ
hàng đợi=app.svc01
Để 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:
Basic.Publish định tuyến-
key=app.svc01
2.1.5.2 Xây dựng hàng đợi trả lời

Hàng đợi trả lời thường là tạm thời, với tên do máy chủ chỉ định. Chúng cũng thường ở chế độ riêng tư, tức là được đọc
bởi một người tiêu dùng. Ngoài những đặc điểm này, hàng đợi trả lời sử dụng tiêu chí so khớp giống như hàng đợi tiêu
chuẩn, vì vậy chúng ta cũng có thể sử dụng trao đổi mặc định.
Đây là mã giả để tạo hàng đợi trả lời, trong đó S: biểu thị phản hồi của máy chủ:
hàng đợi=<trống> độc

quyền=TRUE
S:Queue.Declare-Ok queue=tmp.1
Để 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:
Cơ bản.Xuất bản
trao đổi=<trống> định tuyến-
key=tmp.1
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.5.3 Xây dựng hàng đợi đăng ký Pub-Sub

Trong phần mềm trung gian cổ điển, thuật ngữ "đăng ký" không rõ ràng và đề cập đến ít nhất hai khái niệm khác nhau: bộ
tiêu chí phù hợp với thông báo và hàng đợi tạm thời chứa các thông báo phù hợp. AMQP tách công việc thành các ràng buộc
và hàng đợi tin nhắn. Không có thực thể AMQP nào được gọi là "đăng ký".
Hãy để chúng tôi đồng ý rằng đăng ký pub-sub:
chứa các thông điệp cho một người tiêu dùng (hoặc trong một số trường hợp cho nhiều người
tiêu dùng); thu thập tin nhắn từ nhiều nguồn, thông qua một tập hợp các ràng buộc phù hợp với chủ đề, trường tin nhắn hoặc
nội dung theo những cách khác nhau.
Sự khác biệt chính giữa hàng đợi đăng ký và hàng đợi được đặt tên hoặc trả lời là tên hàng đợi đăng ký không liên quan
đến mục đích định tuyến và việc định tuyến được thực hiện trên các tiêu chí khớp trừu tượng thay vì khớp 1-1 của trường
khóa định tuyến.
Hãy lấy mô hình pub-sub phổ biến của “cây chủ đề” và triển khai mô hình này. Chúng tôi cần một loại trao đổi có khả năng
khớp trên cây chủ đề. Trong AMQP đây là loại trao đổi "chủ đề". Trao đổi chủ đề khớp các ký tự đại diện như "STOCK.USD.*"
với các giá trị chính định tuyến như "STOCK.USD.NYSE".
Chúng tôi không thể sử dụng trao đổi hoặc ràng buộc mặc định vì những điều này không thực hiện định tuyến 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. Đây là mã giả để tạo và ràng buộc hàng đợi đăng ký pub-sub:
hàng đợi=<trống> độc

quyền=TRUE
S:Queue.Declare-Ok queue=tmp.2
Queue.Bind queue=tmp.2
TO Exchange=amq.topic
WHERE Routing-
key=STOCK.USD.*
Để tiêu thụ từ hàng đợi đăng ký, người tiêu dùng thực hiện điều này:
Hàng đợi
Basic.Consume=tmp.2
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:
Cơ bản.Xuất bản
Exchange=amq.topic Routing-
key=STOCK.USD.ACME
Trao đổi chủ đề xử lý khóa định tuyến đến ("STOCK.USD.ACME") bằng bảng liên kết của nó và tìm một kết quả khớp cho 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 rất phức tạp và thách thức của chúng tôi trong việc thiết kế cấu trúc giao thức là khắc phục sự phức tạp đó.
Cách tiếp cận của chúng tôi là mô hình hóa một API truyền thống dựa trên các lớp chứa các phương thức và xác định các phương
thức để thực hiện chính xác một việc và thực hiện tốt việc đó. Điều này dẫn đến một tập lệnh lớn nhưng tương đối dễ hiểu.
Các lệnh AMQP được nhóm thành các lớp. Mỗi lớp bao gồm một miền chức năng cụ thể. Một số lớp là tùy chọn - mỗi lớp ngang hàng
triển khai các lớp mà nó cần hỗ trợ.
Có hai cuộc đối thoại phương pháp riêng biệt:
Phản hồi yêu cầu đồng bộ, trong đó một thiết bị gửi yêu cầu và thiết bị kia gửi phản hồi.
Các phương thức yêu cầu và phản hồi đồng bộ được sử dụng cho chức năng không quan trọng về hiệu suất. Thông báo không
đồng bộ, trong đó một thiết bị ngang hàng gửi một phương thức nhưng không nhận được phản hồi. Các phương pháp không đồng bộ được
sử dụng khi hiệu suất là rất quan trọng.
Để làm cho việc xử lý phương thức trở nên đơn giản, chúng tôi xác định các câu trả lời riêng biệt cho từng yêu cầu đồng bộ.
Nghĩa là, không có phương pháp 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 có nghĩa là một máy ngang hàng,
gửi yêu cầu đồng bộ, 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 các phản hồi đồng bộ hợp lệ.
Điều này phân biệt AMQP với các giao thức RPC truyền thống hơn.
Một phương thức được định nghĩa chính thức là một yêu cầu đồ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 định nghĩa chính thức là phía máy khách (tức là máy chủ đến máy khách) hoặc phía máy
chủ (máy khách đến máy chủ).
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ạ tới API phần mềm trung gian. Ánh xạ này có một số thông tin (không phải tất cả các phương pháp và không
phải tất cả các đối số đều có ý nghĩa đối với ứng dụng) nhưng nó cũng mang tính máy móc (với một số quy tắc, tất cả các phương
pháp đều có thể được ánh xạ mà không cần can thiệp thủ công).
Ưu điểm của việc này là sau khi học ngữ nghĩa AMQP (các lớp được mô tả trong phần này), các nhà phát triển sẽ tìm thấy ngữ nghĩa
tương tự được cung cấp trong bất kỳ môi trường nào họ sử dụng.
Ví dụ: đây là ví dụ về phương thức Queue.Declare:

queue=my.queue auto-
delete=TRUE độc quyền=FALSE
Điều này có thể được truyền dưới dạng khung cấp dây:
+--------+----------+----------+----------+------- ----+
| Xếp hàng | Khai báo | my.queue | 1 | 0 |

+--------+----------+----------+----------+------- ----+
lớp học phương pháp tên tự động xóa độc quyền
Hoặc dưới dạng API cấp cao hơn:
queue_declare (phiên, "my.queue", TRUE, FALSE);
Logic mã giả để ánh xạ một phương thức không đồng bộ là:
gửi phương thức đến máy chủ
Logic mã giả để ánh xạ một phương thức đồng bộ là:
gửi phương thức yêu cầu đến máy chủ lặp lại chờ
phản hồi
từ máy chủ nếu phản hồi là phương thức không đồng
bộ
phương pháp xử lý (thường là nội dung được gửi hoặc trả lại)
khác
khẳng định rằng phương thức đó là phản hồi hợp lệ cho việc lặp lại yêu cầu thoát
kết thúc nếu
kết thúc lặp lại
Điều đáng nhận xét là đối với hầu hết các ứng dụng, phần mềm trung gian có thể bị ẩn hoàn toàn trong các lớp kỹ thuật và API thực
tế được sử dụng không quan trọng bằng việc phần mềm trung gian mạnh mẽ và có khả năng.
2.2.3 Không có xác nhận

Giao thức trò chuyện chậm. Chúng tôi sử dụng nhiều tính năng không đồng bộ trong những trường hợp mà hiệu suất là một vấn đề.
Đây thường là nơi chúng tôi gửi nội dung từ thiết bị ngang hàng này sang thiết bị ngang hàng khác. Chúng tôi gửi các phương thức
nhanh nhất có thể mà không cần chờ xác nhận. Khi cần thiết, chúng tôi triển khai cửa sổ và điều tiết ở cấp độ cao hơn, ví dụ như
ở cấp độ người tiêu dùng.
Chúng tôi có thể loại bỏ xác nhận vì chúng tôi áp dụng mô hình xác nhận cho mọi hành động. Họ thành công hoặc chúng tôi có ngoại
lệ đóng kênh hoặc kết nối.
Không có xác nhận nào trong AMQP. Thành công thì im lặng, còn thất bại thì ồn ào. Khi các ứng dụng cần theo dõi rõ ràng sự thành
công và thất bại, chúng nên sử dụng các giao dịch.
2.2.4 Lớp kết nối
AMQP là một giao thức được kết nối. Kết nối được thiết kế lâu dài và có thể mang nhiều kênh. Vòng đời kết nối là thế này:
Máy khách mở kết nối TCP/IP tới máy chủ và gửi tiêu đề giao thức. Đây là dữ liệu duy nhất khách hàng gửi không được định dạng
dưới dạng phương thức.
Máy chủ phản hồi với phiên bản giao thức của nó 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ợ
(phương thức Start). Máy khách chọn cơ chế bảo mật
(Start-Ok). Máy chủ bắt đầu quá trình xác thực, sử dụng mô hình
phản hồi thử thách SASL. Nó gửi cho khách hàng một thử thách (An toàn). Máy khách gửi phản hồi xác thực (Secure-Ok). Ví dụ: sử
dụng cơ chế "đơn giản", phản hồi bao
gồm tên đăng nhập và mật khẩu.
Máy chủ lặp lại thử thách (Secure) hoặc chuyển sang đàm phán, gửi một tập hợp các tham số như kích thước khung hình tối đa
(Tune).
Máy khách chấp nhận hoặc giảm bớt các thông số này (Tune-Ok). Máy
khách chính thức mở kết nối và chọn một máy chủ ảo (Mở). Máy chủ xác nhận rằng máy chủ ảo
là lựa chọn hợp lệ (Open-Ok). Máy khách bây giờ sử dụng kết nối như mong muốn. Một
máy ngang hàng (máy khách hoặc máy chủ) kết thúc kết nối
(Đóng). Bên kia bắt tay đầu kết nối (Close-Ok). Máy chủ và máy
khách đóng kết nối socket của chúng.
Không có hiện tượng rung tay đối với các lỗi trên các kết nối chưa mở hoàn toàn. Sau khi đàm phán tiêu đề giao
thức thành công, được xác định chi tiết sau và trước khi gửi hoặc nhận Open hoặc Open-Ok, một thiết bị ngang hàng
phát hiện lỗi PHẢI đóng ổ cắm mà không gửi thêm bất kỳ dữ liệu nào.
2.2.5 Lớp kênh

AMQP là một giao thức đa kênh. Các kênh cung cấp cách ghép kênh kết nối TCP/IP hạng nặng thành một số kết nối
hạng nhẹ. Điều này làm cho giao thức trở nên “thân thiện với tường lửa” hơn vì việc sử dụng cổng có thể dự đoán
được. Điều đó cũng có nghĩa là việc định hình lưu lượng và các tính năng QoS mạng khác có thể được sử dụng dễ
dàng.
Các kênh độc lập với nhau và có thể thực hiện đồng thời các chức năng khác nhau với các kênh khác, băng thông
khả dụng được chia sẻ giữa các hoạt động đồng thời.
Người ta mong đợi và khuyến khích rằng các ứng dụng khách đa luồng thường có thể sử dụng mô hình “kênh trên mỗi
luồng” để thuận tiện cho việc lập trình. Tuy nhiên, việc mở một số kết nối tới một hoặc nhiều máy chủ AMQP từ
một máy khách cũng hoàn toàn có thể chấp nhận được. Vòng đời của kênh là:
1. Khách hàng mở một kênh mới (Mở).
2. Máy chủ xác nhận rằng kênh mới đã sẵn sàng (Open-Ok).
3. Máy khách và máy chủ sử dụng kênh theo ý muốn.
4. Một máy ngang hàng (máy khách hoặc máy chủ) đóng kênh (Close).
5. Người kia bắt tay đóng kênh (Close-Ok).
2.2.6 Lớp Exchange Lớp Exchange cho
phép ứng dụng quản lý các trao đổi trên máy chủ. Lớp này cho phép tập lệnh ứng dụng tự nối dây (thay vì dựa vào
một số giao diện cấu hình). Lưu ý: Hầu hết các ứng dụng không cần mức độ phức tạp này và phần mềm trung gian cũ
khó có thể hỗ trợ ngữ nghĩa này.
Vòng đời trao đổi là:
1. Máy khách yêu cầu máy chủ đảm bảo trao đổi tồn tại (Khai báo). Khách hàng có thể tinh chỉnh điều này thành
"tạo sàn giao dịch nếu nó không tồn tại" hoặc "cảnh báo tôi nhưng không tạo nó nếu nó không tồn tại".
2. Khách hàng xuất bản tin nhắn lên sàn giao dịch.
3. Khách hàng có thể chọn xóa sàn giao dịch (Delete).
2.2.7 Lớp hàng đợi Lớp hàng đợi
cho phép ứng dụng quản lý hàng đợi tin nhắn trên máy chủ. Đây là bước cơ bản trong hầu hết các ứng dụng sử dụng
tin nhắn, ít nhất là để xác minh rằng hàng đợi tin nhắn dự kiến thực sự có mặt.
Vòng đời của một hàng đợi tin nhắn lâu bền khá đơn giản:
1. Máy khách xác nhận rằng hàng đợi tin nhắn tồn tại (Khai báo, với đối số "thụ động").
2. Máy chủ xác nhận rằng hàng đợi tin nhắn tồn tại (Khai báo-Ok).
3. Máy khách đọc tin nhắn ra khỏi hàng đợi tin nhắn.
Vòng đời của hàng đợi tin nhắn tạm thời thú vị hơn:
1. Client tạo hàng đợi tin nhắn (Khai báo, thường không có tên hàng đợi tin nhắn nên server sẽ gán tên). Máy chủ xác nhận (Khai
báo-Ok).
2. Máy khách bắt đầu sử dụng hàng đợi tin nhắn. Chức năng chính xác của người tiêu dùng được xác định
theo lớp Cơ bản.
3. Máy khách hủy bỏ ứng dụng tiêu dùng, một cách rõ ràng hoặc bằng cách đóng kênh và/hoặc kết nối.
4. Khi người tiêu dùng cuối cùng biến mất khỏi hàng đợi tin nhắn và sau một khoảng thời gian chờ lịch sự, máy chủ
xóa hàng đợi tin nhắn.
AMQP triển khai cơ chế phân phối đăng ký chủ đề dưới dạng hàng đợi tin nhắn. Điều này cho phép các cấu trúc thú vị trong đó đăng
ký có thể được cân bằng tải giữa một nhóm các ứng dụng thuê bao hợp tác.
Vòng đời của một gói đăng ký bao gồm một giai đoạn liên kết bổ sung:
1. Máy khách tạo hàng đợi tin nhắn (Khai báo) và máy chủ xác nhận (Khai báo-Ok).
2. Máy khách liên kết hàng đợi tin nhắn với chủ đề trao đổi (Bind) và máy chủ xác nhận (Bind-Ok).
3. Máy khách sử dụng hàng đợi tin nhắn như trong các ví dụ trước.
2.2.8 Lớp cơ bản
Lớp Cơ bản triển khai các khả năng nhắn tin được mô tả trong đặc tả này. Nó hỗ trợ các ngữ nghĩa chính sau:
Gửi tin nhắn từ máy khách đến máy chủ, diễn ra không đồng bộ (Xuất bản) Bắt đầu và dừng người
tiêu dùng (Tiêu dùng, Hủy) Gửi tin nhắn từ máy chủ đến máy khách,
diễn ra không đồng bộ (Gửi, Trả lại) Xác nhận tin nhắn (Ack, Từ chối) Nhận tin nhắn ra khỏi hàng đợi tin
nhắn một cách đồng bộ (Nhận).
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 tin nhắn và xác nhận được công bố đều được xử lý như một giao dịch độc lập.
2. Các giao dịch cục bộ của máy chủ, trong đó máy chủ sẽ đệm các thông báo và xác nhận đã xuất bản
và cam kết chúng theo yêu cầu từ khách hàng.
Lớp Giao dịch (“tx”) cung cấp cho ứng dụng quyền truy cập vào loại thứ hai, cụ thể là giao dịch máy chủ. Ngữ nghĩa của lớp này là:
1. Ứng dụng yêu cầu các giao dịch máy chủ trong mỗi kênh mà nó muốn các giao dịch này (Chọn).
2. Ứng dụng hoạt động (Xuất bản, Xác nhận).
3. Ứng dụng cam kết hoặc khôi phục công việc (Commit, Roll-back).
4. Ứng dụng này hoạt động, vô cùng.
Giao dịch bao gồm nội dung được công bố và xác nhận, không phải việc giao hàng. Do đó, việc khôi phục không yêu cầu hoặc gửi lại
bất kỳ tin nhắn nào và khách hàng có quyền xác nhận những tin nhắn này trong giao dịch tiếp theo.
2.3 Kiến trúc truyền tải 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 là một giao thức
nhị phân. Thông tin được tổ chức thành các "khung", thuộc nhiều loại khác nhau. Các khung mang các phương thức giao thức và thông
tin khác. Tất cả các khung có cùng định dạng chung: tiêu đề khung, tải trọng và kết thúc khung. Định dạng tải trọng khung phụ
thuộc vào loại khung.
Chúng tôi giả định lớp truyền tải mạng hướng luồng đáng tin cậy (TCP/IP hoặc tương đương).
Trong một kết nối ổ cắm duy nhất, có thể có nhiều luồng điều khiển độc lập, được gọi là "kênh".
Mỗi khung hình được đánh số bằng một số kênh. Bằng cách xen kẽ các khung của chúng, các kênh khác nhau sẽ chia sẻ kết nối. Đối
với bất kỳ kênh cụ thể nào, các khung chạy theo một trình tự nghiêm ngặt có thể được sử dụng để điều khiển trình phân tích cú
pháp giao thức (thường là máy trạng thái).
Chúng tôi xây dựng các khung bằng cách sử dụng một tập hợp nhỏ các loại dữ liệu như bit, số nguyên, chuỗi và bảng trường. Các
trường khung được đóng gói chặt chẽ mà không làm cho việc phân tích cú pháp bị chậm hoặc phức tạp. Việc tạo lớp khung một cách
máy móc từ các thông số kỹ thuật của giao thức là tương đối đơn giản.
Định dạng cấp dây được thiết kế để có khả năng mở rộng và đủ chung để sử dụng cho các giao thức cấp cao tùy ý (không chỉ AMQP).
Chúng tôi giả định rằng AMQP sẽ được mở rộng, cải thiện và thay đổi theo thời gian và định dạng cấp dây sẽ hỗ trợ điều này.
2.3.2 Kiểu dữ liệu Các kiểu
dữ liệu AMQP được sử dụng trong khung phương thức và là:
Số nguyên (từ 1 đến 8 octet), dùng để biểu thị kích thước, số lượng, giới hạn, v.v. Số nguyên luôn không dấu và có thể không
được căn chỉnh trong khung. Bit, được sử dụng để biểu
thị các giá trị bật/tắt. Các bit được đóng gói thành octet. Chuỗi ngắn, dùng
để chứa các thuộc tính văn bản ngắn. Các chuỗi ngắn được giới hạn ở 255 octet và có thể
được phân tích cú pháp mà không có nguy cơ
tràn bộ đệm. Chuỗi dài, dùng để chứa các khối dữ liệu nhị
phân. Bảng trường chứa các cặp tên-giá trị. Các giá trị trường được nhập dưới dạng chuỗi, số nguyên, v.v.
2.3.3 Đàm phán giao thức Máy khách và máy
chủ AMQP đàm phán giao thức. Điều này có nghĩa là khi máy khách kết nối, máy chủ sẽ đề xuất một số tùy chọn nhất định mà máy
khách có thể chấp nhận hoặc sửa đổi. Khi cả hai đồng nghiệp đồng ý về kết quả, kết nối sẽ tiếp tục. Đàm phán là một kỹ thuật
hữu ích vì nó cho phép chúng ta khẳng định các giả định và điều kiện tiên quyết.
Trong AMQP, chúng tôi đàm phán một số khía cạnh cụ thể của giao thức:
Giao thức và phiên bản thực tế. Máy chủ CÓ THỂ lưu trữ nhiều giao thức trên cùng một cổng. Đối số mã hóa và
xác thực của cả hai bên. Đây là một phần của lớp chức năng, đã được giải thích trước đây. Kích thước khung hình tối đa, số
lượng kênh và các giới
hạn hoạt động khác.
Các giới hạn đã thỏa thuận CÓ THỂ cho phép cả hai bên phân bổ trước bộ đệm khóa, tránh tình trạng bế tắc. Mọi khung hình đến
đều tuân theo các giới hạn đã thỏa thuận và do đó là "an toàn" hoặc vượt quá chúng, trong trường hợp đó, bên kia bị lỗi và PHẢI
ngắt kết nối. Điều này rất phù hợp với triết lý “nó hoạt động bình thường hoặc hoàn toàn không hoạt động” của AMQP.
Cả hai bên đều thương lượng các giới hạn ở giá trị thỏa thuận thấp nhất như sau:
Máy chủ PHẢI cho khách hàng biết những giới hạn mà nó đề xuất.
Máy khách phản hồi và CÓ THỂ giảm các giới hạn đó cho kết nối của nó.
2.3.4 Phân định các khung TCP/IP là
một giao thức luồng, tức là không có sẵn cơ chế nào để phân định các khung. Các giao thức hiện tại giải quyết vấn đề này theo
nhiều cách khác nhau:
Gửi một khung hình cho mỗi kết nối. Điều này đơn giản nhưng chậm. Thêm dấu
phân cách khung vào luồng. Điều này đơn giản nhưng phân tích chậm. Đếm kích thước của
các khung và gửi kích thước trước mỗi khung. Việc này đơn giản và nhanh chóng, và chúng tôi
sự lựa chọn.
2.3.5 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:
0 1 3 7 kích thước+7 kích thước+8
+------+----------+-------------+ +-------------+ +--- --------+

| gõ | kênh | kích cỡ | tải trọng | | kết thúc khung |
| +------+----------+-------------+ +-------------+ +--- --------+
octet ngắn dài kích thước octet bát phân
Để đọc một khung, chúng ta:
1. Đọc tiêu đề và kiểm tra loại khung và kênh.
2. Tùy thuộc vào loại khung, chúng tôi đọc tải trọng và xử lý nó.
3. Đọc octet cuối khung.
Trong các triển khai thực tế mà hiệu suất là mối quan tâm, chúng tôi sẽ sử dụng "bộ đệm đọc trước" hoặc
“thu thập các lần đọc” để tránh thực hiện ba lệnh gọi hệ thống riêng biệt để đọc một khung.
2.3.5.1 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:
0 2 4
+----------+----------+-------------- - -
| id lớp | phương thức-id | tranh luận...
+----------+----------+-------------- - -
ngắn ngắn ...
Để xử lý khung phương thức, chúng tôi:
1. Đọc tải trọng khung phương thức.
2. Giải nén nó thành một cấu trúc. Một phương thức nhất định luôn có cấu trúc giống nhau, vì vậy chúng ta có thể giải nén
phương pháp một cách nhanh chóng.
3. Kiểm tra xem phương thức này 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ệ không.
5. Thực hiện phương pháp.
Thân khung phương thức được xây dựng dưới dạng danh sách các trường dữ liệu AMQP (bit, số nguyên, chuỗi và chuỗi
những cái bàn). Mã sắp xếp thứ tự được tạo trực tiếp từ các đặc tả giao thức và có thể được
rất nhanh chóng.
2.3.5.2 Khung nội dung
Nội dung là dữ liệu ứng dụng mà chúng tôi truyền từ máy khách này đến máy khách khác thông qua máy chủ AMQP. Nội dung đại khái là
nói cách khác, một tập hợp các thuộc tính cộng với một phần dữ liệu nhị phân. Tập hợp các thuộc tính được phép được xác định bởi Basic
lớp và chúng tạo thành "khung tiêu đề nội dung". Dữ liệu có thể có kích thước bất kỳ và CÓ THỂ được chia thành
một số (hoặc nhiều) khối, mỗi khối tạo thành một "khung nội dung".
Nhìn vào các khung của một kênh cụ thể khi chúng truyền qua dây, chúng ta có thể thấy một cái gì đó như thế này:
[phương pháp]
[phương thức] [tiêu đề] [nội dung] [nội dung

[phương pháp]
...
Một số phương pháp nhất định (chẳng hạn như Basic.Publish, Basic.Deliver, v.v.) được xác định chính thức là mang nội dung.
Khi một thiết bị ngang hàng gửi một khung phương thức như vậy, nó luôn theo sau nó với một tiêu đề nội dung và không hoặc nhiều
khung nội dung.
Khung tiêu đề nội dung có định dạng này:
0 2 4 12 14
+----------+--------+-------------+-------+ ------------- - -
| id lớp | cân nặng | kích thước cơ thể | cờ tài sản | danh sách tài sản...
+----------+--------+-------------+-------+ ------------- - -
ngắn ngắn dài dài ngắn phần còn lại...
Chúng tôi đặt nội dung trong các khung riêng biệt (thay vì đưa nội dung đó vào phương thức) để AMQP có thể hỗ trợ kỹ thuật "không
sao chép" trong đó nội dung không bao giờ được sắp xếp theo thứ tự hoặc mã hóa. Chúng tôi đặt các thuộc tính nội dung vào khung
riêng của chúng để người nhận có thể loại bỏ có chọn lọc những nội dung mà họ không muốn xử lý.
2.3.5.3 Khung nhịp tim
Nhịp tim là một kỹ thuật được thiết kế để hoàn tác một trong các tính năng của TCP/IP, cụ thể là khả năng phục hồi sau khi kết
nối vật lý bị hỏng bằng cách chỉ đóng sau một thời gian chờ khá dài. Trong một số trường hợp, chúng ta cần biết rất nhanh liệu
một thiết bị ngang hàng có bị ngắt kết nối hay không phản hồi vì các lý do khác (ví dụ: nó đang bị lặp). Vì nhịp tim có thể
được thực hiện ở mức độ thấp nên chúng tôi triển khai điều này như một loại khung đặc biệt mà các đồng nghiệp trao đổi ở cấp độ
vận chuyển chứ không phải là một phương thức lớp.
2.3.6 Xử lý lỗi AMQP sử dụng các
ngoại lệ để xử lý lỗi. Bất kỳ lỗi vận hành nào (không tìm thấy hàng đợi tin nhắn, không đủ quyền truy cập, v.v.) đều dẫn đến
ngoại lệ kênh. Bất kỳ lỗi cấu trúc nào (đối số không hợp lệ, chuỗi phương thức sai, v.v.) đều dẫn đến ngoại lệ kết nối. Một ngoại
lệ sẽ đóng kênh hoặc kết nối và trả về mã trả lời và văn bản trả lời cho ứng dụng khách. Chúng tôi sử dụng mã trả lời gồm 3 chữ
số cộng với sơ đồ văn bản trả lời bằng văn bản được sử dụng trong HTTP và nhiều giao thức khác.
2.3.7 Đó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 máy khách khi nó gửi Mở và đối với máy chủ khi nó gửi Mở-Ok. Từ thời điểm này trở đi, thiết bị ngang hàng muốn đóng kênh
hoặc kết nối PHẢI thực hiện việc này bằng cách sử dụng giao thức bắt tay được mô tả ở đây.
Việc đóng kênh hoặc kết nối vì bất kỳ lý do gì - bình thường hoặc đặc biệt - phải được thực hiện cẩn thận. Việc đóng đột ngột
không phải lúc nào cũng được phát hiện nhanh chóng và sau một ngoại lệ, chúng tôi có thể mất mã trả lời lỗi.
Thiết kế đúng là bắt tay tất cả các lần đóng để chúng tôi chỉ đóng sau khi chắc chắn rằng bên kia đã biết về tình huống này.
Khi một thiết bị ngang hàng quyết định đóng một kênh hoặc kết nối, nó sẽ gửi phương thức Đóng. Thiết bị ngang hàng nhận PHẢI phản
hồi Đóng bằng Đóng-Ok và sau đó cả hai bên có thể đóng kênh hoặc kết nối của họ. Lưu ý rằng nếu các đồng nghiệp bỏ qua Đóng, bế
tắc có thể xảy ra khi cả hai đồng nghiệp gửi Đóng cùng một lúc.
Kiến trúc máy khách 2.4 AMQP
Có thể đọc và ghi các khung AMQP trực tiếp từ một ứng dụng nhưng đây sẽ là một thiết kế tồi.
Ngay cả đoạn hội thoại AMQP đơn giản nhất cũng phức tạp hơn HTTP và các nhà phát triển ứng dụng không cần phải hiểu những thứ
như định dạng khung nhị phân để gửi tin nhắn đến hàng đợi tin nhắn. Kiến trúc máy khách AMQP được đề xuất bao gồm một số lớp
trừu tượng:
1. Lớp khung. Lớp này sử dụng các phương thức giao thức AMQP, ở một số định dạng dành riêng cho ngôn ngữ (cấu trúc, lớp, v.v.)
và tuần tự hóa chúng dưới dạng khung cấp dây. Lớp khung có thể được tạo một cách cơ học từ các thông số kỹ thuật AMQP (được
xác định bằng ngôn ngữ mô hình hóa giao thức, được triển khai bằng XML và được thiết kế riêng cho AMQP).
2. Lớp quản lý kết nối. Lớp này đọc và ghi các khung AMQP và quản lý kết nối tổng thể cũng như logic phiên. Trong lớp này, chúng
ta có thể gói gọn toàn bộ logic của việc mở kết nối
và phiên, xử lý lỗi, truyền và nhận nội dung, v.v. Phần lớn của lớp này có thể
được sản xuất tự động từ các thông số kỹ thuật AMQP. Ví dụ, các thông số kỹ thuậ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 ý gửi nội dung" có thể là
được sản xuất một cách máy móc.
3. Lớp API. Lớp này hiển thị một API cụ thể để các ứng dụng hoạt động. Lớp API có thể
phản ánh một số tiêu chuẩn hiện có hoặc có thể hiển thị các phương pháp AMQP cấp cao, tạo ánh xạ như
được mô tả trước đó trong phần này. Các phương pháp AMQP được thiết kế để làm cho việc ánh xạ này trở nên đơn giản
Và hữu ích. Bản thân lớp API có thể bao gồm nhiều lớp, ví dụ: API cấp cao hơn
được xây dựng dựa trên API phương thức AMQP.
Ngoài ra, thường có một số loại lớp I/O, có thể rất đơn giản (đọc socket đồng bộ
và ghi) hoặc phức tạp (i/o đa luồng không đồng bộ hoàn toàn). Sơ đồ này thể hiện tổng thể
Kiến trúc được đề xuất:
+---------------+
| Ứng dụng |
+----------+-----------+
|
+---------------+
+---| Lớp API |----Lớp API ứng dụng khách------+

| +----------++-------------+ |
| | |
| +------------------------+ | +--------------+
| | Trình quản lý kết nối +----+ Lớp khung | |

| +----------++-------------+ | +--------------+
| | |
| +------------------------+ |
+---| Lớp I/O không đồng bộ |--------------------------+
+----------+-----------+
|
-------
- - - - Mạng - - - -
-------
Trong tài liệu này, khi chúng tôi nói về "client API", chúng tôi muốn nói đến tất cả các lớp bên dưới ứng dụng (i/o,
khung, trình quản lý kết nối và các lớp API. Chúng ta thường sẽ nói về "API khách" và "
application" thành hai thứ riêng biệt, trong đó ứng dụng sử dụng API máy khách để giao tiếp với phần mềm trung gian
máy chủ.
Bản quyền (c) 2006-2008. Đã đăng ký Bản quyền. Xem Thông báo và Giấy phép. Đặc điểm chức năng
3 Đặc điểm chức năng

3.1 Đặc tả chức năng máy chủ
3.1.1 Tin nhắn và Nội dung Tin nhắn là đơn vị xử
lý nguyên tử của hệ thống xếp hàng và định tuyến phần mềm 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, chứa một khối dữ liệu nhị phân mờ.
Một thông báo có thể tương ứng với nhiều thực thể ứng dụng khác nhau:
Thông báo mức ứng dụng Tệp cần
truyề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à được đảm bảo gửi đ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 sẽ được gửi trước các tin nhắn có mức độ ưu tiên thấp hơn
đang chờ trong cùng một hàng đợi tin nhắn. Khi các 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 PHẢI 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 PHẢI xóa hoặc sửa đổi thông tin hiện có.
3.1.2 Máy chủ ảo Máy chủ ảo là
một phân vùng dữ liệu trong máy chủ, đây là một tiện ích quản trị sẽ hữu ích cho những ai muốn cung cấp AMQP dưới dạng dịch vụ trên cơ
sở hạ tầng dùng chung.
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.
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, sơ đồ ủ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 phương thức 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 đều hoạt động với cùng một máy chủ ảo. Không có cách nào để liên lạc 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 ngắt kết nối và bắt đầu lại từ đầu.
Giao thức không cung cấp cơ chế tạo hoặc định cấu hình máy chủ ảo - việc 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 triển khai.
3.1.3 Trao đổi Trao đổi là
tác nhân định tuyến tin nhắn trong máy chủ ảo. Một phiên bản trao đổi (mà chúng tôi 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 tới các dịch vụ nội bộ. Trao đổi
đượ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à hủy các phiên bản trao đổi trong giới hạn quyền hạn của chúng.
Trao đổi có thể lâu dài, tạm thời hoặc tự động xóa. Trao đổi 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. Trao đổi tự động bị xóa kéo dài cho đến khi chúng không còn được sử dụng.
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 xác định trong phần tiếp theo. AMQP yêu cầu một số ít loại trao đổi và đề xuất 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 Exchange có thể định tuyến song song một tin nhắn đến nhiều hàng đợi tin nhắn. Điều này tạo ra nhiều phiên bản của tin
nhắn được sử dụng độc lập.
3.1.3.1 Loại trao đổi trực tiếp

Loại trao đổi trực tiếp hoạt động như sau:
1. Hàng đợi tin nhắn liên kết với Exchange bằng khóa định tuyến K.
2. Nhà xuất bản gửi tin nhắn trao đổi với khóa định tuyến R.
3. Tin nhắn được chuyển vào hàng đợi tin nhắn nếu K = R.
Máy chủ PHẢI triển khai 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 trao đổi có tên amq.direct và một trao đổi không có tên công khai đóng vai trò trao đổi mặc định cho các phương thức
Xuất bản.
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 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 liên kết 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.
3.1.3.2 Loại trao đổi Fanout Loại trao đổi fanout
hoạt động như sau:
1. Hàng đợi tin nhắn liên kết với Exchange mà không có đối số.
2. Nhà xuất bản gửi tin nhắn trao đổi.
3. Tin nhắn được chuyển vào hàng đợi tin nhắn một cách vô điều kiện.
Việc thiết kế và thực hiện trao đổi fanout rất đơn giản. Loại trao đổi này và trao đổi được khai báo trước có tên là
amq.fanout, là bắt buộc.
3.1.3.3 Loại trao đổi chủ đề

Kiểu trao đổi chủ đề hoạt động như sau:
1. Hàng đợi tin nhắn liên kết với Exchange bằng cách sử dụng mẫu định tuyến, P.
2. Nhà xuất bản gửi tin nhắn trao đổi với khóa định tuyến R.
3. Tin nhắn được chuyển vào hàng đợi tin nhắn nếu R khớp với P.
Khóa định tuyến được sử dụng để trao đổi chủ đề PHẢI bao gồm 0 hoặc nhiều từ được phân cách bằng dấu chấm. Mỗi từ có thể
chứa các chữ cái AZ và az 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 hoặc
nhiều từ. Do đó, mẫu đị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ữ lại tập hợp tất cả các khóa định tuyến đã biết và cập nhật khóa
này khi nhà xuất bản sử dụng các 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 triển khai loại 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 tên là amq.topic.
3.1.3.4 Kiểu trao đổi tiêu đề
Kiểu trao đổi tiêu đề hoạt động như sau:
1. Hàng đợi tin nhắn được liên kết với việc trao đổi với một bảng các đối số chứa các tiêu đề phù hợp với ràng buộc đó và các
giá trị tùy chọn mà chúng nên giữ. Khóa định tuyến không được sử dụng.
2. Nhà xuất bản gửi tin nhắn đến sàn giao dịch trong đó thuộc tính 'headers' chứa bảng
tên và giá trị.
3. 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 đã bị ràng buộc.
Thuật toán so khớp được điều khiển bởi một đối số liên kết đặ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ể nhận một trong hai giá trị, cho biết cách xử lý các cặp giá trị tên còn lại trong bảng trong quá
trình khớp:
'tất cả' ngụ ý rằng tất cả các cặp khác phải khớp với đặc tính tiêu đề của một thông báo để thông báo đó được định tuyến (tức là
khớp với AND)
'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ông báo nếu trường trong đối số liên kết không có giá trị và trường có
cùng tên xuất hiện 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 triển khai loại 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 tên là amq.match.
3.1.3.5 Kiểu trao đổi hệ thống Kiểu trao đổi
hệ thống hoạt động như sau:
1. Nhà xuất bản gửi tin nhắn trao đổi bằng khóa định tuyến S.
2. Trao đổi hệ thống chuyển thông tin này tới dịch vụ hệ thống S.
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 khi 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 trao đổi do triển khai xác định
Tất cả các loại trao đổi không quy chuẩn 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 bộ đệm FIFO có tên chứa tin nhắn thay mặt cho một tập hợp các ứng dụng tiêu dùng.
Các ứng dụng có thể tự do tạo, chia sẻ, sử dụng và hủy hàng đợi tin nhắn trong giới hạn quyền hạn của chúng.
Lưu ý rằng khi có nhiều trình đọc từ một hàng đợi hoặc cá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 thông báo hoặc tối ưu hóa phân phối theo cách triển khai cụ thể thì 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.
Hàng đợi tin nhắn có thể tồn tại lâu dài, 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 sẽ kéo dài cho đến khi không còn được sử
dụng.
Hàng đợi tin nhắn lưu giữ tin nhắn của chúng trong bộ nhớ, trên đĩa hoặc một số kết hợp của những thứ này. Hàng đợi tin nhắn được
đặt tên trên cơ sở từng máy chủ ảo.
Hàng đợi tin nhắn chứa 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 hàng đợi tin nhắn không bao giờ được gửi đến nhiều khách hàng trừ khi nó được gửi lại sau khi bị lỗi hoặc
bị từ chối.
Một hàng đợi tin nhắn có thể chứa nhiều 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 Cơ
bản và Tệp được gửi đến cùng một hàng đợi tin nhắn thì những nội dung này sẽ được gửi đến các ứng dụng sử dụng một
cách độc lập theo yêu cầu.
3.1.5 Ràng buộc 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 Exchange biết
những thông báo nào mà hàng đợi sẽ nhận được. Các ứng dụng tạo và hủy các liên kết khi cần thiết để đưa luồng tin
nhắn vào hàng đợi tin nhắn của chúng. Tuổi thọ của các liên kết 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 liên kết của nó cũng bị hủy. Ngữ nghĩa cụ thể của phương thức Queue.Bind
phụ thuộc vào loại trao đổi.
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 khách và thực thể kiểm soát cách một ứng dụng khách
cụ thể nhận tin nhắn từ hàng đợi tin nhắn. Khi máy khách "khởi động 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 người tiêu dùng", nó sẽ phá hủy thực thể người 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.
3.1.7 Chất lượng dịch vụ 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" để xác định có bao nhiêu tin nhắn hoặc bao nhiêu octet
dữ liệu sẽ được gửi trước khi máy khách xác nhận một tin nhắn. Mục đích là gửi trước dữ liệu tin nhắn để giảm độ trễ.
3.1.8 Lời cảm ơn Sự thừa nhận là một
tín hiệu chính thức từ ứng dụng khách tới 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ể có:
1. Tự động, trong đó máy chủ xóa nội dung khỏi hàng đợi tin nhắn ngay khi nội dung đó được gửi đến ứng dụng (thông
qua các phương thức Phân phối hoặc Nhận-Ok).
2. Rõ ràng, trong đó ứng dụng khách phải gửi phương thức Ack cho mỗi tin nhắn hoặc lô tin nhắn mà nó đã xử lý.
Bản thân các lớp máy khách có thể thực hiện các xác nhận rõ ràng theo nhiều cách khác nhau, ví dụ như ngay khi nhận
được tin nhắn hoặc khi ứng dụng cho biết 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 luồng Kiểm
soát luồng là một thủ tục khẩn cấp được sử dụng để tạm dừng luồng tin nhắn từ một thiết bị ngang hàng. Nó hoạt động
theo cách tương tự giữa máy khách và máy chủ và được triển khai bằng lệnh Channel.Flow. Kiểm soát luồng là cơ chế
duy nhất có thể ngăn chặn 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ế cửa sổ tìm nạp trước
tinh tế hơn nếu nó sử dụng xác nhận tin nhắn (thường có nghĩa là sử dụng giao dịch).
3.1.10 Quy ước đặt tên Những quy ước này chi
phối việc đặt tên của 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-" Các 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 trao đổi, dịch vụ hệ thống và hàng đợi 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 thức)
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 khả năng tương tác. Những mức tối thiểu này được xác định trong phần mô tả của từng lớp.
Việc triển khai AMQP phù hợp NÊN triển khai các giá trị hào phóng hợp lý cho các trường như vậy, mức tối thiểu chỉ nhằm
mục đích 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'; biểu thức *term hoặc *(...) có nghĩa là 'không hoặc nhiều phiên bản'.
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 đồng bộ"). Bên 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 một cách không
đồng bộ; trả lời đồng bộ ("trả lời đồng bộ cho
XYZ"); một yêu cầu hoặc trả lời không đồng bộ ("async").
3.2.2 Chi tiết về lớp và phương thức Phần này
được cung cấp bởi tài liệu được tạo amqp-xml-spec.odt.
Bản quyền (c) 2006-2008. Đã đăng ký Bản quyền. Xem Thông báo và Giấy phép. Thông số kỹ thuâ t
4 Thông số kỹ thuật
4.1 Số cổng được chỉ định của IANA
Số cổng AMQP tiêu chuẩn đã được IANA chỉ định là 5672 cho cả TCP và UDP. UDP
cổng được dành riêng để sử dụng trong việc triển khai nhiều diễn viên trong tương lai.
4.2 Định dạng cấp dây AMQP
4.2.1 Ngữ pháp giao thức hình thức

Chúng tôi cung cấp ngữ pháp hoàn chỉnh cho AMQP (cái này được cung cấp để tham khảo và bạn có thể tìm thêm
thật thú vị khi bỏ qua các phần tiếp theo trình bày chi tiết về các loại khung khác nhau và định dạng của chúng):
amqp = tiêu đề giao thức * amqp-unit
giao thức-tiêu đề bằng = phiên bản giao thức-id giao thức bằng chữ-AMQP = %d65.77.81.80; "AMQP" = %d0 ;
chữ-AMQP giao thức- Phải là 0 = %d0.9.1 ; 0-9-1
id phiên bản giao

thức
khung = khung phương thức [ nội dung ] = %d1 thuộc tính
phương thức khung phương thức-tải trọng khung kết thúc = kích thước tải trọng kênh = short-uint = long-uint
thuộc tính khung kênh kích = class-id phương thức-id * amqp-field =

thước tải %x00.01-% xFF.FF = ; Khác không
trọng phương thức- %x00.01-%xFF.FF =
tải trọng lớp-id phương BIT / OCTET / short-uint / long-uint / long-long-uint / chuỗi
thức-id amqp- ngắn / chuỗi dài / dấu thời gian /
field bảng trường = 2*OCTET = 4*OCTET =
8*OCTET
short-uint long-
uint long-long-
uint chuỗi ngắn chuỗi-char
dấu thời gian chuỗi dài = OCTET *string-char = %x01 .. ; độ dài + nội dung
trường-bảng trường- %xFF = long-uint *OCTET
giá trị-cặp = long-long-uint = long-uint ; độ dài + nội dung; POSIX 64-

*field-value-pair = tên bit
trường field-value
tên trường = chuỗi ngắn

giá trị trường = 't' boolean
/ 'b' ngắn-ngắn-int
/ 'B' ngắn-ngắn-uint
/ 'U' viết tắt
/ 'u' ngắn gọn
/ 'Tôi' lâu dài

/ 'tôi' lâu rồi
/ 'L' dài-dài-int
/ 'l' dài-uint
/ 'f' nổi
/ 'd' gấp đôi
/ 'D' giá trị thập phân
/ 's' chuỗi ngắn
/ ‘S’ chuỗi dài

/ mảng trường 'A'
/ 'T' dấu thời gian
/ bảng trường 'F'
/ 'V' ; không có lĩnh vực
boolean = THÁNG 10 ; 0 = FALSE, nếu không thì TRUE
ngắn-ngắn-int ngắn-ngắn-uint = THÁNG 10
ngắn-int = THÁNG 10
= 2*OCTET
float dài- = 4*OCTET
int dài-int = 8*OCTET

= 4*OCTET ; IEEE-754 ;
gấp đôi = 8*OCTET rfc1832 XDR đôi
thang giá trị thập = quy mô dài uint
phân = THÁNG 10 ; số chữ số thập phân
kết thúc khung mảng = long-int *field-value = %xCE ; mảng giá trị
trường
nội dung = %d2 nội dung-tiêu đề *nội dung-nội dung = khung thuộc
nội dung-tiêu đề-tiêu đề-tải tính tiêu đề-tải trọng khung-end = nội dung-lớp nội dung-trọng lượng nội
trọng dung-thân-kích thước
cờ thuộc tính danh sách thuộc tính
lớp nội dung = THÁNG 10
nội dung-trọng lượng = %x00
nội dung-body-size = thuộc tính dài-uint-cờ thuộc tính-danh

sách nội dung-body-tải = 15*BIT %b0 / 15*BIT %b1 property-flags = *amqp-field = %d3 frame-
trọng nội dung properties body-
payload frame-end
= * THÁNG 10
nhịp tim = %d8 %d0 %d0 cuối khung
Chúng tôi sử dụng cú pháp BNF tăng cường đượ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 diễn giải cơ sở của chúng
các ký tự được chỉ định là 'd' hoặc 'x'.
Một quy tắc có thể định nghĩa 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.
Có thể chỉ định một loạt các giá trị số thay thế một cách ngắn gọn bằng cách sử dụng dấu gạch ngang ("-") để biểu thị
dãy giá trị thay thế.
Các phần tử nằm trong dấu ngoặc đơn được coi là một phần tử đơn lẻ, có nội dung được sắp xếp chặt chẽ.
Các phần tử được phân tách bằng dấu gạch chéo lên ("/") là các phần tử thay thế.
Toán tử “*” đứng trước một phần tử biểu thị sự lặp lại. Biểu mẫu đầy đủ là: "<a>*<b>element",
trong đó <a> và <b> là các giá trị thập phân tùy chọn, biểu thị ít nhất <a> và nhiều nhất <b> lần xuất hiện của
yếu tố.
Quy tắc có dạng: "phần tử <n>" tương đương với phần tử <n>*<n>.
Dấu ngoặc vuông bao quanh một chuỗi phần tử tùy chọn.
4.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 chuỗi 8 octet:
+---+---+---+---+---+---+---+---+
|'A'|'M'|'Q'|'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, sau đó:
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 nhỏ của 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 một
kết nối với một chuỗi văn bản không đổi và với tường lửa đánh hơi sự bắt đầu của giao thức để quyết định
áp dụng những quy tắc gì cho nó.
Máy khách và máy chủ đồng ý về giao thức và phiên bản như sau:
Máy khách mở một kết nối ổ cắm mới tới máy chủ AMQP và gửi tiêu đề giao thức.
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, hãy ghi một giá trị hợp lệ
tiêu đề giao thức vào ổ cắm và sau đó đóng ổ cắm.
Ngược lại, nó để socket mở và thực hiện giao thức tương ứng.
Ví dụ:
Khách hàng gửi: Máy chủ trả lời:

AMQP%d0.0.9.1 Phương thức kết nối.Start
AMQP%d0.1.0.0 AMQP%d0.0.9.1<Đóng kết nối>

HTTP AMQP%d0.0.9.1<Đóng kết nối>
Hướng dẫn cho 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 mà máy khách yêu cầu, nó PHẢI ghi tiêu đề giao thức hợp lệ vào ổ cắm, sau đó xóa
socket (để đảm bảo ứng dụng khách sẽ nhận được dữ liệu) rồi đó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 thử kết nối với giao thức được hỗ trợ cao nhất của nó
phiên bản và kết nối lại với phiên bản thấp hơn nếu nó 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ả 8 octet của
tiêu đề giao thức để xác định giao thức.
4.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 loại (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 kích thước+7 kích thước+8
+------+----------+---------+ +-------------+ +------ -----+
| gõ | kênh | kích thước | | tải trọng | | kết thúc khung |

+------+----------+---------+ +-------------+ +------ -----+
octet ngắn dài octet 'kích thước' bát phân
AMQP xác định các loại khung này:
Loại = 1, "PHƯƠNG PHÁP": khung phương thức.
Loại = 2, "HEADER": khung tiêu đề nội dung.
Type = 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 có tính toàn cục đối với kết nối và 1-65535 đối với các khung có
tham khảo 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. Trong khi AMQP giả định một mức độ tin cậy
giao thức được kết nối, chúng tôi sử dụng phần cuối khung để phát hiện lỗi khung do máy khách hoặc máy chủ không chính xác gây ra
triển khai.
Hướng dẫn dành cho người thực
hiện: Octet cuối khung PHẢI luôn là giá trị thập lục phân %xCE. Nếu một thiết bị
ngang hàng nhận được một khung có kiểu không phải là một trong những kiểu được xác định này, thì nó PHẢI coi khung nà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 trên đó
Khi một thiết bị ngang hàng đọc một khung, nó PHẢI kiểm tra xem phần cuối khung có hợp lệ hay không trước khi cố gắng giải mã
khung. Nếu phần cuối khung 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 trên đó. Nó NÊN ghi lại thông tin về sự cố, vì điều này cho thấy có lỗi trong quá trình triển khai mã
khung máy chủ hoặc máy khách.
Một máy ngang hàng KHÔNG ĐƯỢC gửi các khung lớn hơn kích thước đã thỏa thuận. Một thiết bị ngang hàng nhận được khung quá khổ
PHẢI báo hiệu ngoại lệ kết nối bằng mã trả lời 501 (lỗi khung).
Số kênh PHẢI bằng 0 đối với tất cả các khung nhịp tim và đối với 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 thiết bị ngang hàng nhận được số kênh khác 0 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ệ).
4.2.4 Tải trọng phương thức Phần thân
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 nội dung phương thức đều
bắt đầu bằng số định danh cho lớp và phương thức:
0 2 4
+----------+----------+-------------- - -
| id lớp | phương thức-id | tranh luận...
+----------+----------+-------------- - -
ngắn ngắn ...
Class-id và Method-id là các hằng số được định nghĩa trong lớp và phương thức AMQP
thông số kỹ
thuật. Các đối số là một tập hợp các trường AMQP dành riêng 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. Các giá trị id lớp từ %xF0.00-
%xFF.FF (%d61440-%d65535) có thể được sử dụng trong quá trình triển khai cho các lớp mở rộng không chuẩn.
4.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 đối số phương thức và trường dữ liệu được truyền giữa các ứng
dụng trong bảng trường. Các bảng trường chứa một tập hợp lớn các trường dữ liệu gốc.
4.2.5.1 Số nguyên
AMQP định nghĩa các loại số nguyên gốc này:
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 dài không dấu (64 bit).
Các 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 hai hệ thống cấp thấp (ví dụ: hai CPU Intel) giao tiếp với nhau.
hiện: Người thực hiện KHÔNG ĐƯỢC cho rằng các số nguyên được mã hóa trong khung được căn chỉnh trên từ bộ nhớ
ranh giới.
4.2.5.2 Bit
AMQP xác định 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 tiếp giáp 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 tất cả các giá trị bit trong một khung phải liền kề nhau, nhưng điều này thường được thực hiện để giảm thiểu kích
thước khung.
4.2.5.3 Chuỗi
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 đa 255 octet dữ liệu UTF-8, nhưng không được
chứa các octet 0 nhị phân. Chuỗi dài, được lưu dưới dạng số nguyên không dấu 32 bit, theo sau là 0 hoặc nhiều
octet dữ liệu. Dài
chuỗi có thể chứa bất kỳ dữ liệu nào.
4.2.5.4 Dấu thời gian
Tem thời gian được giữ ở định dạng POSIX time_t 64 bit 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
đề xung quanh trong tương lai liên quan đến giá trị time_t 31 bit và 32 bit.
4.2.5.5 Bảng trường
Bảng trường là các 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 nhiều octet luôn được giữ theo thứ tự byte mạng.
Tên trường PHẢI bắt đầu bằng một chữ cái, '$' hoặc '#' và có thể tiếp tục bằng các 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 có đ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 biểu thị số vị trí theo sau là
một số nguyên có dấu dài. 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 máy ngang hàng đối với một bảng chứa các trường trùng lặp
không định nghĩa được.
4.2.6 Đóng 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ó chứa nội dung hay không. Các phương thức mang
nội dung thực hiện điều đó một cách vô điều kiện.
Nội dung bao gồm danh sách từ 1 khung hình trở lên như sau:
1. Chính xác 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.
Các khung nội dung trên một kênh cụ thể có tính tuần tự nghiêm ngặt. Nghĩa là, chúng có thể được trộn lẫn với các khung dành cho các kênh
khác, nhưng không được trộn lẫn hoặc chồng chéo hai khung nội dung từ cùng một kênh, cũng như không được trộn lẫn các khung nội dung cho
một nội dung với các khung phương thức trên cùng một kênh.
Lưu ý rằng mọi khung không có nội dung đều đá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 được biết rõ 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.
hiện: Một máy ngang hàng nhận được nội dung không đầy đủ hoặc bị định dạng sai PHẢI đưa ra một 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 các tiêu đề nội dung bị thiếu, ID lớp sai trong
tiêu đề nội dung, khung nội dung bị thiếu, v.v.
4.2.6.1 Tiêu đề nội dung
Tải trọng tiêu đề nội dung có định dạng sau:
0 2 4 12 14
+----------+--------+-------------+-------+ ------------- - -
| id lớp | cân nặng | kích thước cơ thể | cờ tài sản | danh sách tài sản... +----------+--------+-------------+---------- ----+------------- - -
ngắn ngắn dài dài ngắn phần còn lại...
ID lớp PHẢI khớp với id lớp của khung phương thức. Máy ngang hàng PHẢI phản hồi với id lớp 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 số không được sử dụng và phải bằng
0. Kích thước nội dung là một giá trị 64-bit xác định tổng kích thước của 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. Các cờ thuộc tính là một mảng các
bit biểu thị sự hiện diện hay vắng mặt của từng giá trị thuộc tính theo thứ tự. Các bit được sắp xếp từ cao nhất
đến thấp nhất - bit 15 biểu thị thuộc tính đầu tiên. Các cờ thuộc tính có thể chỉ rõ 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 tiếp theo. Có nhiều trường cờ thuộc tính nếu cần. Các giá trị
thuộc tính là các trường dữ liệu AMQP dành riêng cho từng 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ờ xuất hiện trong
danh sách tài sản.
Số kênh trong khung nội dung KHÔNG PHẢI bằng 0. Một thiết bị ngang hàng nhận được số kênh bằng 0 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).
4.2.6.2 Nội dung

Tải trọng của nội dung nội dung là một khối nhị phân mờ, theo sau là octet cuối khung:
+--------------+ +-----------+
| Tải trọng nhị phân mờ | | kết thúc khung |
+--------------+ +-----------+
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.
Hướng dẫn dành cho người triển
khai: Một 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 bộ 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 ghép thành một khối duy
nhất để phân phối đến một ứng dụng.
4.2.7 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ỏa thuận trong quá
trình điều chỉnh kết nối.
Khung nhịp tim PHẢI có số kênh bằng 0. Một thiết bị 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 thiết bị ngang hàng 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ỳ tín hiệu nào.
lỗi hoặc lỗi.
Máy khách sẽ bắt đầu gửi nhịp tim sau khi nhận được phương thức Connection.Tune và bắt đầu
theo dõi nhịp tim sau khi nhận Connection.Open. Máy chủ sẽ bắt đầu gửi và
theo dõi nhịp tim sau khi nhận Connection.Tune-Ok.
Đồng nghiệp nên nỗ lực hết sức để gửi nhịp tim theo những khoảng thời gian nhất định. Nhịp tim có thể được gửi tại
Bất cứ lúc nào. Bất kỳ octet nào được gửi đều có thể 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 theo nhịp tim được gửi trong thời gian dài hơn một nhịp tim. Nếu một máy ngang hàng phát hiện không có thư đến
lưu lượng truy cập (tức là các octet đã nhận) trong hai khoảng nhịp tim hoặc lâu hơn, nó sẽ đóng kết nối mà không cần
sau quá trình bắt tay Connection.Close/Close-Ok và ghi lại lỗi.
Nhịp tim sẽ tiếp tục cho đến khi ổ cắm kết nối được đóng lại, kể cả trong và sau
Bắt tay Connection.Close/Close-Ok.
Ghép kênh 4.3

AMQP cho phép các đồng nghiệp tạo ra nhiều luồng điều khiển độc lập. Mỗi kênh hoạt động như một kênh ảo
kết nối chia sẻ một ổ cắm duy nhất:
khung khung khung khung

+----------+--------------+-------------+----------+
| kênh | kênh | kênh | kênh |

+----------+--------------+-------------+----------+
| ổ cắm |
+-----------------------------------------------+
Một AMQP ngang hàng CÓ THỂ hỗ trợ nhiều kênh. Số lượng kênh tối đa được xác định tại
đàm phán kết nối và một máy ngang hàng CÓ THỂ đàm phán điều này xuống còn 1.
Mỗi máy ngang hàng NÊN cân bằng lưu lượng trên tất cả các kênh mở một cách công bằng. Sự cân bằng này có thể
được thực hiện trên cơ sở từng 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 làm chậm tiến độ của một kênh ít bận rộn hơn.
4.4 Đả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 máy khách về trạng thái máy chủ là nhất quán.
Ví dụ sau đây minh họa ý nghĩa của việc quan sát khách hàng trong bối cảnh này:
Client 1 và Client 2 được kết nối trên cùng một vhost
Client 1 khai báo hàng đợi
Client 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ề điều đó
Client 2 khai báo thụ động cùng hàng đợi
Đảm bảo khả năng hiển thị đảm bảo rằng Máy khách 2 nhìn thấy hàng đợi (trong trường hợp không xóa)
Đóng kênh 4,5
Máy chủ sẽ coi kênh đã đóng khi bất kỳ điều nào trong số này xảy ra:
1. Thiết bị ngang hàng sẽ đóng kênh hoặc kết nối chính bằng cách bắt tay Đóng/Đóng-Ok.
2. Một trong hai thiết bị ngang hàng đưa ra một ngoại lệ trên kênh hoặc kết nối chính.
3. Một trong hai thiết bị ngang hàng đóng ổ cắm kết nối chính mà không bắt tay Đóng/Đóng-Ok.
Khi máy chủ đóng một kênh, mọi tin nhắn chưa được xác nhận trên kênh đó sẽ được đánh dấu để gửi lại.
Khi máy chủ đóng một kết nối, nó sẽ xóa mọi thao tác tự động xóa do kết nối đó sở hữu.
4.6 Đồng bộ hóa nội dung

Trong một số trường hợp nhất định, phương thức phản hồi yêu cầu đồ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:
Các phương thức Basic.Consume và Basic.Cancel, bắt đầu và dừng luồng tin nhắn từ một
Hàng đợi tin nhắn.
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 tin nhắn vào một
Hàng đợi tin nhắn.
Hướng dẫn dành cho người triển khai:
Các tác động của phản hồi yêu cầu KHÔNG PHẢI hiển thị trên kênh trước phương thức phản hồi và PHẢI hiển thị sau đó.
4.7 Đảm bảo đặt hàng nội dung

Thứ tự của các phương thức truyền qua một kênh là ổn định: các phương thức được nhận theo thứ tự giống như chúng được gửi. Điều này
được đảm bảo bởi việc truyền tải TCP/IP được AMQP sử dụng. Hơn nữa, nội dung được máy chủ xử lý một cách ổn định. Cụ thể, nội dung đi
qua một đường dẫn duy nhất trong máy chủ sẽ vẫn được sắp xếp theo thứ tự. Đối với nội dung có mức độ ưu tiên nhất định đi 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ự của nội dung đi qua một đường dẫn xử lý nội dung duy nhất, trừ khi trường được gửi lại được đặt trên
các phương thức Basic.Deliver hoặc Basic.Get-Ok và theo các quy tắc quản lý các điều kiện mà trường đó có thể được thực hiện
bộ.
4.8 Xử lý lỗi
4.8.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 mà chỉ báo hiệu thất bại. AMQP định nghĩa hai cấp độ ngoại lệ1 :
1. Ngoại lệ của kênh. Chúng đóng kênh gây ra lỗi. Các trường hợp ngoại lệ của kênh thường
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. Những điều này làm đóng kết nối ổ cắm và thường là do lỗi “cứng” khiến
báo lỗi lập trình, cấu hình kém hoặc trường hợp khác cần can thiệp.
Chúng tôi ghi lại các xác nhận một cách chính thức trong định nghĩa của từng lớp và phương thức.
4.8.2 Định dạng mã trả lời Mã trả lời AMQP
tuân theo định nghĩa “Mức độ nghiêm trọng và lý thuyết của mã trả lời” từ IETF RFC 2821.
1
Mức độ nghiêm trọng của những trường hợp ngoại lệ này có thể khiến người đọc ngạc nhiên, tuy nhiên AMQP nhắm đến các hệ thống hoạt động
có thể dự đoán được hoặc hoàn toàn không hoạt động, sử dụng mẫu ASSERT phổ biến từ phương pháp hay nhất về phần mềm.
4.9 Hạn chế
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 AMQP trong tương lai 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ố lượng phương thức trên mỗi lớp giao thức: id
phương thức 16-bit.
Đặc 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 thướ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 của mình đối với các 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.
4.10 Bảo mật
4.10.1 Mục tiêu và Nguyên tắc Chúng tôi đề
phòng việc khai thác tràn bộ đệm bằng cách sử dụng bộ đệm có độ dài được chỉ định ở mọi nơi. Tất cả dữ liệu do bên ngoài cung
cấp có thể được xác minh theo độ dài tối đa cho phép bất cứ khi nào có bất kỳ dữ liệu nào được đọc. Dữ liệu không hợp lệ có thể
được xử lý một cách rõ ràng bằng cách đóng kênh hoặc kết nối.
4.10.2 Tấn công từ chối dịch vụ AMQP xử lý lỗi
bằng cách trả lại mã trả lời rồi đó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ủ phải giả định rằng
các điều kiện đặc biệt trong giai đoạn đàm phán kết nối là do nỗ lực thù địch nhằm giành 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 quá trình đàm phán kết nối là tạm dừng kết nối đó (có thể là một luồng) trong
khoảng thời gian vài giây rồi đóng kết nối mạng. Điều này bao gồm lỗi cú pháp, dữ liệu quá kích thước và các 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 trường hợp ngoại lệ như vậy và gắn cờ hoặc chặn các máy khách gây ra nhiều lỗi.

Amqp0 9 1

Uploaded by

Document Information

Original Title

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

Amqp0 9 1

Uploaded by

Copyright:

Available Formats

Machine Translated by Google

Đặc tả giao thức

Phiên bản 0-9-1, ngày 13 tháng 11 năm 2008

Tiêu chuẩn nhắn tin có mục đích chung

Người đóng góp kỹ thuật

Sanjay Aiyagari hệ thống Cisco Alexis Richardson Công nghệ thỏ

Đánh dấu Atwell JPMorgan Chase Shahrokh Sadjadi hệ thống Cisco

Jason Brome Công nghệ đặc phái viên Rafael Schloming Mũ đỏ

Alan Conway Mũ đỏ Steven Shaw JPMorgan Chase

Robert Godfrey JPMorgan Chase Martin Sustrik Tập đoàn iMatix

Robert Greig JPMorgan Chase Carl Trieloff Mũ đỏ

Pieter Hintjens Tập đoàn iMatix Kim van der Riet Mũ đỏ

John O'Hara JPMorgan Chase Steve Vinoski Công nghệ IONA

Công nghệ thỏ Matthias Radestock

Thông báo Bản quyền Bản

sở hữu hoặc kiểm soát.

TIN NHẮN NÂNG CAO ĐƯỢC CUNG CẤP "NGUYÊN TRẠNG"

IMATIX và logo iMatix là thương hiệu của iMatix Corporation sprl.

1. Khái quát chung................................................ ................................................................. ................................................................. ............6

1.1 Mục tiêu của tài liệu này................................................................. ................................................................. .................................6

1.2 Tóm tắt................................................................................. ................................................................. ................................................................. .............6

năng........... ................................................................. ................................................................. ............8 1.3 Bố cục của tài liệu

này................................................. ................................................................. ......................................8 1.4 Các quy

ước........... ................................................................. ................................................................. ...................................9 1.4.1 Hướng dẫn cho người

thực hiện.. ................................................................. ................................................................. ............9 1.4.2 Đánh số phiên

bản........... ................................................................. ................................................................. ....9 1.4.3 Thuật ngữ kỹ

thuật....................................... ................................................................. ...................................9

2 Kiến trúc chung................................................................................. ................................................................. .................................................11

chính............ ................................................................. ................................................................. ......................11 2.1.2 Luồng thông

báo........... ................................................................. ................................................................. ......................13 2.1.3 Trao

đổi........... ................................................................. ................................................................. ......................15 2.1.4 Hàng đợi tin

nhắn........... ................................................................. ................................................................. ......15 2.1.5 Ràng

buộc................................................. ................................................................. ................................................................. ....16 2.2 Kiến

gian.................................. ................................................................. ......18 2.2.3 Không có xác

nhận....................... ................................................................. ...................................19 2.2.4 Lớp kết

nối................................................................................. ................................................................. ......................19 2.2.5 Lớp

kênh............ ................................................................. ................................................................. ....20 2.2.6 Lớp

Exchange........... ................................................................. ................................................................. ...20 2.2.7 Lớp hàng

đợi................................................. ................................................................. ...................................20 2.2.8 Cơ bản Lớp

học................................................. ................................................................. ......................21 2.2.9 Lớp giao

dịch....... ................................................................. ................................................................. ......................21

2.3 Kiến trúc vận tải AMQP................................................................. ................................................................. ....................22 2.3.1 Mô tả

chung....................... ................................................................. ................................................................. ............22 2.3.2 Kiểu dữ

liệu........... ................................................................. ................................................................. .............22 2.3.3 Đàm phán giao

thức........................... ................................................................. ....................................22 2.3.4 Khung phân

định ................................................................. ................................................................. ....................23 2.3.5 Chi tiết khung

hình............ ................................................................. ................................................................. ......................23 2.3.6 Xử lý

lỗi........... ................................................................. ................................................................. ......................24 2.3.7 Đóng kênh và kết

nối........... ................................................................. ....................24 2.4 Kiến trúc máy khách

AMQP........... ................................................................. ................................................................. ............25

3 Đặc điểm chức năng.................................................................................. ................................................................. ....................................26 3.1 Đặc

dung........... ................................................................. ................................................................. 26 3.1.2 Máy chủ

ảo................................................................. ................................................................. ...................................26 3.1.3 Trao

đổi................................................................................. ................................................................. ...................................26 3.1.4 Hàng

đợi tin nhắn.................................................................. ................................................................. ......................28 3.1.5 Các ràng

buộc............ ................................................................. ................................................................. ......................................29 3.1.6 Người

tiêu dùng...... ................................................................. ................................................................. ......................29 3.1.7 Chất lượng dịch

vụ...... ................................................................. ................................................................. ............29

3.1.8 Lời cảm ơn................................................................................. ................................................................. ....................29

3.1.9 Kiểm soát luồng............ ................................................................. ................................................................. ...................29

3.1.10 Quy ước đặt tên............ ................................................................. ................................................................. ............29 3.2

thích....................................... ................................................................. ...................................30 3.2.2 Lớp và Chi tiết phương

pháp.................................................................. ................................................................. ......................30