Implementing Raft in RabbitMQ
summary
Implements Raft-based replication inside RabbitMQ by adding quorum queues that persist each message to a majority (typically 2 of 3) on disk so commits are safe, trading latency for throughput. Ships as an Erlang Raft library and an alpha RabbitMQ feature merged to master Oct 29. Uses Raft-based log replication with commit-on-majority, a sliding-window batching publisher flow, heartbeat-based probabilistic failure detection (~95% threshold), millisecond-level commit latency in favorable setups, but higher memory/disk use and limited queue features.
AI-written summary · about
chapters (31)
- 0:00Introduction
- 0:28SpringOne Platform
- 0:52Pivotal
- 1:31RabbitMQ
- 2:46Message Replication
- 3:31Mirrored queues
- 4:15Chain plication
- 4:33Chain ring
- 4:56Mirror loss
- 5:32Resynchronization
- 5:52Ring Topology
- 6:07Why Resync
- 7:08Raft
- 7:24What is Raft
- 8:08Log Replication
- 8:28What Raft does
- 8:59Details of Raft
- 11:01Raft and Dropkick
- 11:16Raft on failures
- 12:35Raft library
- 13:18Raft challenges
- 15:11quorum
- 16:11business queue
- 17:45resource conservation
- 22:21challenges
- 27:58experimental fish
- 29:00problems solved
- 30:16implementation
- 31:19other uses
- 32:46partitioning
- 34:28latency
related talks
55mImplementing Raft in RabbitMQ
43mRa: a Raft implementation
51mKeynote: Quorum Queues: A Retrospective
47mDistributed Systems: When Democracy and Computer Science Come Together
41mThe Raft Consensus Algorithm
14mDistributed Consensus in 15 Minutes!
44mCluster Consensus: When Aeron Met Raft
47mUnderstanding Raft Consensus