前言
redis是一个开源的key value存储系统，受到了广大互联网公司的青睐。redis3.0版本之前只支持单例模式，在3.0版本及以后才支持集群，我这里用的是redis3.0.0版本；
redis集群采用P2P模式，是完全去中心化的，不存在中心节点或者代理节点；
redis集群是没有统一的入口的，客户端（client）连接集群的时候连接集群中的任意节点（node）即可，集群内部的节点是相互通信的（PING-PONG机制），每个节点都是一个redis实例；
为了实现集群的高可用，即判断节点是否健康（能否正常使用），redis-cluster有这么一个投票容错机制：如果集群中超过半数的节点投票认为某个节点挂了，那么这个节点就挂了（fail）。这是判断节点是否挂了的方法；
那么如何判断集群是否挂了呢? 如果集群中任意一个节点挂了，而且该节点没有从节点（备份节点），那么这个集群就挂了。这是判断集群是否挂了的方法；
那么为什么任意一个节点挂了（没有从节点）这个集群就挂了呢？ 因为集群内置了16384个slot（哈希槽），并且把所有的物理节点映射到了这16384[0-16383]个slot上，或者说把这些slot均等的分配给了各个节点。当需要在Redis集群存放一个数据（key-value）时，redis会先对这个key进行crc16算法，然后得到一个结果。再把这个结果对16384进行求余，这个余数会对应[0-16383]其中一个槽，进而决定key-value存储到哪个节点中。所以一旦某个节点挂了，该节点对应的slot就无法使用，那么就会导致集群无法正常工作。
综上所述，每个Redis集群理论上最多可以有16384个节点。
一、案例概述
1.1、单节点Redis服务器带来的问题
1.1.1、单点故障，服务不可用
1.1.2、无法处理大量的并发数据请求
1.1.3、数据丢失——大灾难
1.2、解决方法
搭建Redis集群
二、案例前置知识点
2.1、Redis集群介绍
2.1.1、Redis集群是一个提供在多个Redis间节点间共享数据的程序集
2.1.2、Redis集群并不支持处理多个keys的命令，因为这需要在不同的节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会导致不可预料的错误
2.1.3、Redis集群通过分区来提供一定程度的可用性，在实际环境中当某个节点宕机或者不可达的情况下可继续处理命令
2.2、Redis集群的优势
2.2.1、自动分割数据到不同的节点上
2.2.2、整个集群的部分节点失败或者不可达的情况下能够继续处理命令
2.3、Redis集群的实现方法
2.3.1、有客户端分片
2.3.2、代理分片
2.3.3、服务器端分片
2.4、Redis-Cluster数据分片
2.4.1、Redis集群没有使用一致性hash，而是引入了哈希槽概念
2.4.2、Redis集群有16384个哈希槽
2.4.3、每个key通过CRC16校验后对16384取模来决定放置槽
2.4.4、集群的每个节点负责一部分哈希槽
2.4.5、以3个节点组成的集群为例
①节点A包含0到5500号哈希槽
②节点B包含5501到11000号哈希槽
③节点C包含11001到16384号哈希槽
2.4.6、支持添加或者删除节点
①添加删除节点无需停止服务
②例如：
1）如果想新添加个节点D，需要移动节点A、B、C中的部分槽到D上
2）如果想移除节点A，需要将A中的槽移到B和C上，再将没有任何槽的A节点从集群中移除
2.4.7、Redis-Cluster的主从复制模型
①集群中具有A，B，C三个节点，如果节点B失败了，整个集群就会因缺少5501-11000这个范围的槽而不可用
②为每个节点添加一个从节点A1，B1，C1，整个集群便有三个master节点和三个slave节点组成，在节点B失败后，集群便会选举B1为新的主节点继续服务
③当B和B1都失败后，集群将不可用