Cluster support is one of the big thing in slacker 0.6.x. Cluster enables high-availability and load balancing on slacker client and server.
Slacker cluster has a centralized registry, a zookeeper node, stores information of all the namespaces and servers instances in the cluster. Once a client declared remote functions, by calling `defn-remote` or `use-remote`, it reads all available servers offering that namespace from the registry and create connection to each of them. We the user issues a request, the client randomly pick up a connection from them. So the load is eventually distributed to every instance of slacker servers. And thanks to zookeeper’s notification feature, the client watches certain znode. It will be notified when 1. a connected server goes offline 2. a new server serving required namespace added into the cluster. Thus you don’t have to change client code or restart client when server changes.
To start a slacker server and add it to a cluster, you have to provide cluster information using the new :cluster option:
2104
:cluster {:zk "127.0.0.1:2181"
:name "example-cluster"})
- :zk is the address of zookeeper node
- :name is a znode qualified string, to identify the cluster
On the client side, it’s important to use APIs from `slacker.client.cluster` instead of `slacker.client`:
;; arguments: cluster-name, zookeeper address
(def sc (clustered-slackerc "example-cluster" "127.0.0.1:2181"))
(use-remote 'sc 'slacker.example.api)
;; call the function from a random server
(timestamp)
If all servers provide ‘slacker.example.api go offline, slacker client will raise a “not-found” exception.
Slacker cluster is also designed with simple and clean in mind. You don’t have to change you business code to make it remote or cluster. Everything is transparent and non-invasive. Enjoy it.
