优缺陷对比 Redis 四种集群打算引见

在服务开发中，单机都会存在单点缺点的疑问，即服务部署在一台主机上，一旦主机宕机服务就无法用，所以为了让服务高可用，散布式服务就出现了，将同一服务部署到多台机器上，即使其中几台主机宕机，只需有一台主机可用服务就可用。

redis也是一样，为了处置单机缺点引入了主从形式，但主从形式存在一个疑问：master节点缺点后服务，须要人为的手动将slave节点切换成为maser节点后服务才恢复。redis为处置这一疑问又引入了哨兵形式，哨兵形式能在master节点缺点后能智能将salve节点优化成master节点，不须要人工干预操作就能恢复服务可用。

然而主从形式、哨兵形式都没有到达真正的数据sharding存储，每个redis实例中存储的都是全量数据，所以redis cluster就降生了，成功了真正的数据分片存储。然而由于redis cluster颁布得比拟晚(2年才颁布正式版 )，各大厂等不迭了，陆陆续续开发了自己的redis数据分片集群形式，比如：Twemproxy、Codis等。

redis单节点只管有经过RDB和AOF耐久化机制能将数据耐久化到硬盘上，但数据是存储在一台主机上的，假设主机出现硬盘缺点等疑问，会造成数据无法用，而且读写无法分别，读写都在同一台主机上，恳求量大时会出现I/O瓶颈。

为了防止单点缺点 和 读写不分别，Redis 提供了复制（replication）性能成功master数据库中的数据更新后，会智能将更新的数据同步到其余slave数据库上。

如上redis主从结构特点：一个master可以有多个salve节点；salve节点可以有slave节点，从节点是级结合构。

主从形式优缺陷

个别的主从形式，当主数据库解体时，须要手动切换从数据库成为主数据库:

第一种主从同步/复制的形式，当主主机宕机后，须要手动把一台从主机切换为主主机，这就须要人工干预，费事费劲，还会形成一段时期外敷务无法用，这时刻就须要哨兵形式退场了。

哨兵形式是从Redis的2.6版本开局提供的，然而过后这个版本的形式是不稳固的，直到Redis的2.8版本，这个哨兵形式才稳固上去。

哨兵形式外围还是主从复制，只不过在相关于主从形式在主节点宕机造成无法写的状况下，多了一个竞选机制：从一切的从节点竞选出新的主节点。竞选机制的成功，是依赖于在系统中启动一个sentinel进程。

如上图，哨兵自身也有单点缺点的疑问，所以在一个一主多从的Redis系统中，可以经常使用多个哨兵启动监控，哨兵不只会监控主数据库和从数据库，哨兵之间也会相互监控。每一个哨兵都是一个独立的进程，作为进程，它会独立运转。

(1)哨兵形式的作用：

监控一切主机能否反常运转：经过发送命令前往监控主机的运转形态，处置监控主主机、从主机外，哨兵之间也相互监控。

缺点切换：当哨兵监测到master宕机，会智能将slave切换成master，而后经过颁布订阅形式通知其余的从主机，修正性能文件，让它们切换master。同时那台有疑问的旧主也会变为新主的从，也就是说当旧的主即使恢复时，并不会恢还原来的主身份，而是作为新主的一个从。

(2)哨兵成功原理

哨兵在启动进程时，会读取性能文件的内容，经过如下的性能找出须要监控的主数据库：

sentinel monitor mastername ip port quorum#ip和port 是主数据库地址和端口号#quorum示意在口头缺点切换操作前，须要多少哨兵节点赞同。

这里之所以只须要衔接主节点，是由于经过主节点的info命令，失掉从节点信息，从而和从节点也建设衔接，同时也能经过主节点的info信息知道新增从节点的信息。

一个哨兵节点可以监控多个主节点，然而并不倡议这么做，由于当哨兵节点解体时，同时有多个集群切换会出现缺点。哨兵启动后，会与主数据库建设两条衔接。

跟主数据库建设衔接后会定时口头以下三个操作：

(3)客观下线和客观下线

哨兵节点发送ping命令时，当超越必定时期(down-after-millisecond)后，假设节点未回复，则哨兵以为客观下线。客观下线示意哨兵以为该节点曾经下线，假设该节点为主数据库，哨兵会进一步判别是够须要对其启动缺点切换，这时刻就要发送命令(SENTINEL is-master-down-by-addr)征询其余哨兵节点能否以为该主节点是客观下线，当到达指定数量(quorum)时，哨兵就会以为是客观下线。

当主节点客观下线时就须要启动主从切换，主从切换的步骤为：

选出一个从数据库后，哨兵发送slave no one命令更新为主数据库，并发送slaveof命令将其余从节点的主数据库设置为新的主数据库。

(4)哨兵形式优缺陷

1.优势

2.无余-疑问

主从形式或哨兵形式每个节点存储的数据都是全量的数据，数据量过大时，就须要对存储的数据启动分片后存储到多个redis实例上。此时就要用到Redis Sharding技术。

Redis在3.0版本前只允许单实例形式，只管Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中参与集群的性能，但3.0版本等到2年才颁布正式版。各大企业等不迭了，在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实例群拓扑结构有变动时，每个客户端都须要更新调整。假设能把客户端分片模块独自拎进去，构成一个独自的模块(两边件)，作为客户端 和 服务端衔接的桥梁就能处置这个疑问了，此时代理分片就出现了。

(2)代理分片

redis代理分片用得最多的就是Twemproxy，由Twitter开源的Redis代理，其基本原理是：经过两边件的方式，Redis客户端把恳求发送到Twemproxy，Twemproxy依据路由规定发送到正确的Redis实例，最后Twemproxy把结果会集前往给客户端。

Twemproxy经过引入一个代理层，将多个Redis实例启动一致治理，使Redis客户端只须要在Twemproxy上启动操作，而不须要关心前面有多少个Redis实例，从而成功了Redis集群。

Twemproxy的优势：

Twemproxy的无余：

Twemproxy作为最被宽泛经常使用、最久经考验、稳固性最高的Redis代理，在业界被宽泛经常使用。

Twemproxy不能平滑参与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启动迁徙，以成功数据的平衡。

Redis 的哨兵形式只管曾经可以成功高可用，读写分别 ，然而存在几个方面的无余：

redis在3.0上参与了Cluster集群形式，成功了 Redis 的散布式存储，也就是说每台 Redis 节点上存储不同的数据。cluster形式为了处置单机Redis容量有限的疑问，将数据按必定的规定调配到多台机器，内存/QPS不受限于单机，可受益于散布式集群高裁减性。

Redis Cluster是一种主机Sharding技术(分片和路由都是在服务端成功)，驳回多主多从，每一个分区都是由一个Redis主机和多个从机组成，片区和片区之间是相互平行的。Redis Cluster集群驳回了P2P的形式，齐全去中心化。

如上图，官网介绍，集群部署至少要 3 台以上的master节点，最好经常使用 3 主 3 从六个节点的形式。Redis Cluster集群具有如下几个特点：

redis cluster重要是针对海量数据+高并发+高可用的场景，海量数据，假设你的数据量很大，那么倡议就用redis cluster，数据量不是很大时，经常使用sentinel就够了。redis cluster的性能和高可用性均优于哨兵形式。

Redis Cluster驳回虚构哈希槽分区而非分歧性hash算法，预先调配一些卡槽，一切的键依据哈希函数映射到这些槽内，每一个分区内的master节点担任保养一局部槽以及槽所映射的键值数据。