Ankur Mhatre
e1f8aa7402
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.
25 lines
915 B
Plaintext
25 lines
915 B
Plaintext
== Pulsar: the subscription type decides ==
|
|
|
|
12 messages, keys A/B/C, values 1..12 in order, two consumers per
|
|
subscription, receiverQueueSize 1 so the first consumer cannot take the
|
|
whole backlog.
|
|
|
|
Shared subscription, which consumers saw each key:
|
|
A -> [consumer-1, consumer-2]
|
|
B -> [consumer-1, consumer-2]
|
|
C -> [consumer-1, consumer-2]
|
|
|
|
Key_Shared subscription, which consumers saw each key:
|
|
A -> [consumer-1]
|
|
B -> [consumer-1]
|
|
C -> [consumer-1]
|
|
|
|
A Shared subscription round-robins individual messages, so messages with
|
|
the same key end up on different consumers and can be processed at the
|
|
same time: there is no per-key order left to speak of. Key_Shared hashes
|
|
the key to one consumer, which is Kafka's guarantee -- except that the
|
|
assignment belongs to the subscription and is recomputed as consumers come
|
|
and go, rather than being fixed by a partition count chosen when the topic
|
|
was created.
|
|
|