Skip to content

Instantly share code, notes, and snippets.

@antirez
Last active August 29, 2015 14:17
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save antirez/9bde5f5dcee13e95c3c7 to your computer and use it in GitHub Desktop.
Save antirez/9bde5f5dcee13e95c3c7 to your computer and use it in GitHub Desktop.

Job IDs

Disque jobs are uniquely identified by an ID like the following:

DI0f0c644fd3ccb51c2cedbd47fcb6f312646c993c05a0SQ

Job IDs always start with "DI" and end with "SQ" and are always composed of exactly 48 characters.

We can split an ID into multiple parts:

DI | 0f0c644f | d3ccb51c2cedbd47fcb6f312646c993c | 05a0 | SQ

  1. DI is the prefix
  2. 0f0c644f is the first 8 bytes of the node ID where the message was generated.
  3. d3ccb51c2cedbd47fcb6f312646c993c is the 128 bit ID pesudo random part in hex.
  4. 05a0 is the Job TTL in minutes. Because of it, message IDs can be expired safely even without having the job representation.
  5. SQ is the suffix.

IDs are returned by ADDJOB when a job is successfully created, are part of the GETJOB output, and are used in order to acknowledge that a job was correctly processed by a worker.

Part of the node ID is included in the message so that a worker processing messages for a given queue can easily guess what are the nodes where jobs are created, and move directly to these nodes to increase efficiency instead of listeing for messages in a node that will require to fetch messages from other nodes.

Only 64 bits of the original node ID is included in the message, however in a cluster with 1000 Disque nodes, the probability of two nodes to have identical 64 bit ID prefixes is given by the birthday paradox:

P(100,2^64) = .000000000000027

In case of collisions, the workers may just do a non-efficient choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment