Ankur Mhatre
e7e64a047b
Kafka, RabbitMQ and Pulsar measured side by side on ordering, replay and consumer scaling by driving the three client libraries directly, plus an operational-footprint measurement of each broker's own distribution. Nine tests, three brokers started without Docker, and every number in the documentation regenerated by scripts/run-all.sh.
19 lines
818 B
Plaintext
19 lines
818 B
Plaintext
== RabbitMQ: FIFO per queue, per consumer ==
|
|
|
|
one queue, one consumer, 12 messages
|
|
completion order : [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
|
|
|
|
one queue, two consumers, prefetch 1, consumer-1 slower than consumer-2
|
|
completion order : [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 1, 12]
|
|
out-of-order steps: 1
|
|
|
|
A queue is FIFO and a single consumer sees it that way. The moment a second
|
|
consumer is added the broker hands the next message to whichever consumer
|
|
is free, so the order in which work finishes is no longer the order in
|
|
which it was published. There is no key: RabbitMQ has no notion of a
|
|
partition to which related messages could be pinned. Ordering across
|
|
related messages means one queue and one consumer, and therefore no
|
|
horizontal scaling for that queue -- or a consistent-hash exchange, which
|
|
is a plugin.
|
|
|