a.业务分割，大集群分为多个小集群；

　　b.减少不必要的数据；

　　c.调整数据过期策略等。
（4）适度冗余：Redis可以在不影响集群服务的情况下增加节点，因此节点数量适当冗余即可，不用太大。

集群的原理：

集群最核心的功能是数据分区，因此首先介绍数据的分区规则；然后介绍集群实现的细节：通信机制和数据结构；最后以cluster meet(节点握手)、cluster addslots(槽分配)为例，说明节点是如何利用上述数据结构和通信机制实现集群命令的。

数据分区方案：
　　数据分区有顺序分区、哈希分区等，其中哈希分区由于其天然的随机性，使用广泛；集群的分区方案便是哈希分区的一种。
　　哈希分区的基本思路是：对数据的特征值（如key）进行哈希，然后根据哈希值决定数据落在哪个节点。常见的哈希分区包括：哈希取余分区、一致性哈希分区、带虚拟节点的一致性哈希分区等。
　　（1）哈希取余分区
　　　　哈希取余分区思路非常简单：计算key的hash值，然后对节点数量进行取余，从而决定数据映射到哪个节点上。该方案最大的问题是，当新增或删减节点时，节点数量发生变化，系统中所有的数据都需要重新计算映射关系，引发大规模数据迁移。
　　（2）一致性哈希分区
　　　　一致性哈希算法将整个哈希值空间组织成一个虚拟的圆环，范围为0-2^32-1；对于每个数据，根据key计算hash值，确定数据在环上的位置，然后从此位置沿环顺时针行走，找到的第一台服务器就是其应该映射到的服务器。

　　　与哈希取余分区相比，一致性哈希分区将增减节点的影响限制在相邻节点。如果在node1和node2之间增加node5，则只有node2中的一部分数据会迁移到node5；如果去掉node2，则原node2中的数据只会迁移到node4中，只有node4会受影响。
　　　一致性哈希分区的主要问题在于，当节点数量较少时，增加或删减节点，对单个节点的影响可能很大，造成数据的严重不平衡。还是以上图为例，如果去掉node2，node4中的数据由总数据的1/4左右变为1/2左右，与其他节点相比负载过高。
　　（3）带虚拟节点的一致性哈希分区
　　　　该方案在一致性哈希分区的基础上，引入了虚拟节点的概念。Redis集群使用的便是该方案，其中的虚拟节点称为槽（slot）。槽是介于数据和实际节点之间的虚拟概念；每个实际节点包含一定数量的槽，每个槽包含哈希值在一定范围内的数据。引入槽以后，

　　　数据的映射关系由数据hash->实际节点，变成了数据hash->槽->实际节点。

　　　　在使用了槽的一致性哈希分区中，槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点之间的关系，增加或删除节点对系统的影响很小。仍以上图为例，系统中有4个实际节点，假设为其分配16个槽(0-15)； 槽0-3位于node1，4-7位于node2，

　　   以此类推。如果此时删除node2，只需要将槽4-7重新分配即可，例如槽4-5分配给node1，槽6分配给node3，槽7分配给node4；可以看出删除node2后，数据在其他节点的分布仍然较为均衡。槽的数量一般远小于2^32，远大于实际节点的数量；

　　  在Redis集群中，槽的数量为16384

　　下面这张图很好的总结了Redis集群将数据映射到实际节点的过程：

　　（1）Redis对数据的特征值（一般是key）计算哈希值，使用的算法是CRC16。 Crc16（key） = hash
　　（2）根据哈希值，计算数据属于哪个槽。 Hash % 16384
　　（3）根据槽与节点的映射关系，计算数据属于哪个节点。

Redis集群搭建：

一、主/从（master/slave）(缺点： 数据冗余，浪费内存 （ping - pong）

　　1.主节点读写，从节点只能读，不能写
　　2.当主节点读写数据变化时，会直接同步到从节点
　　3.一个master可以拥有多个slave，但是一个slave只能对应一个master

主从复制工作机制:
　　当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。

主从配置：
　　redis默认是主数据，所以master无需配置，我们只需要修改slave的配置即可。
　　a.设置需要连接的master的ip端口:
　　　　slaveof 192.168.0.107 6379
　　b.如果master设置了密码。需要配置：
　　　　masterauth
　　c.连接成功进入命令行后，可以通过以下命令行查看连接该数据库的其他库信息:
　　　　info replication

二、哨兵模式（sentinel）

　　哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。（ping - pong）

这里的哨兵有两个作用:
　　? 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
　　? 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
故障切换（failover）的过程:
　　假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的

配置：