• Module Docs
• API Docs

Skyring

A distributed reliable timer service providing similar functionality to using setTimeout. Skyring servers are clustered into a hashring using consistent hashing to partition timers to specific nodes in the ring. Skyring exposes a simple HTTP API That allows to you create and cancel timers. Timer execution comes in to the form of an HTTP webhook ( more transports to come )

Architechture Overview

Install

npm install -s skyring

Run A Local Cluster

Start a nats instance

Download the nats binary and start it using the defaults

$ gnats -D -V

To verify that it is working, you can telnet directly to the server and ping it.

$ telnet localhost 42222
> ping
PONG

Skyring CLI

If you intend to run skyring as is, it may be preferable to use the included binary over cloning the project.

npm install -g skyring

DEBUG=skyring:* skyring run -p 3000 -s localhost:3456 -s localhost:3455

Using in your project

If you want to use the skyring directly, you can just require it and start it directly. most of the available enviroment and cli arguments can be passed to the {@link module:skyring/lib/server|skyring constructor}. If you don't pass anything to the construct the default values are {@link module:keef|loaded} from the appropriate sources

// index.js
const Skyring = require('skyring')
const server = new Skyring()
 
function onSignal() {
  server.close(()=>{
    console.log('shutting down');
  });
}
 
server.load().listen(3000, (err) => {
  if (err) throw err
  console.log('skyring listening at %s', 'http://0.0.0.0:3000')
})
 
process.once('SIGINT', onSignal);
process.once('SIGTERM', onSignal);

This can then be started as a single node cluster

$ DEBUG=* node . --channel:port=3455 --seeds='localhost:3455'

The default settings expect a minimum of 2 servers on port 3455 and 3456 respectively. Start each server in a different terminal session

# Seed node 1 
$ DEBUG=skyring:* node index.js --channel:port=3455 -p 3000

# Seed node 2 
$ DEBUG=skyring:* node index.js --channel:port=3456 -p 3001

If all goes well you should see a message like this

skyring:ring ring bootstraped [ '127.0.0.1:3455', '127.0.0.1:3456' ] +1ms

Thats it, you have 2 instances running w/ HTTP servers running on ports 3000 and 3001

Run via Docker Compose

The Easiest way to run a small cluster is to use the included compose files. It is also a good way to see how to quickly configure a cluster

• Install Docker Compose

$ npm start

That is it! You have a 5 node Skyring cluster with a 3 node nats cluster behind an nginx proxy listening on port 8080

Timer API

A request can be issued to any active node in the cluster. If that node is not responsible for the timer in question, it will forward the request directly to the node that is keeping network latency to a minimum. This makes Skyring very suitable for high performance, stateless, and distributed environments. The minimum recommended cluster size is 3 nodes, 2 of which being seed or bootstrapping nodes. A cluster of this size can average between 2K - 5K requests per second.

Create a timer

POST /timer

Request

curl -i -XPOST http://localhost:8080/timer -d '{
  "timout": 6000,
  "data" : "{\"foo\":\"bar\"}",
  "callback": {
    "transport": "http",
    "method": "post",
    "uri": "http://api.someservice.com/hook/timout"
  }
}'

Response Headers

For performance considerations, a body is not included in responses. Rather, HTTP headers are used to relay information about timer status. In the case of a Create request, the uri to the timer instance is returned in the Location header.

HTTP/1.1 201 CREATED
location: /timer/4adb026b-6ef3-44a8-af16-4d6be0343ecf
Date: Fri, 23 Dec 2016 00:19:13 GMT
Connection: keep-alive
Content-Length: 0

Cancel A Timer

DELETE /timer/:id

Request

curl -i -XDELETE http://localhost:8080/timer/4adb026b-6ef3-44a8-af16-4d6be0343ecf

Response Headers

HTTP/1.1 202 Accepted
Date: Fri, 23 Dec 2016 00:22:12 GMT
Connection: keep-alive
Content-Length: 0

Crash Recovery

Each Skyring node uses an internal levelup instance to record timers that it owns. When a node starts, it will check the configured database for any existing timers, and will immediately load them back into memory. By default, the memdown backend is used, and wil not persists between starts. To enable full persistence and recovery, you must configure skyring to use a persistent backend for levelup. Leveldown is installed by default.

skyring run --storage:backend=leveldown --storage:path='/var/data/skyring'

Custom Transports

Skyring ships with a single HTTP transport, but support custom transports. A transport is a named function that can be executed when a timer triggers. To register a transport, you can pass an array of named functions, or requireable paths to the skyring server constructor via via the {@link module:skyring/lib/transports|transports} option

Optionally, for transports that need to perform some clean up work, a function property shutdown may be defined on the transport

const path = require('path')
const Skyring = require('skyring')
 
function fizzbuz(method, uri, payload, id, timer_store) {
 // send payload to uri...
 timer_store.remove(id)
}
 
fuzzbuz.shutdown(cb) {
  // drain connections...
  // free up event loop
  cb()
}
 
const server = new Skyring({
  transports: [
    'my-transport-module'
  , fizzbuz
  , path.resolve(__dirname, '../transports/fake-transport')
  ]
})

The same can be achieved through CLI arguments or ENV vars via the transport key

transport=foobar,fizzbuz node index.js

node index --transport=foobar --transport=fizzbuz --transport=$PWD/../path/to/my-transport