Redis高可用技术解决方案

最新推荐文章于 2024-07-31 16:54:22 发布

jerry-89

最新推荐文章于 2024-07-31 16:54:22 发布

阅读量751

点赞数

分类专栏： redis

本文链接：https://blog.csdn.net/eagle89/article/details/108602817

版权

redis 专栏收录该内容

22 篇文章 0 订阅

订阅专栏

Redis 的几种常见使用方式包括：

Redis 单副本
Redis 多副本（主从）
Redis Sentinel（哨兵）
Redis Cluster
Redis 自研
客户端分片
Twemproxy
Codis
云服务器上的集群服务

关于redis的集群化方案目前有三种

（1）Twitter开发的twemproxy

（2）豌豆荚开发的codis

（3）redis官方的redis-cluster

注：redis-cluster-proxy （REDIS6版本）非常强大

简介：twemproxy架构简单就是用proxy对后端redis server进行代理但是由于代理层的消耗性能很低而且通常涉及多个key的操作都是不支持的而且本身不支持动态扩容和透明的数据迁移而且也失去维护 Twitter内部已经不使用了

redis-cluster是三个里性能最强大的因为他使用去中心化的思想使用hash slot方式将16348个hash slot 覆盖到所有节点上对于存储的每个key值使用CRC16(KEY)&16348=slot 得到他对应的hash slot 并在访问key时就去找他的hash slot在哪一个节点上然后由当前访问节点从实际被分配了这个hash slot的节点去取数据节点之间使用轻量协议通信减少带宽占用性能很高自动实现负载均衡与高可用自动实现failover 并且支持动态扩展官方已经玩到可以1000个节点实现的复杂度低总之个人比较喜欢这个架构因为他的去中心化思想免去了proxy的消耗是全新的思路

但是它也有一些不足例如官方没有提供图形化管理工具运维体验差全手工数据迁移并且自己对自己本身的redis命令支持也不完全等但是这些问题我觉得不能掩盖他关键的新思想所带来的的优势随着官方的推进这些问题应该都能在一定时间内得到解决那么这时候去中心化思想带来的高性能就会表现出他巨大的优势

codis使用的也是proxy思路但是做的比较好是这两种之间的一个中间级而且支持redis命令是最多的有图形化GUI管理和监控工具运维友好这个过段时间会详细另外写出来原理工作机制和搭建实现

各种使用方式的优缺点

Redis 单副本

Redis 单副本，采用单个 Redis 节点部署架构，没有备用节点实时同步数据，不提供数据持久化和备份策略，适用于数据可靠性要求不高的纯缓存业务场景。

优点：

架构简单，部署方便。
高性价比：缓存使用时无需备用节点（单实例可用性可以用 supervisor 或 crontab 保证），当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务。
高性能。

缺点：

不保证数据的可靠性。
在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务。
高性能受限于单核 CPU 的处理能力（Redis 是单线程机制），CPU 为主要瓶颈，所以适合操作命令简单，排序、计算较少的场景。也可以考虑用 Memcached 替代。

Redis 多副本（主从）

Redis 多副本，采用主从（replication）部署结构，相较于单副本而言最大的特点就是主从实例间数据实时同步，并且提供数据持久化和备份策略。

主从实例部署在不同的物理服务器上，根据公司的基础环境配置，可以实现同时对外提供服务和读写分离策略。

优点：

高可靠性：一方面，采用双机主备架构，能够在主库出现故障时自动进行主备切换，从库提升为主库提供服务，保证服务平稳运行；另一方面，开启数据持久化功能和配置合理的备份策略，能有效的解决数据误操作和数据异常丢失的问题。
读写分离策略：从节点可以扩展主库节点的读能力，有效应对大并发量的读操作。

缺点：

故障恢复复杂，如果没有 Redis HA 系统（需要开发），当主库节点出现故障时，需要手动将一个从节点晋升为主节点，同时需要通知业务方变更配置，并且需要让其他从库节点去复制新主库节点，整个过程需要人为干预，比较繁琐。
主库的写能力受到单机的限制，可以考虑分片。
主库的存储能力受到单机的限制，可以考虑 Pika。
原生复制的弊端在早期的版本中也会比较突出，如：Redis 复制中断后，Slave 会发起 psync，此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时可能会造成毫秒或秒级的卡顿。

又由于 COW 机制，导致极端情况下的主库内存溢出，程序异常退出或宕机；主库节点生成备份文件导致服务器磁盘 IO 和 CPU（压缩）资源消耗；发送数 GB 大小的备份文件导致服务器出口带宽暴增，阻塞请求，建议升级到最新版本。

Redis Sentinel（哨兵）

Redis Sentinel 是社区版本推出的原生高可用解决方案，其部署架构主要包括两部分：Redis Sentinel 集群和 Redis 数据集群。

其中 Redis Sentinel 集群是由若干 Sentinel 节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel 的节点数量要满足 2n+1（n>=1）的奇数个。

优点：

Redis Sentinel 集群部署简单；
能够解决 Redis 主从模式下的高可用切换问题；
很方便实现 Redis 数据节点的线形扩展，轻松突破 Redis 自身单线程瓶颈，可极大满足 Redis 大容量或高性能的业务需求；
可以实现一套 Sentinel 监控一组 Redis 数据节点或多组数据节点。

缺点：

部署相对 Redis 主从模式要复杂一些，原理理解更繁琐；
资源浪费，Redis 数据节点中 slave 节点作为备份节点不提供服务；
Redis Sentinel 主要是针对 Redis 数据节点中的主节点的高可用切换，对 Redis 的数据节点做失败判定分为主观下线和客观下线两种，对于 Redis 的从节点有对节点做主观下线操作，并不执行故障转移。
不能解决读写分离问题，实现起来相对复杂。

建议：

如果监控同一业务，可以选择一套 Sentinel 集群监控多组 Redis 数据节点的方案，反之选择一套 Sentinel 监控一组 Redis 数据节点的方案。
sentinel monitor <master-name> <ip> <port> <quorum> 配置中的<quorum>建议设置成 Sentinel 节点的一半加 1，当 Sentinel 部署在多个 IDC 的时候，单个 IDC 部署的 Sentinel 数量不建议超过（Sentinel 数量 – quorum）。
合理设置参数，防止误切，控制切换灵敏度控制：

a. quorum

b. down-after-milliseconds 30000

c. failover-timeout 180000

d. maxclient

e. timeout
部署的各个节点服务器时间尽量要同步，否则日志的时序性会混乱。
Redis 建议使用 pipeline 和 multi-keys 操作，减少 RTT 次数，提高请求效率。
自行搞定配置中心（zookeeper），方便客户端对实例的链接访问。

Redis Cluster

Redis Cluster 是社区版推出的 Redis 分布式集群解决方案，主要解决 Redis 分布式方面的需求，比如，当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster 能起到很好的负载均衡的目的。

Redis Cluster 集群节点最小配置 6 个节点以上（3 主 3 从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。

Redis Cluster 采用虚拟槽分区，所有的键根据哈希函数映射到 0～16383 个整数槽内，每个节点负责维护一部分槽以及槽所映射的键值数据。

优点：

无中心架构；
数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布；
可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除；
高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升；
降低运维成本，提高系统的扩展性和可用性。

缺点：

Client 实现复杂，驱动要求实现 Smart Client，缓存 slots mapping 信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅 JedisCluster 相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。
节点会因为某些原因发生阻塞（阻塞时间大于 clutser-node-timeout），被判断下线，这种 failover 是没有必要的。
数据通过异步复制，不保证数据的强一致性。
多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况。
Slave 在集群中充当“冷备”，不能缓解读压力，当然可以通过 SDK 的合理设计来提高 Slave 资源的利用率。
Key 批量操作限制，如使用 mset、mget 目前只支持具有相同 slot 值的 Key 执行批量操作。对于映射为不同 slot 值的 Key 由于 Keys 不支持跨 slot 查询，所以执行 mset、mget、sunion 等操作支持不友好。
Key 事务操作支持有限，只支持多 key 在同一节点上的事务操作，当多个 Key 分布于不同的节点上时无法使用事务功能。
Key 作为数据分区的最小粒度，不能将一个很大的键值对象如 hash、list 等映射到不同的节点。
不支持多数据库空间，单机下的 redis 可以支持到 16 个数据库，集群模式下只能使用 1 个数据库空间，即db 0 。
复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。
避免产生 hot-key，导致主库节点成为系统的短板。
避免产生 big-key，导致网卡撑爆、慢查询等。
重试时间应该大于 cluster-node-time 时间。
Redis Cluster 不建议使用 pipeline和multi-keys 操作，减少 max redirect 产生的场景。

Redis 自研

Redis 自研的高可用解决方案，主要体现在配置中心、故障探测和 failover 的处理机制上，通常需要根据企业业务的实际线上环境来定制化。

优点：

高可靠性、高可用性；
自主可控性高；
贴合业务实际需求，可缩性好，兼容性好。

缺点：

实现复杂，开发成本高；
需要建立配套的周边设施，如监控，域名服务，存储元数据信息的数据库等；
维护成本高。

　1.客户端分片

　　客户端分片是把分片的逻辑放在Redis客户端实现，通过Redis客户端预先定义好的路由规则，把对Key的访问转发到不同的Redis实例中，最后把返回结果汇集。这种方案的模式如图1所示。

图1 客户端分片的模式

　　客户端分片的好处是所有的逻辑都是可控的，不依赖于第三方分布式中间件。开发人员清楚怎么实现分片、路由的规则，不用担心踩坑。

　　客户端分片方案有下面这些缺点。

这是一种静态的分片方案，需要增加或者减少Redis实例的数量，需要手工调整分片的程序。
可运维性差，集群的数据出了任何问题都需要运维人员和开发人员一起合作，减缓了解决问题的速度，增加了跨部门沟通的成本。
在不同的客户端程序中，维护相同的分片逻辑成本巨大。例如，系统中有两套业务系统共用一套Redis集群，一套业务系统用Java实现，另一套业务系统用PHP实现。为了保证分片逻辑的一致性，在Java客户端中实现的分片逻辑也需要在PHP客户端实现一次。相同的逻辑在不同的系统中分别实现，这种设计本来就非常糟糕，而且需要耗费巨大的开发成本保证两套业务系统分片逻辑的一致性。

　　2.Twemproxy

　　Twemproxy是由Twitter开源的Redis代理，其基本原理是：Redis客户端把请求发送到Twemproxy，Twemproxy根据路由规则发送到正确的Redis实例，最后Twemproxy把结果汇集返回给客户端。

　　Twemproxy通过引入一个代理层，将多个Redis实例进行统一管理，使Redis客户端只需要在Twemproxy上进行操作，而不需要关心后面有多少个Redis实例，从而实现了Redis集群。

　　Twemproxy集群架构如图2所示。

图2Twemproxy集群架构

　　Twemproxy的优点如下。

客户端像连接Redis实例一样连接Twemproxy，不需要改任何的代码逻辑。
支持无效Redis实例的自动删除。
Twemproxy与Redis实例保持连接，减少了客户端与Redis实例的连接数。

　　Twemproxy有如下不足。

由于Redis客户端的每个请求都经过Twemproxy代理才能到达Redis服务器，这个过程中会产生性能损失。
没有友好的监控管理后台界面，不利于运维监控。
最大的问题是Twemproxy无法平滑地增加Redis实例。对于运维人员来说，当因为业务需要增加Redis实例时工作量非常大。

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

　　3.Codis

　　Twemproxy不能平滑增加Redis实例的问题带来了很大的不便，于是豌豆荚自主研发了Codis，一个支持平滑增加Redis实例的Redis代理软件，其基于Go和C语言开发，并于2014年11月在GitHub上开源。

　　Codis包含下面4个部分。

Codis Proxy：Redis客户端连接到Redis实例的代理，实现了Redis的协议，Redis客户端连接到Codis Proxy进行各种操作。Codis Proxy是无状态的，可以用Keepalived等负载均衡软件部署多个Codis Proxy实现高可用。
CodisRedis：Codis项目维护的Redis分支，添加了slot和原子的数据迁移命令。Codis上层的 Codis Proxy和Codisconfig只有与这个版本的Redis通信才能正常运行。
Codisconfig：Codis管理工具。可以执行添加删除CodisRedis节点、添加删除Codis Proxy、数据迁移等操作。另外，Codisconfig自带了HTTP server，里面集成了一个管理界面，方便运维人员观察Codis集群的状态和进行相关的操作，极大提高了运维的方便性，弥补了Twemproxy的缺点。
ZooKeeper：分布式的、开源的应用程序协调服务，是Hadoop和Hbase的重要组件，其为分布式应用提供一致性服务，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。Codis依赖于ZooKeeper存储数据路由表的信息和Codis Proxy节点的元信息。另外，Codisconfig发起的命令都会通过ZooKeeper同步到CodisProxy的节点。

　　Codis的架构如图3所示。

图3Codis的架构图

　　在图3的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
1	1~500
2	501~1024

　　当增加了一个Redis Server Group，slot就要重新分配了。Codis分配slot有两种方法。

　　第一种：通过Codis管理工具Codisconfig手动重新分配，指定每个Redis Server Group所对应的slot的范围，例如可以指定Redis Server Group和slot的新的对应关系如下。

Redis Server Group	slot
1	1~500
2	501~700
3	701~1024

　　第二种：通过Codis管理工具Codisconfig的rebalance功能，会自动根据每个Redis Server Group的内存对slot进行迁移，以实现数据的均衡。

　　4.Redis 3.0集群

　　Redis 3.0集群采用了P2P的模式，完全去中心化。Redis把所有的Key分成了16384个slot，每个Redis实例负责其中一部分slot。集群中的所有信息（节点、端口、slot等），都通过节点之间定期的数据交换而更新。

　　Redis客户端在任意一个Redis实例发出请求，如果所需数据不在该实例中，通过重定向命令引导客户端访问所需的实例。

　　Redis 3.0集群的工作流程如图4所示。

图4Redis 3.0集群的工作流程图

　　如图4所示Redis集群内的机器定期交换数据，工作流程如下。

　　（1） Redis客户端在Redis2实例上访问某个数据。

　　（2）在Redis2内发现这个数据是在Redis3这个实例中，给Redis客户端发送一个重定向的命令。

　　（3） Redis客户端收到重定向命令后，访问Redis3实例获取所需的数据。

　　Redis 3.0的集群方案有以下两个问题。

一个Redis实例具备了“数据存储”和“路由重定向”，完全去中心化的设计。这带来的好处是部署非常简单，直接部署Redis就行，不像Codis有那么多的组件和依赖。但带来的问题是很难对业务进行无痛的升级，如果哪天Redis集群出了什么严重的Bug，就只能回滚整个Redis集群。
对协议进行了较大的修改，对应的Redis客户端也需要升级。升级Redis客户端后谁能确保没有Bug？而且对于线上已经大规模运行的业务，升级代码中的Redis客户端也是一个很麻烦的事情。

　　综合上面所述的两个问题，Redis 3.0集群在业界并没有被大规模使用。

　　5.云服务器上的集群服务

　　国内的云服务器提供商阿里云、UCloud等均推出了基于Redis的云存储服务。

　　这个服务的特性如下。

　　（1）动态扩容

　　用户可以通过控制面板升级所需的Redis存储空间，扩容的过程中服务部不需要中断或停止，整个扩容过程对用户透明、无感知，这点是非常实用的，在前面介绍的方案中，解决Redis平滑扩容是个很烦琐的任务，现在按几下鼠标就能搞定，大大减少了运维的负担。

　　（2）数据多备

　　数据保存在一主一备两台机器中，其中一台机器宕机了，数据还在另外一台机器上有备份。

　　（3）自动容灾

　　主机宕机后系统能自动检测并切换到备机上，实现服务的高可用。

　　（4）实惠

　　很多情况下为了使Redis的性能更高，需要购买一台专门的服务器用于Redis的存储服务，但这样子CPU、内存等资源就浪费了，购买Redis云存储服务就很好地解决了这个问题。