WHwhy-el·Dec 6, 2017
Oh damn, I meant https://github.com/antirez/disque, not resque. Apologies.
In Redis PSYNC2 bug post mortemantirez
disque
C2015–2022
antirez / disque
disque
Disque is a distributed message broker
11Distinct people
12Mentions
1Explicit recommenders
8.1KGitHub stars
What to know before exploring
What it is
Disque is a distributed message broker
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I run Postgres, MonetDB, Redis, and Disque on DragonFlyBSD for various hobby projects. It's been extremely stable, easy to administer¹, and fast². Two of my favorite things: 1.…
PeCaN used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:58:02 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year12 dated mentions
Observed mentions: 2015-04-27 16:11:11 UTC to 2022-08-11 17:51:41 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
6 sourcesTry https://github.com/antirez/disque. Written by the same guy behind Redis.
> Is Redis a one-man show? (plus contributors)
Well, yes, started by one man, and he continues to lead it, with many contributions from the community.
Update: I fixed the wrong URL.
In Redis PSYNC2 bug post mortemRegardless of complexity, what I find interesting in the deployment of Redis for this use case is the following: if for the use case the consistency provided by Redis is sufficient, or even more, when a relaxed level of consistency and durability are enough for the business requirements, being Redis an in memory system and because of the specific design of the Stream inside Redis (a radix tree of blobs), you get a very high number of operations per second per process, with a memory usage which is very compact compared to the other data structures. This allows to scale certain use cases using a small percentage of the resources needed with other systems.
About the use cases where strong guarantees are needed: for instance Disque (http://github.com/antirez/disque) provides strong guarantees of delivery in face of failures, being a pure AP s
Read the rest
ystem with synchronous replication of messages. For Redis 4.2 I'm moving Disque as a Redis module. To do this, Redis modules are getting a fully featured Cluster API. This means that it will be possible, for instance, to write a Redis module that orchestrates N Redis masters, using Raft or any other consensus algorithm, as a single distributed system. This will allow to also model strong guarantees easily.
Disque: a distributed message broker
30 points · Open discussionHow does this compare to https://github.com/antirez/disque?
In Faktory, a new background job systemIndeed. In my opinion RabbitMQ is essentially useless in clustered mode.
When Rabbit recovers from a network partition and has to decide between multiple potential master versions of a queue, it picks the largest one to become the new master, and discards the others. It's rather mind-boggling that it can't merge them instead; after all, if your application is capable of handling duplicate deliveries, then merging (which would potentially result in previously ACKed messages becoming visible again) would be a perfectly acceptable solution.
The only way to make it non-lossy is to turn off HA recovery and manually handle network partitions, but it turns out that's not practically feasible, because there are no tools to work with Rabbit queues at a low level; the only way to recover is to discard one or more nodes.
We've also found Rabbit's cl
Read the rest
ustering to be very flaky in general, beside the lack of partition tolerance. We recently had a Rabbit crash where one Rabbit node (not the machine itself) went down, and things got really stuck; the only way to recover was to stop all the nodes, then start them again. After we did that, all the queues were empty. We've also had instances where suddenly bindings go missing, or the bindings are there but attempting to declare them from a client fails with an "bindings already exist" error. And many other weird errors.
The last year or so, after having to endure all of these issues, we've decided to ditch clustering altogether and run a single node. That's risky, but ironically it's a lot more stable than our previous three-node cluster.
In my opinion, Pivotal really needs to redesign RabbitMQ's clustering.
Has anyone successfully moved off Rabbit? ActiveMQ, NSQ? Disque [1] looked promising, but seems dead (last commit was 18 months ago) at this point.
[1] https://github.com/antirez/disque