Redis利用主从复制机制，能够实现Redis高可用性。然而，如果Master服务器宕机，会导致整个Redis瘫痪，这种方式的高可用性较低。正常会采用多台Redis服务器构成一个集群.

在Redis中，主要存在两种方式实现Redis集群机制：

Redis Sentinel集群机制:在Redis2.X版本，往往都是通过这种方式实现Redis的高可用。redis-sentinel是在master-slave机制上加入监控机制哨兵Sentinel实现的。

Redis Cluster集群机制:在Redis3.0版本后推出了redis-cluster集群机制。redis-cluster集群中各个节点之间是对等的，即master-master模式。

注意：Redis Sentinel集群是解决HA问题的（主从同步），Redis Cluster集群是解决sharding问题的（分区），两种不重复，可以混合使用。

Sharding（分库分表）机制：Sharding是把数据库Scale Out到多个物理节点上的一种有效的方式。Shard代表“碎片”，将数据库分片分表则为sharding。 常用的sharding方案

    1. 按功能划分（垂直切分） 将不同功能相关的表放到不同的数据库中，譬如将用户管理相关表放到shard1上，将blog相关表放到shard2上。这样做的好处很直观，当需要用户列表时，就到shard1上获取。但是当某一部分的功能其数据量或者性能要求超出了可控的范围，我们就需要继续对其进行深入的sharding。
   
    2. 按表中某一字段值的范围划分（水平切分） 当伴随一个表的数据量越来越大，以至于不能承受的时候，就需要进行进一步的切分。一种选择是根据key的范围来做切分，譬如userID范围为1-10000的放到shard 10上，userID为userID为10000到20000的放到shanrd11上，这样的扩展就是可预见的。另一种是根据某一字段值得来划分，譬如根据用户名的首字母，如果是a-d，就属于shard 20，e-h就属于shard21，这样做也存在不均衡性，当某个范围超出了shard所能承受的范围就需要继续切分。还有按日期切分等等。
   
    3.基于hash的切分  类似于memcached的keyhash算法，一开始确定切分数据库的个数，通过hash取模来决定使用哪台 shard。这种方法能够平均的来分配数据，但是伴随着数据量的增大，需要进 行扩展的时候，这种方式无法做到在线扩容。每增加节点的时候，就需要对hash算法重新运算，数据需要重新衔接。
   
    4.基于路由表的切分 基于路由表的切分是一种更加松散的方法。它单独维护一张路由 表，根据用户的某一属性来查找路由表决定使用哪个shard，这种方式是一种更加通用的方案。譬如我们在系统中维护一张表-（用户所属省-〉 shard），这样每个用户我们知道是哪个省的，去路由表查找，就知道它所在的shard。因为每次数据操作的时候都需要进行路由的查找，所以将这些内容 存储到一台独立cache上是一个非常好的方 式，譬如memcached。这种切分的方式同时也带来了另一个好处，当需要增加shard的时候，可以在不影响在线应用的情况下来执行，当然这也跟应用程序的架构设计相关，你的设计必须适用这种增加。 HA机制：通过尽量缩短因日常维护操作和突发的系统崩溃所导致的停机时间，以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。 下面详解这两种集群，并给出具体的演示示例。

1. Redis Sentinel集群机制 Redis-Sentinel是在master-slave机制上加入监控机制哨兵Sentinel实现的。Sentinel主要功能就是为Redis Master-Slave集群提供：

    监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
    
    提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

    自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
    
    在Sentinel集群中，一个最小的Master-Slave单元包含一个master和一个slave服务器。当master失效后，sentinel自动将slave提升为master，从而可以减少管理员的人工切换slave的操作过程。

2. Redis Cluster集群机制 2.1 Redis-cluster介绍 Redis-cluster是一种服务器Sharding技术，Redis3.0以后版本正式提供支持。Redis-cluster没有使用一致性hash，而是引入了哈希槽的概念。Redis-cluster中有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽。Cluster中的每个节点负责一部分hash槽（hash slot），比如集群中存在三个节点，则可能存在的一种分配如下：

节点A包含0到5500号哈希槽； 节点B包含5501到11000号哈希槽； 节点C包含11001 到 16384号哈希槽。 这种集群架构很容易扩展，如果扩充一个节点D，只需要将A、B、C节点中的部分槽放置在D上；如果想移除节点A，只需要将A的slot转移到B和C节点上。由于将哈希槽从一个节点移动到另一个节点不需要停止服务，只需要通过命令直接再分配，因而上述拓展不会造成集群不可用。目前这种方式还是一种半自动的方式，需要人工介入。

2.2 Redis-Cluster主从复制 在Redis-Cluster中，如果某个节点宕机或者处在不可用状态时，那它负责的Hash槽也将失效，导致整个集群不可用。因而为了提供高可用性，正常会将每个节点配置成主从式结构，即一个master节点，挂载多个slave节点。如果master节点失效时，集群便会选取新一个slave节点作为master，继续提供服务，从而不会导致整个集群不可用。