Redis3集群搭建（上）- 基础知识
随着项目规模越来越大，单个Redis已经不能满足需求。Redis从3.0版本之后开始支持集群模式，可以进行分布式存储，本文将介绍一些Redis集群的基础知识，再从0开始搭建一个Redis集群。
Redis集群介绍
Redis集群是一个提供在多个Redis间节点间共享数据的程序集。
Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误。
Redis集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下继续处理命令. Redis集群的优势:
- 自动分割数据到不同的节点上。
- 整个集群的部分节点失败或者不可达的情况下能够继续处理命令。
Redis集群分片
Redis集群没有使用一致性hash, 而是引入了哈希槽的概念。
Redis集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽。（有点类似于Java的HashMap，通过取模计算具体的槽位）集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么: - 节点A包含0到5500号哈希槽
- 节点B包含5501到11000 号哈希槽
- 节点C包含11001到16384号哈希槽
这种结构很容易添加或者删除节点。比如如果我想新添加一个节点D, 我需要从节点A, B, C中移动部分槽到D上。如果我想移除节点A，需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.
Redis集群主从复制模型
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品。
在我们例子中具有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用。
如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了。不过当B和B1 都失败后，集群是不可用的。
Redis一致性保证
Redis 并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作。
第一个原因是因为集群是用了异步复制. 写操作过程:
- 客户端向主节点B写入一条命令。
- 主节点B向客户端回复命令状态。
- 主节点将写操作复制给他得从节点 B1, B2 和 B3。
主节点对命令的复制工作发生在返回命令回复之后，因为如果每次处理命令请求都需要等待复制操作完成的话，那么主节点处理命令请求的速度将极大地降低， 所以必须在性能和一致性之间做出权衡。注意：Redis集群可能会在将来提供同步写的方法。 Redis集群另外一种可能会丢失命令的情况是集群出现了网络分区，并且一个客户端与至少包括一个主节点在内的少数实例被孤立。
举个例子 假设集群包含A、B、C、A1、B1、C1六个节点，其中A、B 、C为主节点，A1、B1 、C1为A，B，C的从节点，还有一个客户端Z1假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点A 、C 、A1 、B1和C1，小部分的一方则包含节点B和客户端Z1。
Z1仍然能够向主节点B中写入, 如果网络分区发生时间较短,那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了。在网络分裂出现期间， 客户端Z1可以向主节点B发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout），是Redis集群的一个重要的配置选项。
