Redis集群的搭建，我已经在前面文章介绍过了，这篇文章，就让我们来学习一下Redis的集群是如何实现的。
Redis最开始的集群搭建是依靠ZK的，但是在 3.0 之后版本支持redis-cluster集群。Redis-Cluster采用无中心结构，即每个节点保存数据和整个集群状态,每个节点都和其他所有 节点连接。
那么我们是如何知道，我们的数据保存在哪里的呢？这样的话，我们就需要了解另一个概念，槽。
Redis的集群里面有着一个槽（slots）的概念，他的大小是10的14次方（16384 ），每当我们向集群中set一个值的时候，我们就会通过 CRC16 算法得到一个值，然后再对16384 这个值取模，最后得到的值就是给他分配到值的槽的位置。同理，我们再读取数据的时候，也是通过这种方式获取的。
然后在集群创建的时候，我们的每个主节点就已经有了自己分配好的槽了（但是我还不知道他们初始化的时候是如何分配的槽，网上也没找到），但是只有主节点才有槽，所以，我们的集群中每个主节点，都必须要分配从节点，主节点负责数据的读取，从节点负责数据的同步（主从复制，这也是关于Redis高可用的体现，所以，我们的Redis是AP的，并不强调数据一致性）。
一旦主节点挂了，从节点变成主节点，即使原主节点重新上线，也会变成现在主节点的从节点。一旦有主节点挂了，且无从节点，整个集群也会下线。
另一个Redis集群中重要的内容就是哨兵了。
说实话我第一次听见这个名词的时候，我脑海里浮现的总是变种人里面的那个哨兵 (*^▽^*) 皮一下 哈哈
当然，Redis中的哨兵不可能像电影里面那么无所不能，它只有两个作用，一是监控主从节点是否正常，二是在主节点下线的时候，自动将从节点提升为主节点。说的高端点，就是实现自动化的系统监控和故障恢复功能。
总结一下：
Redis整体是基于高可用的，他的哨兵和主从复制保证了我们集群的可用性，同时为了解决内存浪费问题，又引入了去中心化的Redis-Cluster，保证了数据的分布式存储，又使用它的CRC16 算法和槽的概念，保证了能够找到对应的节点，但是呢，他也有着自己的缺点，那就是，如果集群达到上限，如果想在线扩容，会比较麻烦。
