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.
31 lines
783 B
Plaintext
31 lines
783 B
Plaintext
== Kafka: ordering is per partition ==
|
|
|
|
produced 12 records, keys D/A/F round-robin, values 1..12 in order
|
|
(keys chosen so that murmur2 spreads them: D->0, A->1, F->2. A, B and C
|
|
all hash to partition 1 with three partitions, which is worth knowing
|
|
before you decide your keys are well distributed.)
|
|
|
|
consumed in this order:
|
|
F=2@p2
|
|
F=5@p2
|
|
F=8@p2
|
|
F=11@p2
|
|
A=1@p1
|
|
A=4@p1
|
|
A=7@p1
|
|
A=10@p1
|
|
D=3@p0
|
|
D=6@p0
|
|
D=9@p0
|
|
D=12@p0
|
|
|
|
per key:
|
|
F -> partition [2] values [2, 5, 8, 11]
|
|
A -> partition [1] values [1, 4, 7, 10]
|
|
D -> partition [0] values [3, 6, 9, 12]
|
|
|
|
Order is preserved within each key because a key hashes to one partition.
|
|
Across keys it is not: the values above are not 1..12 in order, because a
|
|
consumer drains one partition's buffer before the next.
|
|
|