本文参考Redis官方文档里针对cluster方案的特点和运行机制进行整理，从而了解其运行原理。

  Redis官方提出了Redis集群方案所要实现的一系列目标：

• 高性能

• 可扩展性

• 无需代理

• 可容忍的写丢失

• 可用性

  我们从集群的运行过程来看上面提到的特点。

集群的初始化启动

  cluster方案下，集群内的节点实例启动后，每个节点都需要打开两个TCP连接， 一个是节点自身的业务端口，另一个是（10000+业务端口）计算出的端口，第二个端口是集群内部实例之间交互使用的端口。集群内，所有的redis节点通过PING-PONG等机制实现互相通信，也叫集群总线（cluster bus）。Redis集群在创建过程中，我们可以使用redis-trib命令行工具帮助完成主从关系的指定。根据我们的配置要求，一开始先指定了其中三个节点作为master，组成了整个集群的基础。然后为每个master逐个添加规划好的slave。

高性能

  在集群工作过程中，当redis节点收到请求后，发现数据不在自己这个实例上的slot时会发送重定向回应给客户端，客户端会得到一份最新的slot和key的正确对应关系，从而最终直接和正确的slot所在节点进行交互。另一方面，主从节点之间是异步复制，所以对于单个节点来说，在运行过程中，他是不会等其他节点的写入确认。综合这2个方面，对于客户端，实际上得到的是和单实例的redis交互一样的性能体验！

无需代理

  客户端（可能是应用层代码）不需要连接集群所有节点,连接集群中任何一个可用master节点即可进行数据交互。业务代码里一般会指定所有master的IP和端口，不用担心单个master故障带来的实例IP和端口的变化。而且当redis节点发现数据不在自己实例上的slot时会发送重定向回应给客户端，这样客户端代码其实压根也不在乎数据存在哪个实例下。这样，就体现出了不需要中间proxy层的特点！

便于扩展

  存储数据时，所有的键根据哈希函数(CRC16[key]&16383)映射到0－16383槽内。redis-cluster把所有的物理节点映射到[0-16383]slot上，然后cluster负责维护node、slot、value三者之间的映射关系。体现在使用过程中，就是散列槽从一个节点移动到另一个节点不需要停机操作，缩减或扩大容量都很方便。体现出了扩展性良好！可以看出，增减master是为了容量的扩大或减少。（官方指出可以达到1000个节点的扩展能力）

写保护

  其实写入丢失发生的可能性很少，官网提出最主要的情况是当master接收了一个新的写入后，还未来得及将数据写入给slave时，自己发生了永久性故障。官方认为这种情况就是真的大故障了，所以某种意义上不太容易出现，写还是比较安全的~

高可用

  当某个master挂掉后，该master的slave会自动接管。从概率上讲，master和自己的slave同时全部挂掉的概率是很低的。此外，cluster自身提供了一种replicas migration的机制，当某个master被检测到成了孤儿的时候，富余的slave节点会被分配给该master。slave存在实现了高可用性！

  其实理解了这些特性，我们也就理解了redis集群的运作机制~