redis也是一样，为理解决单机故障引入了主从模式，但主从模式存在一个问题：master节点故障后做事，须要人为的手动将slave节点切换成为maser节点后做事才规复。redis为办理这一问题又引入了哨兵模式，哨兵模式能在master节点故障后能自动将salve节点提升成master节点，不须要人工干预操作就能规复做事可用。
但是主从模式、哨兵模式都没有达到真正的数据sharding存储，每个redis实例中存储的都是全量数据，以是redis cluster就出身了，实现了真正的数据分片存储。但是由于redis cluster发布得比较晚(2015年才发布正式版 )，各大厂等不及了，陆陆续续开拓了自己的redis数据分片集群模式，比如：Twemproxy、Codis等。
redis单节点虽然有通过RDB和AOF持久化机制能将数据持久化到硬盘上，但数据是存储在一台做事器上的，如果做事器涌现硬盘故障等问题，会导致数据不可用，而且读写无法分离，读写都在同一台做事器上，要求量大时会涌现I/O瓶颈。
为了避免单点故障 和 读写不分离，Redis 供应了复制（replication）功能实现master数据库中的数据更新后，会自动将更新的数据同步到其他slave数据库上。
如上redis主从构造特点：一个master可以有多个salve节点；salve节点可以有slave节点，从节点是级联结构。
主从模式优缺陷优点: 主从构造具有读写分离，提高效率、数据备份，供应多个副本等优点。不敷: 最大的不敷便是主从模式不具备自动容错和规复功能，主节点故障，集群则无法进行事情，可用性比较低，从节点升主节点须要人工手动干预。普通的主从模式，当主数据库崩溃时，须要手动切换从数据库成为主数据库:
在从数据库中利用SLAVE NO ONE命令将从数据库提升成主数据连续做事。启动之前崩溃的主数据库，然后利用SLAVEOF命令将其设置成新的主数据库的从数据库，即可同步数据。2.哨兵模式第一种主从同步/复制的模式，当主理事器宕机后，须要手动把一台从做事器切换为主理事器，这就须要人工干预，费事费力，还会造成一段韶光内做事不可用，这时候就须要哨兵模式登场了。
哨兵模式是从Redis的2.6版本开始供应的，但是当时这个版本的模式是不稳定的，直到Redis的2.8版本往后，这个哨兵模式才稳定下来。
哨兵模式核心还是主从复制，只不过在相对付主从模式在主节点宕机导致不可写的情形下，多了一个竞选机制：从所有的从节点竞选出新的主节点。竞选机制的实现，是依赖于在系统中启动一个sentinel进程。
如上图，哨兵本身也有单点故障的问题，以是在一个一主多从的Redis系统中，可以利用多个哨兵进行监控，哨兵不仅会监控主数据库和从数据库，哨兵之间也会相互监控。每一个哨兵都是一个独立的进程，作为进程，它会独立运行。
(1)哨兵模式的浸染：
监控所有做事器是否正常运行：通过发送命令返回监控做事器的运行状态，处理监控主理事器、从做事器外，哨兵之间也相互监控。
故障切换：当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式关照其他的从做事器，修正配置文件，让它们切换master。同时那台有问题的旧主也会变为新主的从，也便是说当旧的主纵然规复时，并不会恢复原来的主身份，而是作为新主的一个从。
(2)哨兵实现事理哨兵在启动进程时，会读取配置文件的内容，通过如下的配置找出须要监控的主数据库：
sentinel monitor master-name ip port quorum#master-name是主数据库的名字#ip和port 是当前主数据库地址和端口号#quorum表示在实行故障切换操作前，须要多少哨兵节点赞许。
这里之以是只须要连接主节点，是由于通过主节点的info命令，获取从节点信息，从而和从节点也建立连接，同时也能通过主节点的info信息知道新增从节点的信息。
一个哨兵节点可以监控多个主节点，但是并不提倡这么做，由于当哨兵节点崩溃时，同时有多个集群切换会发生故障。哨兵启动后，会与主数据库建立两条连接。
订阅主数据库_sentinel_:hello频道以获取同样监控该数据库的哨兵节点信息定期向主数据库发送info命令，获取主数据库本身的信息。跟主数据库建立连接后会定时实行以下三个操作：
（1）每隔10s向master和 slave发送info命令。浸染是获取当前数据库信息，比如创造新增从节点时，会建立连接，并加入到监控列表中，当主从数据库的角色发生变革进行信息更新。
（2）每隔2s向主数据里和从数据库的_sentinel_:hello频道发送自己的信息。浸染是将自己的监控数据和哨兵分享。每个哨兵会订阅数据库的_sentinel:hello频道，当其他哨兵收到后，会判断该哨兵是不是新的哨兵，如果是则将其加入哨兵列表，并建立连接。
（3）每隔1s向所有主从节点和所有哨兵节点发送ping命令，浸染是监控节点是否存活。
(3)主不雅观下线和客不雅观下线哨兵节点发送ping命令时，当超过一定韶光(down-after-millisecond)后，如果节点未回答，则哨兵认为主不雅观下线。主不雅观下线表示当前哨兵认为该节点已经下面，如果该节点为主数据库，哨兵会进一步判断是够须要对其进行故障切换，这时候就要发送命令(SENTINEL is-master-down-by-addr)讯问其他哨兵节点是否认为该主节点是主不雅观下线，当达到指天命量(quorum)时，哨兵就会认为是客不雅观下线。
当主节点客不雅观下线时就须要进行主从切换，主从切换的步骤为：
选出领头哨兵。领头哨兵所有的slave选出优先级最高的从数据库。优先级可以通过slave-priority选项设置。如果优先级相同，则从复制的命令偏移量越大（即复制同步数据越多，数据越新），越优先。如果以上条件都一样，则选择run ID较小的从数据库。选出一个从数据库后，哨兵发送slave no one命令升级为主数据库，并发送slaveof命令将其他从节点的主数据库设置为新的主数据库。
(4)哨兵模式优缺陷1.优点
哨兵模式是基于主从模式的，办理可主从模式中master故障不可以自动切换故障的问题。2.不敷-问题
是一种中央化的集群实现方案：始终只有一个Redis主机来吸收和处理写要求，写操作受单机瓶颈影响。集群里所有节点保存的都是全量数据，摧残浪费蹂躏内存空间，没有真正实现分布式存储。数据量过大时，主从同步严重影响master的性能。Redis主机宕机后，哨兵模式正在投票选举的情形之外，由于投票选举结束之前，谁也不知道主机和从机是谁，此时Redis也会开启保护机制，禁止写操作，直到选举出了新的Redis主机。主从模式或哨兵模式每个节点存储的数据都是全量的数据，数据量过大时，就须要对存储的数据进行分片后存储到多个redis实例上。此时就要用到Redis Sharding技能。
3.各大厂的Redis集群方案Redis在3.0版本前只支持单实例模式，虽然Redis的开拓者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能，但3.0版本等到2015年才发布正式版。各大企业等不急了，在3.0版本还没发布前为理解决Redis的存储瓶颈，纷纭推出了各自的Redis集群方案。这些方案的核心思想是把数据分片（sharding）存储在多个Redis实例中，每一片便是一个Redis实例。
(1)客户端分片客户端分片是把分片的逻辑放在Redis客户端实现，（比如：jedis已支持Redis Sharding功能，即ShardedJedis），通过Redis客户端预先定义好的路由规则(利用同等性哈希)，把对Key的访问转发到不同的Redis实例中，查询数据时把返回结果搜集。这种方案的模式如图所示。
客户端分片的优缺陷：
优点：客户端sharding技能利用hash同等性算法分片的好处是所有的逻辑都是可控的，不依赖于第三方分布式中间件。做事真个Redis实例彼此独立，相互无关联，每个Redis实例像单做事器一样运行，非常随意马虎线性扩展，系统的灵巧性很强。开拓职员清楚怎么实现分片、路由的规则，不用担心踩坑。
1.同等性哈希算法:是分布式系统中常用的算法。比如，一个分布式的存储系统，要将数据存储到详细的节点上，如果采取普通的hash方法，将数据映射到详细的节点上，如mod(key,d)，key是数据的key，d是机器节点数，如果有一个机器加入或退出这个集群，则所有的数据映射都无效了。
同等性哈希算法办理了普通余数Hash算法伸缩性差的问题，可以担保在上线、下线做事器的情形下只管即便有多的要求命中原来路由到的做事器。
2.实现办法：同等性hash算法，比如MURMUR_HASH散列算法、ketamahash算法比如Jedis的Redis Sharding实现，采取同等性哈希算法(consistent hashing)，将key和节点name同时hashing，然后进行映射匹配，采取的算法是MURMUR_HASH。
采取同等性哈希而不是采取大略类似哈希求模映射的紧张缘故原由是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。同等性哈希只影响相邻节点key分配，影响量小。
不敷：
这是一种静态的分片方案，须要增加或者减少Redis实例的数量，须要手工调度分片的程序。运维本钱比较高，集群的数据出了任何问题都须要运维职员和开拓职员一起互助，减缓理解决问题的速率，增加了跨部门沟通的本钱。在不同的客户端程序中，掩护相同的路由分片逻辑本钱巨大。比如：java项目、PHP项目里共用一套Redis集群，路由分片逻辑分别须要写两套一样的逻辑，往后掩护也是两套。客户端分片有一个最大的问题便是，做事端Redis实例群拓扑构造有变革时，每个客户端都须要更新调度。如果能把客户端分片模块单独拎出来，形成一个单独的模块(中间件)，作为客户端 和 做事端连接的桥梁就能办理这个问题了，此时期理分片就涌现了。
(2)代理分片redis代理分片用得最多的便是Twemproxy，由Twitter开源的Redis代理，其基本事理是：通过中间件的形式，Redis客户端把要求发送到Twemproxy，Twemproxy根据路由规则发送到精确的Redis实例，末了Twemproxy把结果搜集返回给客户端。
Twemproxy通过引入一个代理层，将多个Redis实例进行统一管理，使Redis客户端只须要在Twemproxy上进行操作，而不须要关心后面有多少个Redis实例，从而实现了Redis集群。
Twemproxy的优点：客户端像连接Redis实例一样连接Twemproxy，不须要改任何的代码逻辑。支持无效Redis实例的自动删除。Twemproxy与Redis实例保持连接，减少了客户端与Redis实例的连接数。Twemproxy的不敷：由于Redis客户真个每个要求都经由Twemproxy代理才能到达Redis做事器，这个过程中会产生性能丢失。没有友好的监控管理后台界面，不利于运维监控。Twemproxy最大的痛点在于，无法平滑地扩容/缩容。对付运维职员来说，当由于业务须要增加Redis实例时事情量非常大。
Twemproxy作为最被广泛利用、最久经磨练、稳定性最高的Redis代理，在业界被广泛利用。
(3)CodisTwemproxy不能平滑增加Redis实例的问题带来了很大的不便，于是豌豆荚自主研发了Codis，一个支持平滑增加Redis实例的Redis代理软件，其基于Go和C措辞开拓，并于2014年11月在GitHub上开源。
在Codis的架构图中，Codis引入了Redis Server Group，其通过指定一个主CodisRedis和一个或多个从CodisRedis，实现了Redis集群的高可用。当一个主CodisRedis挂掉时，Codis不会自动把一个从CodisRedis提升为主CodisRedis，这涉及数据的同等性问题（Redis本身的数据同步是采取主从异步复制，当数据在主CodisRedis写入成功时，从CodisRedis是否已读入这个数据是没法担保的），须要管理员在管理界面上手动把从CodisRedis提升为主CodisRedis。
如果手动处理以为麻烦，豌豆荚也供应了一个工具Codis-ha，这个工具会在检测到主CodisRedis挂掉的时候将其下线并提升一个从CodisRedis为主CodisRedis。
Codis中采取预分片的形式，启动的时候就创建了1024个slot，1个slot相称于1个箱子，每个箱子有固定的编号，范围是1~1024。slot这个箱子用作存放Key，至于Key存放到哪个箱子，可以通过算法“crc32(key)%1024”得到一个数字，这个数字的范围一定是1~1024之间，Key就放到这个数字对应的slot。
例如，如果某个Key通过算法“crc32(key)%1024”得到的数字是5，就放到编码为5的slot（箱子）。1个slot只能放1个Redis Server Group，不能把1个slot放到多个Redis Server Group中。1个Redis Server Group最少可以存放1个slot，最大可以存放1024个slot。因此，Codis中最多可以指定1024个Redis Server Group。
Codis最大的上风在于支持平滑增加（减少）Redis Server Group（Redis实例），能安全、透明地迁移数据，这也是Codis 有别于Twemproxy等静态分布式 Redis 办理方案的地方。Codis增加了Redis Server Group后，就牵扯到slot的迁移问题。
例如，系统有两个Redis Server Group，Redis Server Group和slot的对应关系如下。
当增加了一个Redis Server Group，slot就要重新分配了。Codis分配slot有两种方法：
第一种：通过Codis管理工具Codisconfig手动重新分配，指定每个Redis Server Group所对应的slot的范围，例如：可以指定Redis Server Group和slot的新的对应关系如下。
第二种：通过Codis管理工具Codisconfig的rebalance功能，会自动根据每个Redis Server Group的内存对slot进行迁移，以实现数据的均衡。
4.Redis ClusterRedis 的哨兵模式虽然已经可以实现高可用，读写分离 ，但是存在几个方面的不敷：
哨兵模式下每台 Redis 做事器都存储相同的数据，很摧残浪费蹂躏内存空间；数据量太大，主从同步时严重影响了master性能。哨兵模式是中央化的集群实现方案，每个从机和主机的耦合度很高，master宕机到salve选举master规复期间做事不可用。哨兵模式始终只有一个Redis主机来吸收和处理写要求，写操作还是受单机瓶颈影响，没有实现真正的分布式架构。redis在3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也便是说每台 Redis 节点上存储不同的数据。cluster模式为理解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器，内存/QPS不受限于单机，可受益于分布式集群高扩展性。
Redis Cluster是一种做事器Sharding技能(分片和路由都是在做事端实现)，采取多主多从，每一个分区都是由一个Redis主机和多个从机组成，片区和片区之间是相互平行的。Redis Cluster集群采取了P2P的模式，完备去中央化。
如上图，官方推举，集群支配至少要 3 台以上的master节点，最好利用 3 主 3 从六个节点的模式。Redis Cluster集群具有如下几个特点：
集群完备去中央化，采取多主多从；所有的redis节点彼此互联(PING-PONG机制)，内部利用二进制协议优化传输速率和带宽。客户端与 Redis 节点直连，不须要中间代理层。客户端不须要连接集群所有节点，连接集群中任何一个可用节点即可。每一个分区都是由一个Redis主机和多个从机组成，分片和分片之间是相互平行的。每一个master节点卖力掩护一部分槽，以及槽所映射的键值数据；集群中每个节点都有全量的槽信息，通过槽每个node都知道详细数据存储到哪个node上。redis cluster紧张是针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster，数据量不是很大时，利用sentinel就够了。redis cluster的性能和高可用性均优于哨兵模式。
Redis Cluster采取虚拟哈希槽分区而非同等性hash算法，预先分配一些卡槽，所有的键根据哈希函数映射到这些槽内，每一个分区内的master节点卖力掩护一部分槽以及槽所映射的键值数据。
