LinuxCommandLibrary

beanstalkd

Queue jobs for asynchronous processing

TLDR

Start the server, listening on port 11300

$ beanstalkd
copy

Listen on a specific [p]ort and address
$ beanstalkd -l [ip_address] -p [port_number]
copy

Persist work queues by saving them to disk
$ beanstalkd -b [path/to/persistence_directory]
copy

Sync to the persistence directory every 500 milliseconds
$ beanstalkd -b [path/to/persistence_directory] -f [500]
copy

SYNOPSIS

beanstalkd [options]

PARAMETERS

-b DIR
    Specify the directory for the binlog. If specified, beanstalkd will write all jobs to disk for persistence. Jobs are loaded from this directory on startup. Without this option, data is in-memory only.

-f N
    Set the fsync period. The binlog is fsync'd every N seconds. A value of 0 disables fsync (use with caution as it increases data loss risk on crashes). Default is 0.

-l ADDR
    Specify the address to listen on. This can be an IP address (e.g., 127.0.0.1) or 0.0.0.0 to listen on all available network interfaces. Default is 0.0.0.0.

-p PORT
    Specify the TCP port to listen on. The default port is 11300.

-u USER
    Drop privileges and run as the specified USER and its primary group after binding to the port. Recommended for security.

-z BYTES
    Set the maximum job size in bytes. Jobs larger than this limit will be rejected. Default is 65535 bytes (64KB).

-V
    Print the version string of beanstalkd and exit.

-h
    Print a help message with available command-line options and exit.

DESCRIPTION

beanstalkd is a lightweight, high-performance, in-memory work queue designed for fast, low-latency, and persistent job processing. It serves as a reliable backbone for handling asynchronous tasks in various applications, particularly web services.

It allows applications to quickly offload time-consuming operations (e.g., sending emails, processing images, generating reports) to background workers, thereby keeping the main application responsive. Jobs can be prioritized, delayed, and are handled with a robust lifecycle (put, reserve, delete, release, bury, kick) to ensure successful processing and recovery from failures. beanstalkd communicates via a simple, text-based protocol, making it easy to integrate with almost any programming language.

CAVEATS

By default, beanstalkd runs purely in memory; all data will be lost if the daemon is stopped or crashes. To ensure persistence, the -b (binlog directory) option must be used.
beanstalkd itself is a single-server solution; it does not offer built-in clustering, replication, or high-availability features. For redundancy, external mechanisms (e.g., shared storage, active-passive setups with failover) are required.
While efficient, it's not designed for extremely high-throughput, guaranteed-delivery scenarios that complex message brokers like Apache Kafka or RabbitMQ address, but rather for its simplicity and speed in typical web application use cases.

JOB LIFECYCLE AND PROTOCOL

beanstalkd operates using a simple, text-based protocol over TCP. The core job lifecycle involves several commands:
PUT: Client creates a new job.
RESERVE: Worker fetches a job, making it invisible to other workers for a timeout duration.
DELETE: Worker successfully processes and deletes the job.
RELEASE: Worker fails to process the job and returns it to the ready queue, potentially with a delay.
BURY: Worker fails, moves the job to a 'buried' state, making it inaccessible until explicitly 'kicked'.
TOUCH: Worker signals it's still processing a job, extending its timeout to prevent it from being released.
KICK: Returns buried or delayed jobs to the ready queue, making them available for processing.

TUBES

Jobs are organized into 'tubes'. Tubes are independent queues that allow for logical separation of different types of jobs (e.g., 'email-sending', 'image-processing', 'report-generation'). Clients can 'put' jobs into specific tubes, and workers can 'watch' one or more tubes, enabling flexible routing and processing of jobs by different worker types.

HISTORY

beanstalkd was originally developed by Chris Dickinson and Phil Jacob at Percona in 2008 as a lightweight, persistent work queue for their internal needs. Its design emphasizes speed and simplicity, aiming to be a 'fast, simple, work queue'. It quickly gained popularity within the Ruby on Rails and PHP communities for handling background jobs due to its ease of use and small footprint, offering a more streamlined alternative to larger message brokers for many common use cases. It has since become a mature and widely adopted open-source project, maintained by a community of contributors.

SEE ALSO

supervisord(1) - A process control system, often used to manage beanstalkd daemon as a background service., systemctl(1) - The control utility for the systemd system and service manager, used for managing beanstalkd as a service., netstat(8) - A command-line network utility for displaying network connections, routing tables, interface statistics, etc., useful for verifying beanstalkd's listening port., ss(8) - Another utility to investigate sockets, similar to netstat but often faster.

Copied to clipboard