jackvanlightly

4 ms·

1.
by jackvanlightly 11mo ago
> A 500 KB/s workload should not use Kafka This is a simplistic take. Kafka isn't just about scale, it, like other messaging systems provide queue/streaming semantics for applications. Sure you can roll your own queue on a
2.
by jackvanlightly 11mo ago
We fixed that particular issue: https://jack-vanlightly.com/blog/2023/8/17/kafka-kip-966-fix...
3.
by jackvanlightly 6y ago
Not "currently" a distributed log, but we're working on adding that (in a Rabbity way). We're not trying to compete with the likes of Pulsar or Kafka though, we're just trying to round out RabbitMQ's functional
4.
by jackvanlightly 6y ago
If consumers are keeping up, there will be no reads to the BookKeeper layer as the Pulsar broker will serve from memory. When reads need to go to BookKeeper there are caches there too, with read-aheads to populate the cache to avoid going b
5.
by jackvanlightly 6y ago
Yes it does FIFO. Just like RabbitMQ, Apache Kafka and many other distributed systems, writes go through an elected leader, who is able to ensure ordering guarantees. Specifically with Apache Pulsar, each topic has an owner broker (leader)
6.
by jackvanlightly 6y ago
One of the issues with modelling queue semantics over a database is performance. All that locking, key lookups and mutating of B trees is expensive. The latest generation of durable messaging systems that offer queue semantics do so by mode
7.
by jackvanlightly 6y ago
Rabbit dev here. We released quorum queues a few months ago. It's a Raft based replicated queue that addresses all the old problems. https://www.rabbitmq.com/blog/2020/04/20/rabbitmq-gets-an-ha...