Awesome
PostgreSQL queue for Node.js:
-
Supports pub-sub and work queues.
-
Highly configurable.
-
Full set of unit tests, including stress tests.
-
API-compatible with qlobber-fsq.
- Use as an alternative when you need to use the queue from multiple hosts (and prefer to use a database over a distributed filesystem).
-
Use as an alternative to RabbitMQ, Redis pub-sub etc.
- For example when you already have a PostgreSQL server.
-
Supports AMQP-like topics with single- and multi-level wildcards.
-
Tested on Linux and Windows.
Examples
const { QlobberPG } = require('qlobber-pg');
const qpg = new QlobberPG({
name: 'example1',
db: {
host: '/var/run/postgresql',
database: 'qlobber-pg'
}
});
qpg.subscribe('foo.*', (data, info) => {
console.log(info.topic, data.toString());
const assert = require('assert');
assert.equal(info.topic, 'foo.bar');
assert.equal(data, 'hello');
});
qpg.publish('foo.bar', 'hello');
You can publish messages using a separate process if you like:
const { QlobberPG } = require('qlobber-pg');
const qpg = new QlobberPG({
name: 'example2',
db: {
host: '/var/run/postgresql',
database: 'qlobber-pg'
}
});
qpg.publish('foo.bar', 'hello', qpg.stop);
Or use the streaming interface to read and write messages:
const { QlobberPG } = require('qlobber-pg');
const qpg = new QlobberPG({
name: 'example3',
db: {
host: '/var/run/postgresql',
database: 'qlobber-pg'
}
});
function handler(stream, info) {
const data = [];
stream.on('readable', function () {
let chunk;
while (chunk = this.read()) {
data.push(chunk);
}
});
stream.on('end', function () {
const s = Buffer.concat(data).toString();
console.log(info.topic, s);
const assert = require('assert');
assert.equal(info.topic, 'foo.bar');
assert.equal(s, 'hello');
});
}
handler.accept_stream = true;
qpg.subscribe('foo.*', handler);
qpg.publish('foo.bar').end('hello');
The API is described here.
Installation
To install the module:
npm install qlobber-pg
You need to create a database on your PostgreSQL server. You can use an administration tool (e.g. pgAdmin) or the command line, for example:
psql -c 'create database "qlobber-pg";'
Then you need to run migrations on your database to create the table
that qlobber-pg
uses:
npm run migrate
Note: The database is assumed to be named qlobber-pg
. If you created a
database with a different name, you’ll need to change it in
config/default.json.
Limitations
-
qlobber-pg
provides no guarantee that the order messages are given to subscribers is the same as the order in which the messages were written. If you want to maintain message order between readers and writers then you’ll need to do it in your application (using ACKs, sliding windows etc). Alternatively, use theorder_by_expiry
constructor option to have messages delivered in order of the time they expire. -
qlobber-pg
does its best not to lose messages but in exceptional circumstances (e.g. process crash, file system corruption) messages may get dropped. You should design your application to be resilient against dropped messages. -
qlobber-pg
makes no assurances about the security or privacy of messages in transit or at rest. It’s up to your application to encrypt messages if required. -
qlobber-pg
supports Node 10 onwards. -
Publish topics are restricted to characters
A-Za-z0-9_.
-
Subscription topics are restricted to characters
A-Za-z0-9_*#.
How it works
Publishing a message creates a row in a table in the database. The columns for each message are:
-
The ID, a big serial number. This is used in queries to make sure only messages published since the last check are returned.
-
The topic, a ltree label. Using ltree means wildcards (
*
and#
) can be supported when subscribing to topics. -
The expiry time, a time stamp. Messages which have expired are periodically deleted from the table.
-
Whether the message should be processed by a single
QlobberPG
instance or by all connectedQlobberPG
instances. This is a boolean which determines whether each message has work queue or pub sub semantics.- An advisory
lock
is used to make sure a work queue message is only processed by a
single
QlobberPG
instance.
- An advisory
lock
is used to make sure a work queue message is only processed by a
single
-
The message payload, as a byte array.
-
The name of the
QlobberPG
instance which published the message. This is used in queries to make sure only messages published since the last check are returned. The ID isn’t enough on its own because incrementing the ID and adding the row isn’t an atomic operation. That is, incrementing the current ID in the table and actually inserting a row can be interleaved.
The database is periodically queried for new messages and a trigger is optionally created to invoke a check as soon as a message is published.
The query made against the table is constructed from the topics to which
the QlobberPG
instance is subscribed.
Licence
Test
To run the default tests (including stress tests):
npm test
To run the multi-process tests (each process publishing and subscribing to different messages):
npm run test-multi [-- --queues=<number of queues>]
If you omit --queues
then one process will be created per core.
To run the distributed tests (one process per remote host, each one publishing and subscribing to different messages):
npm run test-remote [-- --remote=<host1> --remote=<host2> ...]
You can specify as many remote hosts as you like. The test uses cp-remote to run a module on each remote host. Make sure on each host:
-
The
qlobber-pq
module is installed at the same location. -
The same PostgreSQL server is accessible.
Please note the distributed tests don’t run on Windows.
Lint
npm run lint
Code Coverage
npm run coverage
c8 results are available here.
Coveralls page is here.
Benchmarking
To run the benchmark:
npm run bench -- --rounds=<number of rounds> \
--size=<message size> \
--ttl=<message time-to-live in seconds> \
(--queues=<number of queues> | \
--remote=<host1> --remote=<host2> ...)
If you provide at least one --remote=<host>
argument then the
benchmark will be distributed across multiple hosts using
cp-remote. Make sure on each
host:
-
The
qlobber-pq
module is installed at the same location. -
The same PostgreSQL server is accessible.