Update the docs

docs/guides/redis/clustering/redis-cluster.md

@@ -1,12 +1,12 @@
 ---
 
 
-title: MongoDB ReplicaSet Guide
+title: Redis Cluster Guide
 menu:
   docs_0.9.0:
-    identifier: mg-clustering-replicaset
-    name: ReplicaSet Guide
-    parent: mg-clustering-mongodb
+    identifier: rd-cluster
+    name: Clustering Guide
+    parent: rd-clustering-redis
     weight: 15
 menu_name: docs_0.9.0
 section_menu_id: guides

docs/guides/redis/clustering/redis-clustering-concept.md

@@ -1,10 +1,10 @@
 ---
-title: MongoDB ReplicaSet Concept
+title: Redis Cluster Concept
 menu:
   docs_0.9.0:
-    identifier: mg-clustering-replicaset-concept
-    name: ReplicaSet Concept
-    parent: mg-clustering-mongodb
+    identifier: rd-clustering-concept
+    name: Clustering Concept
+    parent: rd-clustering-redis
     weight: 10
 menu_name: docs_0.9.0
 section_menu_id: guides
@@ -16,7 +16,7 @@ section_menu_id: guides
 
 Redis Cluster provides a way to partition data among multiple master nodes (data sharding) and ensures data availability. Each of the master nodes may have its own replicas. The cluster member nodes (both masters and slaves) detect failures via internal interconnection among themselves. When a majority of nodes agree with the failure of a master node, one of the slaves of the failed master node is promoted to the new master.
 
-So basically it is a group of multiple Redis nodes where data is **automatically sharded across multiple Redis nodes**. And it also provides **some degree of availability during partitions**, that is in practical terms the ability to continue the operations when some nodes fail or are not able to communicate. However the cluster stops to operate in the event of larger failures (for example when the majority of masters are unavailable).
+So basically it is a group of multiple Redis nodes where data is **automatically sharded across multiple Redis nodes**. And it also provides **some degree of availability during partitions**, that is in practical terms the ability to continue the operations when some nodes fail or are not able to communicate. However, the cluster stops to operate in the event of larger failures (for example when the majority of masters are unavailable).
 
 So in practical terms, what do you get with Redis Cluster?
 
@@ -123,12 +123,56 @@ For more parameters, see [here](http://download.redis.io/redis-stable/redis.conf
 
 ## Redis Cluster main components
 
-- [Keys distribution model](https://redis.io/topics/cluster-spec#keys-distribution-model)
-- [ Keys hash tags](https://redis.io/topics/cluster-spec#keys-hash-tags)
-- [ Cluster nodes attributes](https://redis.io/topics/cluster-spec#cluster-nodes-attributes)
-- [ The Cluster bus](https://redis.io/topics/cluster-spec#the-cluster-bus)
-- [ Cluster topology](https://redis.io/topics/cluster-spec#cluster-topology)
-- [Nodes handshake](https://redis.io/topics/cluster-spec#nodes-handshake)
+- **Keys distribution model**: The key space is split into 16384 slots, effectively setting an upper limit for the cluster size of 16384 master nodes (however the suggested max size of nodes is in the order of ~ 1000 nodes).
+
+  Each master node in a cluster handles a subset of the 16384 hash slots. The cluster is **stable** when there is no cluster reconfiguration in progress (i.e. where hash slots are being moved from one node to another). When the cluster is stable, a single hash slot will be served by a single node (however the serving node can have one or more slaves that will replace it in the case of net splits or failures, and that can be used in order to scale read operations where reading stale data is acceptable).
+
+  Reference: https://redis.io/topics/cluster-spec#keys-distribution-model
+
+- **Keys hash tags**: There is an exception for the computation of the hash slot that is used in order to implement **hash tags**. Hash tags are a way to ensure that multiple keys are allocated in the same hash slot. This is used in order to implement multi-key operations in Redis Cluster.
+
+  Reference: https://redis.io/topics/cluster-spec#keys-hash-tags
+
+- **Cluster nodes' attributes**: Every node has a unique name in the cluster. The node name is the hex representation of a 160 bit random number, obtained the first time a node is started (usually using /dev/urandom). The node will save its ID in the node configuration file, and will use the same ID forever, or at least as long as the node configuration file is not deleted by the system administrator, or a *hard reset* is requested via the [CLUSTER RESET](https://redis.io/commands/cluster-reset) command.
+
+  A detailed [explanation of all the node fields](http://redis.io/commands/cluster-nodes) is described in the [CLUSTER NODES](https://redis.io/commands/cluster-nodes) documentation.
+
+  The following is sample output of the [CLUSTER NODES](https://redis.io/commands/cluster-nodes) command sent to a master node in a small cluster of three nodes.
+
+  ```console
+  $ redis-cli cluster nodes
+  d1861060fe6a534d42d8a19aeb36600e18785e04 127.0.0.1:6379 myself - 0 1318428930 1 connected 0-1364
+  3886e65cc906bfd9b1f7e7bde468726a052d1dae 127.0.0.1:6380 master - 1318428930 1318428931 2 connected 1365-2729
+  d289c575dcbc4bdd2931585fd4339089e461a27d 127.0.0.1:6381 master - 1318428931 1318428931 3 connected 2730-4095
+  ```
+
+  Reference: https://redis.io/topics/cluster-spec#cluster-nodes-attributes
+
+- **The Cluster bus**: Every Redis Cluster node has an additional TCP port for receiving incoming connections from other Redis Cluster nodes. This port is at a fixed offset from the normal TCP port used to receive incoming connections from clients. To obtain the Redis Cluster port, 10000 should be added to the normal commands port. For example, if a Redis node is listening for client connections on port 6379, the Cluster bus port 16379 will also be opened.
+
+  Reference: https://redis.io/topics/cluster-spec#the-cluster-bus
+
+- **Cluster topology**: Redis Cluster is a full mesh where every node is connected with every other node using a TCP connection.
+
+  In a cluster of N nodes, every node has N-1 outgoing TCP connections and N-1 incoming connections.
+
+  These TCP connections are kept alive all the time and are not created on demand. When a node expects a pong reply in response to a ping in the cluster bus, before waiting long enough to mark the node as unreachable, it will try to refresh the connection with the node by reconnecting from scratch.
+
+  Reference: https://redis.io/topics/cluster-spec#cluster-topology
+
+- Nodes handshake**: Nodes always accept connections on the cluster bus port, and even reply to pings when received, even if the pinging node is not trusted. However, all other packets will be discarded by the receiving node if the sending node is not considered part of the cluster.
+
+  A node will accept another node as part of the cluster only in two ways:
+
+  - If a node presents itself with a `MEET` message. A meet message is exactly like a [PING](https://redis.io/commands/ping) message but forces the receiver to accept the node as part of the cluster. Nodes will send `MEET` messages to other nodes **only if** the system administrator requests this via the following command:
+
+    ```console
+    $ CLUSTER MEET ip port
+    ```
+
+  - A node will also register another node as part of the cluster if a node that is already trusted will gossip about this other node. So if A knows B, and B knows C, eventually B will send gossip messages to A about C. When this happens, A will register C as part of the network, and will try to connect with C.
+
+  Reference: https://redis.io/topics/cluster-spec#nodes-handshake
 
 ## Next Steps