Nosql之Redis集群模式

现今 Redis 在很多业务场景，使用越来越广泛。在互联网发展的今天，网站的稳定性和高可用性不言而喻。随着技术的发展，集群方案层出不穷，目前 Redis 集群的实现方法一般有客户端分片、代理分片和服务器端分片三种解决方案。

redis集群方式

redis有三种模式：分别是主从复制、哨兵模式、cluster

主从模式

主从复制是高可用 Redis 的基础,哨兵和群集都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单故障恢复。缺陷:故障恢复无法自动化，写操作无法负载均衡，存储能力受到单机的限制。

哨兵模式

在主从复制的基础上，哨兵实现了自动化的故障恢复。缺陷:写操作无法负载均衡，存储能力受到单机的限制，哨兵无法对从节点进行自动故障转移;在读写分离场景下，从节点故障会导致读服务不可用，需要对从节点做额外的监控、切换操作。

集群模式

通过集群，Redis 解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
Redis-Cluster 是在 Redis3.0 版中推出，支持 Redis 分布式集群部署模式，采用无中心分布式架构。所有的 Redis 节点彼此互联(PING-PONG 机制)，内部使用二进制协议优化传输速度和带宽。节点的 fai1 是通过集群中超过半数的节点检测失败时才生效。客户端与 Redis 节点直连，不需要中间代理层。客户端也不需要连接集群所有节点，连接集群中任何一个可用节点即可，这样即减少了代理层，也大大提高了 Redis 集群性能。
Redis cluster 通过创建多个副本来保证数据的可靠性。每个分片都有一个主节点和多个从节点，主节点负责处理读写操作，而从节点则复制主节点的数据。当主节点发生故障时，从节点会自动切换为主节点，提供读写服务。这样可以确保即使发生节点故障，系统仍然能够继续提供服务，保证数据的高可用性。

集群模式简介

集群，即 Redis Cluster， 是Redis3.0开始引入的分布式存储方案。集群由多个节点(Node)组成，Redis 的数据分布在这些节点中。集群中的节点分为主节点和从节点:只有主节点负责读写请求和集群信息的维护;从节点只进行主节点数据和状态信息的复制。
redis 集群采用 master-slave 的方式，即1个master 节点可以包含多个 slave 节点，slave 节点主要对 master 节点的数据进行备份，也就 master 节点的备份，如果master 节点挂了，可以启动 salve节点替换掉原先的 master 节点，作为新的master 节点。redis 集群使用投票容错机制，如果集群中超过半数以上的节点投票认为某节点挂了，那么这个节点就会被认为挂掉了，所以，在设置 redis 集群时，最少的 master 节点为3个，如果每一个 master 节点都添加一个 slave 节点的话，搭建一个 redis 集群总共需要6个节点，即3个master节点，3个slave节点，
redis 集群没有统一的入口，客户端连接集群的时候，连接集群中的任意节点即可。
Redis 集群是一个由多个主从节点群组成的分布式服务集群,它具有复制、高可用和分片特性。Redis集群不需要 sentine1 哨兵也能完成节点移除和故障转移的功能，需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过 1000 个节点)。redis 集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单。redis 集群的运用主要是针对海量数据+高并发+高可用的场景。

数据分片方式

对象保存到 redis 之前先经过 CRC16哈希到一个指定的Node上，这个过程即redis cluster 的分片，集群内部将所有的 key 映射到 16384个 s1ot 中，集群中的每个 Redis Instance 负责其中的一部分的 slot 的读写。集群客户端连接集群中任一 Redis Instance 即可发送命令，当Redis Instance 收到自己不负责的s1ot 的请求时，会将负责请求 Key所在 slot 的 Redis Instance 地址返回给客户端，客户端收到后自动将原请求重新发往这个地址，对外部透明。一个Key 到底属于哪个Slot由(HASH_SLOT=CRC16(key)mod 16384)决定。只有master 节点会被分配槽位，slave节点不会分配位。
Redis Cluster 通过哈希算法将数据分散到多个节点上，实现数据的分片。每个节点负责管理一部分数据，并提供相应的读写操作。分片机制可以将数据均匀地分布在多个节点上，提高系统的并发处理能力。当某个节点发生故障时，只会影响该节点上的数据，而不会影响整个系统的可用性。
具体的分片方式有客户端分片、代理分片和Twemproxy 代理分片机制。

客户端分片

客户端分片方案是将分片工作放在业务程序端。程序代码根据预先设置的路由规则，直接对多个Redis 实例进行分布式访问。这样的好处是，群集不依赖于第三方分布式中间件，实现方法和代码都自己掌控，可随时调整，不用担心踩到坑。这实际上是一种静态分片技术，Redis 实例的增减，都得手工调整分片程序。基于此分片机制的开源产品，现在仍不多见。
这种分片机制的性能比代理式更好(少了一个中间分发环节)，但缺点是升级麻烦，对研发人员的个人依赖性强，需要有较强的程序开发能力做后盾。如果主力程序员离职，可能新的负责人会选择重写一遍。所以这种方式下可运维性较差，一旦出现故障，定位和解决都得研发人员和运维人员配合解决，故障时间变长。因此这种方案，难以进行标准化运维，不太适合中小公司。

代理分片

代理分片方案是将分片工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求，根据路由规则，将这些请求分发给正确的Redis实例并返回给业务程序。这种机制下，一般会达用第三方代理程序(面不是自己研发)。因为后有多个Redis实例，所以这类程序又称为分布式中间件。这种分片机制的好处是业务程序不用关心后端Red1s实例。推护起来也方便。虽然会因此带来些性损耗，但对于 Red1s这种内存读写型应用,相对面言是能容思的,这是比较推荐的集群实现方案。像 Twemproxy、Codss 发是基于该机制的开源产品的其中代表。应用非常广泛。
(1)Twemproxy 代理分片机制
Twemproxy 是一种代理分片机制，由Twitter 开源。Twemproxy 作为代理。可接受米自多个程片的访问，按照路由规则，转发给后台的各个Reds服务器。再原路返回。这个方案理成意地解决了单个Reds单实例问题。当然Twemproxy 本身也是单点，需要用Keepalivèd 做高可用方案。在很长的时问内，Twemproxy 是应用范围最广、稳定性最高、最久经考的分布式中间件。
这种分片方式无法平滑地扩容/缩容，增加了运维难度。当业务量突增需要增加Redis服务器或业务量装缩需爱减少 Red1s服务器时，Twemproxy 都无法平滑地进行扩密或容等操作。
并且Twemproxy 代理分片机制对运维操作不友好，甚至没有控制面板。由于使用了中间件代理，相比客户端直接连接服务器方式，性能上有所损耗，实测性能效果降低了2%左右。(2)Codis 代理分片机制
Codis 由豌豆英于2814年11月开源，基于 Go语言和 C 语言开发，是近期涌现的、国人开发的优秀开源软件之一，现已广泛用于院豆英的各种 Rodis业务场景。从各种压力测试来看，Codis的稳定性符合高效运维的要求。实测Codi5集群业务处理性能改善很多,最初集群处理数据性能要比Twemproxy差28%左右，现在比Twemproxy好很多。并且Codis具有可视化运维管理界面。因此综合方面会优于
Twemproxy 很多。目前越来越求的公司选择 Codis。Codis 引入了 Group 的概念，保个 Group 包括1个 Redis Master 及至少1个 Redisslave.这是和 Twomproxy 的区别之一。这样做的好处是，如果当前 Master 有问题，则运维人员可通过Dashboard“自助式”切换到 slave，面不需要小心翼翼地修改程序配置文件，为文持数器热迁移(Auto Rebalance)，出品方性改了 Redis Server 源码，非除之为 (odisserverCodis采用预先分片(Pre-sharding)机制，事先规定分成1024个slots(也就是说，最多能支持后端1824个Codis Server)，这些路出销息保存在z00keeper

服务器端分片

服务器满分片是 Redis官方的集群分片技术,Redis-cluster将所有Key映射到16384个 slot中，集群中每个 Redis实例负责一部分，业务程序是通过集成的edis-cluster 客户进行操作。客户端可以向任一实例发出销求，如果所需数据不在该实例中，则该实例引导客户端自动去对应实例读写数据。Redis-C1uster 成员之间的管理包括节点名称、IP、口、状态、角色等。都通过节点与之间商尚通讯，定鹏交换信息井更新
四:会载均衡的实民
客户编路由:在Redis C1uster中,客户演需委根据数据的键名选择正确的节点进行读写操作,RedisC1uster 使用哈希槽(hash slot)采划分数探。并将每个哈希槽映射到相应的节点上。客户端可以根探键名的哈看值，将请求发送到对应的节点上，实联负软均衡
自动迁移: Rediscluster具有自动迁移功能。当节点加入或离开集群时，系统会自动藏新分配数据，保持各个节点上哈希糟的均衡。当节点加入集群时，系统会将一部分哈希帽从其他节点迁移到新节点上:当节点离开处群时，系统会将该节点上的哈希植重新分配给其些节点。这种机制可以在节点数目变化
时，自动调整数狱的分布。实现会我均衡。
故障检测与恢复: Redis Cluster 具有故除检测和自动恢复的机制。集群中的节点会相互监控。枪测节点的健康状态。当某个节点被检测到不可用时，系统会自动将该节点标记为下线，并将该节点上的哈希槽或新分配给其他节点。当节点恢复正常时，系统会将其或新加入集群，并进行数据迁移，保特数据的一玫性。
Redis cluster 通过分片和副本机制实现了数狱的高可用性和贷载均衡。分片机制将数据均匀地分布在多个节点上，提高了系统的井发处理能力;副本机制则保迁了数据的可靠性，即使发生节点故障。也能够维续授供服务。同时，RedisCluster通过客户演路由、自动迁移和故障检测与恢复等机制，实现了负款均衡和故障自动转移。在实际废用中，合理设计和配置RedisCluster，可以提高系统的性能、可靠性和可扩展性。

故障的处理

故障转移

当从节点发现自己的主节点变为已下线(FAIL)状态时，便尝试进 Failover，以期成为新的主。以下是故障转移的执行步骤:
(1)从下线主节点的所有从节点中选中一个从节点
(2)被选中的从节点执行 SLAVEOF NO NOE 命令，成为新的主节点
(3)新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽全部指派给自己(4)新的主节点对集群进行广播 PONG消息，告知其他节点已经成为新的主节点
(5)新的主节点开始接收和处理槽相关的请求
(6)集群slots 是否必须完整才能对外提供服务

多slave选举

在多个 slave 情况下如果一个master 宕机，需要基于 Raft 协议选举方式来实现的新主的选举。步骤如下:
(1)当从节点发现自己的主节点进行已下线状态时，从节点会广播一条
CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST 消息，要求所有收到这条消息，并且具有投票权的主节点向这个从节点投票
(2)如果一个主节点具有投票权，并且这个主节点尚未投票给其他从节点，那么主节点将向要求投票的从节点返回一条，CLUSTERMSG TYPE_FAILOVER_AUTH_ACK 消息，表示这个主节点支持从节点成为新的主节点。
(3)每个参与选举的从节点都会接收CLUSTERMSG TYPE_FAILOVER AUTH ACK 消息,并根据自己收到了多少条这种消息来统计自己获得了多少主节点的支持。(4)如果集群里有N个具有投票权的主节点，那么当一个从节点收集到大于等于集群N/2+1 张支持票时，这个从节点就成为新的主节点。
(5)如果在一个选举周期没有从能够收集到足够的文持票数，那么集群进入一个新的选举周期，并再次进行选主，直到选出新的主节点为止。

redis群集部署

安装redis（每个节点都要安装）

[root@localhost ~]# systemctl stop firewalld[root@localhost ~]# setenforce 0
[root@localhost ~]# yum -y install gcc* zlib-devel[root@localhost ~]# tar xvzf redis-5.0.14.tar.gz[root@localhost ~]# cd redis-5.0.14/
[root@localhost redis-5.0.14]# make
[root@localhost redis-5.0.14]# make PREFlX=/usr/local/redis install

[root@localhost ~]#In -s /usr/local/redis/bin,* /usr/local/bin/

[root@localhost redis-5.0.14]# cd /root/redis-5.0.14/utils/

[root@localhost utils]f ./install server.sh

修改配置文件(每个节点都要配置，只有 IP 地址不同，其他都相同)

创建redis群集

redis-cli--clustercreate--cluster-replicas192.168.10.101:6379192.168.10.102:6379192.168.10.103:6379 192.168.10.104:6379192.168.10.105:6379
192.168.10.106:6379

测试群集

[root@localhost ~]# redis-cli -h 192.168.10.106-p 6379-c192.168.10.106:6379>set centos 7.3192.168.10.106:6379> get centos192.168.10.106:6379> quit
[root@localhost ~]# redis-cli -h 192.168.10.105 -p 6379 -c192.168.10.105:6379>get centos
192.168.10.105:6379> quit

群集信息查看

[root@localhost ~]# redis-cli192.168.10.106:6379>cluster nodes

添加节点

另一种方式：

修改新节点为其他节点的从节点

重新分配槽位

重新分片基本上意味着将 slot 重新分配，就像集群创建一样，它是使用 redis-cli 实用程序完成中
注意:平均分配所有的槽位，使用以下命令会自动降 16384 个槽位自动分配给集群的每一个 master,不用手动指定槽为分配。
redis-cli --clusterrebalance--cluster-threshold 1--cluster-use-empty-masters192.168.10.101:6379
只需要指定一个老的节点(10.21.108.174:3001)，redis 会自动查找其他节点。

删除节点

注意:
如果删除的 slave 节点，直接删除即可，如果删除的是 master 节点，需要先清除槽信息再删除。