It is only 40 pages written in plain english. (0-9-1)
I tried to read through section 2.1 only (the main architecture part)
My overall thought on section 2.1
the most important bits:
It first seemed like everything is setup, but it is much more flexible at RUNTIME
exchange is more or less controlled by the producer. (at least that seems like the best practice)
queue is more or less controlled by the consumer. (at least that seems like the best practice)
there are cases where one application creates a mq for itself and removed that queue on runtime.
Transactions, cutting off connections
there are weird details I found which is not necessarily obvious.
transactions exist.
when any error occurs, entire channel or connection is simply closed.
Paraphrased Version
Below is what I paraphrased section 2.1 into a little bit easier format. ๐ is my thoughts and I wanted to highlight them. It makes contents easier to digest.
Only the code + mermaid of this article is generated by gpt.
2.1.1 Main Entities
2.1.1.1 The Message Queue
You can build queues various properties. Detailed options are not formally defined in AMQP.
Examples of what you can build:
store-and-forward queue => durable + shared
๐ durable + shared means queue is supposed to live forever + shared between queue consumers.
fundamental types of routing needed. The CLASS, or blueprint of how the exchange should work.
Exchange instance?
default instances + the exchanges you initialize (๐ in rabbitmq management dashboard, you can see the default exchanges when you boot up.)
๐ type & instance here seems almost identical to OOP class & instance
Exchange is intended to add extensibility to AMQP for interoperability
๐ this means => Since we need to allow Java - JS - Python - multiple different environments to be communicable via AMQP (interoperability), we needed to create Exchange within AMQP protocol to handle complex situations.
2.1.1.3 The Routing Key
routing key is only used within the server.
it is used with different algorithms for different exchange types.
2.1.1.4 Analogy to Email
AMQP message โ email message
queue โ mailbox
consumer โ mail client (gmail) that reads and delets email
exchanges โ MTA (mail transfer agent)
routing key โ email To:, Cc: address
binding โ MTA routing table
the difference:
amqp is for internal services (store messages within a server)
VS email servers send emails here and there between servers.
you need to setup explicit bridges for amqp - amqp server connection
2.1.2 Message Flow
2.1.2.1 Message Life-cycle
๐ I was surprised there was transaction feature in amqp.
2.1.2.2 What The Producer Sees
messages never goes directly to queues.
messages should always go through exchange(s).
producer only sees exchange(s).
2.1.2.3 What The Consumer Sees
consumer sees a lot more than a simple email consumer.
can create or destroy mqs
can make bindings. (bindings define how the mq is filled)
select different exchanges
2.1.2.4 Automatic Mode
there is default mode since amqp don't need to be all this complicated in most cases:
default exchange exists
default routing logic: routing key is mapped to the queue of the same name.
2.1.3 Exchanges
2.1.3.1 Types of Exchange
direct: routing key exact match
topic: routing key pattern match (*, #)
๐ * is any single word and # is zero or multiple words
there are others specified in "Functional Specification" Section
2.1.3.2 Exchange Life-cycle
default exchanges are not removeable.
there is no "create exchange" but rather "declare exchange" which means something similar to what we do in dbs: "CREATE 'x' IF NOT EXISTS"
it is uncommon to remove exchanges.
2.1.4 Message Queues
2.1.4.1 Message Queue Properties
name:
bp is to use random name generated by server if a single application is using it for its own purpose
otherwise, set it up front, cohering to other applications which use the same queues.
exclusive:
current connection only
deleted when connection closes
durable:
queue remains present and active when server restarts.
might lose message when server restarts though!
2.1.4.2 Queue Life-cycles
two main types + possible other types.
Durable MQ: lives even though nobody is consuming
Temporary MQ: deleted when consumer disconnects
Shared MQ: deleted when last consumer disconnects
x MQ: might be other patterns as well.
2.1.5 Bindings
bindings = logic for exchange to mq
constructed from the client application (one owning the mq)
It is only 40 pages written in plain english. (0-9-1)
I tried to read through section 2.1 only (the main architecture part)
My overall thought on section 2.1
the most important bits:
It first seemed like everything is setup, but it is much more flexible at RUNTIME
exchange is more or less controlled by the producer. (at least that seems like the best practice)
queue is more or less controlled by the consumer. (at least that seems like the best practice)
there are cases where one application creates a mq for itself and removed that queue on runtime.
Transactions, cutting off connections
there are weird details I found which is not necessarily obvious.
transactions exist.
when any error occurs, entire channel or connection is simply closed.
Paraphrased Version
Below is what I paraphrased section 2.1 into a little bit easier format. ๐ is my thoughts and I wanted to highlight them. It makes contents easier to digest.
Only the code + mermaid of this article is generated by gpt.
2.1.1 Main Entities
2.1.1.1 The Message Queue
You can build queues various properties. Detailed options are not formally defined in AMQP.
Examples of what you can build:
store-and-forward queue => durable + shared
๐ durable + shared means queue is supposed to live forever + shared between queue consumers.
fundamental types of routing needed. The CLASS, or blueprint of how the exchange should work.
Exchange instance?
default instances + the exchanges you initialize (๐ in rabbitmq management dashboard, you can see the default exchanges when you boot up.)
๐ type & instance here seems almost identical to OOP class & instance
Exchange is intended to add extensibility to AMQP for interoperability
๐ this means => Since we need to allow Java - JS - Python - multiple different environments to be communicable via AMQP (interoperability), we needed to create Exchange within AMQP protocol to handle complex situations.
2.1.1.3 The Routing Key
routing key is only used within the server.
it is used with different algorithms for different exchange types.
2.1.1.4 Analogy to Email
AMQP message โ email message
queue โ mailbox
consumer โ mail client (gmail) that reads and delets email
exchanges โ MTA (mail transfer agent)
routing key โ email To:, Cc: address
binding โ MTA routing table
the difference:
amqp is for internal services (store messages within a server)
VS email servers send emails here and there between servers.
you need to setup explicit bridges for amqp - amqp server connection
2.1.2 Message Flow
2.1.2.1 Message Life-cycle
๐ I was surprised there was transaction feature in amqp.
2.1.2.2 What The Producer Sees
messages never goes directly to queues.
messages should always go through exchange(s).
producer only sees exchange(s).
2.1.2.3 What The Consumer Sees
consumer sees a lot more than a simple email consumer.
can create or destroy mqs
can make bindings. (bindings define how the mq is filled)
select different exchanges
2.1.2.4 Automatic Mode
there is default mode since amqp don't need to be all this complicated in most cases:
default exchange exists
default routing logic: routing key is mapped to the queue of the same name.
2.1.3 Exchanges
2.1.3.1 Types of Exchange
direct: routing key exact match
topic: routing key pattern match (*, #)
๐ * is any single word and # is zero or multiple words
there are others specified in "Functional Specification" Section
2.1.3.2 Exchange Life-cycle
default exchanges are not removeable.
there is no "create exchange" but rather "declare exchange" which means something similar to what we do in dbs: "CREATE 'x' IF NOT EXISTS"
it is uncommon to remove exchanges.
2.1.4 Message Queues
2.1.4.1 Message Queue Properties
name:
bp is to use random name generated by server if a single application is using it for its own purpose
otherwise, set it up front, cohering to other applications which use the same queues.
exclusive:
current connection only
deleted when connection closes
durable:
queue remains present and active when server restarts.
might lose message when server restarts though!
2.1.4.2 Queue Life-cycles
two main types + possible other types.
Durable MQ: lives even though nobody is consuming
Temporary MQ: deleted when consumer disconnects
Shared MQ: deleted when last consumer disconnects
x MQ: might be other patterns as well.
2.1.5 Bindings
bindings = logic for exchange to mq
constructed from the client application (one owning the mq)
2.1.5.1 Constructing a Shared Queue
wip
2.1.5.2 Constructing a Reply Queue
wip
2.1.5.3 Constructing a Pub-Sub Subscription Queue
wip
Copyrightย ยฉย 2023ย Seho Leeย All Rights Reserved.