gogrlx/nats-server
1
0
Fork 0
mirror of https://github.com/gogrlx/nats-server.git synced 2026-04-17 03:24:40 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #308 from nats-io/readme-clustering

Browse Source 
Updates to Clustering section
This commit is contained in:
Derek Collison
2016-07-16 01:36:18 -05:00
committed by GitHub
parent c58af70095 d022275087
commit b14d3b9405
1 changed files with 21 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
README.md
View File

@@ -197,28 +197,40 @@ Any value in the configuration language can be a variable reference (`key=$VALUE
## Clustering
NATS supports running each server in clustered mode. You can cluster servers together for high volume messaging systems and resiliency and high availability. Clients are cluster-aware. See also the [clustered NATS](http://nats.io/documentation/server/gnatsd-cluster/) documentation.
Clustering lets you scale NATS messaging by having multiple NATS servers communicate with each other. Clustering lets messages published to one server be routed and received by a subscriber on another server. See also the [clustered NATS](http://nats.io/documentation/server/gnatsd-cluster/) documentation.
The following cluster options are supported:
### Full mesh required
In order for clustering to work correctly, all NATS servers must be connected to each other.
NATS servers have a forwarding limit of one hop. This means that each server will **only** forward a message that it has received **from a client** to all connected servers that expressed interest in the message's published subject. A message received **from** a route will only be distributed to local clients.
### Configuration options
NATS supports running each server in clustered mode. The following command line options are supported:
--routes [rurl-1, rurl-2] Routes to solicit and connect
--cluster [cluster url] Cluster URL for solicited routes
--routes [rurl-1, rurl-2] Routes to solicit and connect
### Full mesh recommended
The `--cluster` flag specifies the NATS URL where the server listens for connections from other servers.
NATS clustered servers have a forwarding limit of one hop. This means that each `gnatsd` instance will **only** forward messages that it has received **from a client** to the immediately adjacent `gnatsd` instances to which it has routes. Messages received **from** a route will only be distributed to local clients. Therefore a full mesh cluster, or complete graph, is recommended for NATS to function as intended and as described here.
The `--routes` flag specifies the NATS URL for one or more servers in the cluster. When a server connects to a specified route, it will advertise its own cluster URL to other servers. Note that when the `--routes` option is specified a `--cluster` option is also required.
Previous releases required you to build the complete mesh using the `--routes` flag. To define your cluster in the current release, please follow the "Basic example" as described below.
### Basic example
Setting up a full mesh cluster is easy. When running NATS Servers in different hosts, the command line parameters for all servers can be as simple as:
NATS makes building the full mesh easy. Simply designate a server to be a *seed* server. All other servers in the cluster simply specify the *seed* server as its server's routes option as indicated below.
When running NATS Servers in different hosts, the command line parameters for all servers could be as simple as:
```
gnatsd -cluster nats://$HOSTNAME:$NATS_CLUSTER_PORT -routes nats://$NATS_SEED_HOST:$NATS_CLUSTER_PORT
gnatsd --cluster nats://$HOSTNAME:$NATS_CLUSTER_PORT --routes nats://$NATS_SEED_HOST:$NATS_CLUSTER_PORT
```
Even on the host where the "seed" is running, the above command would work. The server would detect an attempt to connect to itself and ignore that. In other words, the same command line could be deployed in several hosts and the full mesh will properly form.
Even on the host where the *seed* is running, the above would work as the server would detect an attempt to connect to itself and ignore that. In other words, the same command line could be deployed in several hosts and the full mesh will properly form.
Note that you don't have to connect all servers to the same "seed" server, any server accepting a connection will inform other servers in the mesh about that new server so that they can connect to it. The advantage of the seed approach, is that you can "deploy" the same configuration on all hosts.
Note that you don't have to connect all servers to the same *seed* server, any server accepting a connection will inform other servers in the mesh about that new server so that they can connect to it. The advantage of the seed approach, is that you can deploy the same configuration to all hosts.
### 3-node example