The team from adeven about their Redis-based message queue:
In order to be used in production at adeven we need the following features:
- persistent (none to little data loss in case of a crash)
- reliable, atomic (each message can only be fetched once)
- monitorable (message rates, queue length and worker statuses need to be
monitored through an API)
- multi-message ack and reject (acknowledge multiple messages at once while
rejecting them individually)
We do not need any complex broker system. Simple queues with multi
publishers and multi consumers are the only thing we currently use. So if
you want to have a fancy broker or exchange system this is probably not what
you’re looking for.
By now this is already a well-known use case in the Redis community. Things can become more complicated if you need more than 1 Redis instance.
Original title and link: Building a Message Queue using Redis in Go ( ©myNoSQL)