redis高可用_redis高可用性 - CSDN
精华内容
参与话题
  • Redis高可用方案对比

    千次阅读 2018-11-05 23:08:41
    Redis的几种常见使用方式包括: Redis 单副本 Redis 多副本(主从) Redis Sentinel(哨兵) Redis Cluster Redis 自研 一. Redis 单副本 Redis单副本,采用单个Redis节点部署架构,没有备用节点实时同步数据,...

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

    1. Redis 单副本
    2. Redis 多副本(主从)
    3. Redis Sentinel(哨兵)
    4. Redis Cluster
    5. Redis 自研

    一. Redis 单副本

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

    优点:

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

    缺点:

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

    二. Redis多副本( 主从 )

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

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

    优点:

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

    缺点:

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

    三. 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 的角色提升;
    • 降低运维成本,提高系统的扩展性和可用性

    缺点:

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

    五. Redis 自研

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

    优点:

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

    缺点:

    • 实现复杂,开发成本高;
    • 需要建立配套的周边设施,如监控,域名服务,存储元数据信息的数据库等;
    • 维护成本高。
    展开全文
  • redis高可用,保证并发

    万次阅读 2018-11-22 18:17:46
    目录 redis如何通过读写分离来承载读请求QPS超过10万+ redis replication以及master持久化对主从架构的安全... redis主从架构下如何才能做到99.99%的高可用性?  redis哨兵架构的相关基础知识的讲解1、哨兵的...

    目录

    redis如何通过读写分离来承载读请求QPS超过10万+

    redis replication以及master持久化对主从架构的安全意义

     redis主从复制原理、断点续传、无磁盘化复制、过期key处理

    redis replication的完整流运行程和原理的再次深入剖析

     redis主从架构下如何才能做到99.99%的高可用性?

     redis哨兵架构的相关基础知识的讲解1、哨兵的介绍

     redis哨兵主备切换的数据丢失问题:异步复制、集群脑裂

     怎么保证redis是高并发以及高可用的?\09_redis哨兵的多个核心底层原理的深入解析(包含slave选举算法)


     

    就是如果你用redis缓存技术的话,肯定要考虑如何用redis来加多台机器,保证redis是高并发的,还有就是如何让Redis保证自己不是挂掉以后就直接死掉了,redis高可用

     

    我这里会选用我之前讲解过这一块内容,redis高并发、高可用、缓存一致性

     

    redis高并发:主从架构,一主多从,一般来说,很多项目其实就足够了,单主用来写入数据,单机几万QPS,多从用来查询数据,多个从实例可以提供每秒10万的QPS。

    redis高并发的同时,还需要容纳大量的数据:一主多从,每个实例都容纳了完整的数据,比如redis主就10G的内存量,其实你就最对只能容纳10g的数据量。如果你的缓存要容纳的数据量很大,达到了几十g,甚至几百g,或者是几t,那你就需要redis集群,而且用redis集群之后,可以提供可能每秒几十万的读写并发。

     

    redis高可用:如果你做主从架构部署,其实就是加上哨兵就可以了,就可以实现,任何一个实例宕机,自动会进行主备切换。

     

     

    redis如何通过读写分离来承载读请求QPS超过10万+

     


    1、redis高并发跟整个系统的高并发之间的关系

    redis,你要搞高并发的话,不可避免,要把底层的缓存搞得很好

    mysql,高并发,做到了,那么也是通过一系列复杂的分库分表,订单系统,事务要求的,QPS到几万,比较高了

    要做一些电商的商品详情页,真正的超高并发,QPS上十万,甚至是百万,一秒钟百万的请求量

    光是redis是不够的,但是redis是整个大型的缓存架构中,支撑高并发的架构里面,非常重要的一个环节

    首先,你的底层的缓存中间件,缓存系统,必须能够支撑的起我们说的那种高并发,其次,再经过良好的整体的缓存架构的设计(多级缓存架构、热点缓存),支撑真正的上十万,甚至上百万的高并发

    2、redis不能支撑高并发的瓶颈在哪里?

    单机

    3、如果redis要支撑超过10万+的并发,那应该怎么做?

    单机的redis几乎不太可能说QPS超过10万+,除非一些特殊情况,比如你的机器性能特别好,配置特别高,物理机,维护做的特别好,而且你的整体的操作不是太复杂

    单机在几万

    读写分离,一般来说,对缓存,一般都是用来支撑读高并发的,写的请求是比较少的,可能写请求也就一秒钟几千,一两千

    大量的请求都是读,一秒钟二十万次读

    读写分离

    主从架构 -> 读写分离 -> 支撑10万+读QPS的架构

    4、接下来要讲解的一个topic

    redis replication

    redis主从架构 -> 读写分离架构 -> 可支持水平扩展的读高并发架构
     

    redis replication以及master持久化对主从架构的安全意义

    课程大纲

    1、图解redis replication基本原理
    2、redis replication的核心机制
    3、master持久化对于主从架构的安全保障的意义

    redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发

    redis replication的最最基本的原理,铺垫

    ------------------------------------------------------------------------

    1、图解redis replication基本原理

    ------------------------------------------------------------------------

    2、redis replication的核心机制

    (1)redis采用异步方式复制数据到slave节点,不过redis 2.8开始,slave node会周期性地确认自己每次复制的数据量
    (2)一个master node是可以配置多个slave node的
    (3)slave node也可以连接其他的slave node
    (4)slave node做复制的时候,是不会block master node的正常工作的
    (5)slave node在做复制的时候,也不会block对自己的查询操作,它会用旧的数据集来提供服务; 但是复制完成的时候,需要删除旧数据集,加载新数据集,这个时候就会暂停对外服务了
    (6)slave node主要用来进行横向扩容,做读写分离,扩容的slave node可以提高读的吞吐量

    slave,高可用性,有很大的关系

    ------------------------------------------------------------------------

    3、master持久化对于主从架构的安全保障的意义

    如果采用了主从架构,那么建议必须开启master node的持久化!
    a
    不建议用slave node作为master node的数据热备,因为那样的话,如果你关掉master的持久化,可能在master宕机重启的时候数据是空的,然后可能一经过复制,salve node数据也丢了

    master -> RDB和AOF都关闭了 -> 全部在内存中

    master宕机,重启,是没有本地数据可以恢复的,然后就会直接认为自己IDE数据是空的

    master就会将空的数据集同步到slave上去,所有slave的数据全部清空

    100%的数据丢失

    master节点,必须要使用持久化机制

    第二个,master的各种备份方案,要不要做,万一说本地的所有文件丢失了; 从备份中挑选一份rdb去恢复master; 这样才能确保master启动的时候,是有数据的

    即使采用了后续讲解的高可用机制,slave node可以自动接管master node,但是也可能sentinal还没有检测到master failure,master node就自动重启了,还是可能导致上面的所有slave node数据清空故障
     

     redis主从复制原理、断点续传、无磁盘化复制、过期key处理

     

     

     

     

    1、主从架构的核心原理

    当启动一个slave node的时候,它会发送一个PSYNC命令给master node

    如果这是slave node重新连接master node,那么master node仅仅会复制给slave部分缺少的数据; 否则如果是slave node第一次连接master node,那么会触发一次full resynchronization

    开始full resynchronization的时候,master会启动一个后台线程,开始生成一份RDB快照文件,同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后,master会将这个RDB发送给slave,slave会先写入本地磁盘,然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave,slave也会同步这些数据。

    slave node如果跟master node有网络故障,断开了连接,会自动重连。master如果发现有多个slave node都来重新连接,仅仅会启动一个rdb save操作,用一份数据服务所有slave node。

    2、主从复制的断点续传

    从redis 2.8开始,就支持主从复制的断点续传,如果主从复制过程中,网络连接断掉了,那么可以接着上次复制的地方,继续复制下去,而不是从头开始复制一份

     

     

    master node会在内存中常见一个backlog,master和slave都会保存一个replica offset还有一个master id,offset就是保存在backlog中的。如果master和slave网络连接断掉了,slave会让master从上次的replica offset开始继续复制

    但是如果没有找到对应的offset,那么就会执行一次resynchronization

    3、无磁盘化复制

    master在内存中直接创建rdb,然后发送给slave,不会在自己本地落地磁盘了

    repl-diskless-sync
    repl-diskless-sync-delay,等待一定时长再开始复制,因为要等更多slave重新连接过来

    4、过期key处理

    slave不会过期key,只会等待master过期key。如果master过期了一个key,或者通过LRU淘汰了一个key,那么会模拟一条del命令发送给slave。
     

    redis replication的完整流运行程和原理的再次深入剖析

     

     

     


    1、复制的完整流程

    (1)slave node启动,仅仅保存master node的信息,包括master node的host和ip,但是复制流程没开始

    master host和ip是从哪儿来的,redis.conf里面的slaveof配置的

    (2)slave node内部有个定时任务,每秒检查是否有新的master node要连接和复制,如果发现,就跟master node建立socket网络连接
    (3)slave node发送ping命令给master node
    (4)口令认证,如果master设置了requirepass,那么salve node必须发送masterauth的口令过去进行认证
    (5)master node第一次执行全量复制,将所有数据发给slave node
    (6)master node后续持续将写命令,异步复制给slave node

    2、数据同步相关的核心机制

    指的就是第一次slave连接msater的时候,执行的全量复制,那个过程里面你的一些细节的机制

    (1)master和slave都会维护一个offset

    master会在自身不断累加offset,slave也会在自身不断累加offset
    slave每秒都会上报自己的offset给master,同时master也会保存每个slave的offset

    这个倒不是说特定就用在全量复制的,主要是master和slave都要知道各自的数据的offset,才能知道互相之间的数据不一致的情况

    (2)backlog

    master node有一个backlog,默认是1MB大小
    master node给slave node复制数据时,也会将数据在backlog中同步写一份
    backlog主要是用来做全量复制中断候的增量复制的

    (3)master run id

    info server,可以看到master run id
    如果根据host+ip定位master node,是不靠谱的,如果master node重启或者数据出现了变化,那么slave node应该根据不同的run id区分,run id不同就做全量复制
    如果需要不更改run id重启redis,可以使用redis-cli debug reload命令

    (4)psync

    从节点使用psync从master node进行复制,psync runid offset
    master node会根据自身的情况返回响应信息,可能是FULLRESYNC runid offset触发全量复制,可能是CONTINUE触发增量复制

    3、全量复制

    (1)master执行bgsave,在本地生成一份rdb快照文件
    (2)master node将rdb快照文件发送给salve node,如果rdb复制时间超过60秒(repl-timeout),那么slave node就会认为复制失败,可以适当调节大这个参数
    (3)对于千兆网卡的机器,一般每秒传输100MB,6G文件,很可能超过60s
    (4)master node在生成rdb时,会将所有新的写命令缓存在内存中,在salve node保存了rdb之后,再将新的写命令复制给salve node
    (5)client-output-buffer-limit slave 256MB 64MB 60,如果在复制期间,内存缓冲区持续消耗超过64MB,或者一次性超过256MB,那么停止复制,复制失败
    (6)slave node接收到rdb之后,清空自己的旧数据,然后重新加载rdb到自己的内存中,同时基于旧的数据版本对外提供服务
    (7)如果slave node开启了AOF,那么会立即执行BGREWRITEAOF,重写AOF

    rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave aof rewrite,很耗费时间

    如果复制的数据量在4G~6G之间,那么很可能全量复制时间消耗到1分半到2分钟

    4、增量复制

    (1)如果全量复制过程中,master-slave网络连接断掉,那么salve重新连接master时,会触发增量复制
    (2)master直接从自己的backlog中获取部分丢失的数据,发送给slave node,默认backlog就是1MB
    (3)msater就是根据slave发送的psync中的offset来从backlog中获取数据的

    5、heartbeat

    主从节点互相都会发送heartbeat信息

    master默认每隔10秒发送一次heartbeat,salve node每隔1秒发送一个heartbeat

    6、异步复制

    master每次接收到写命令之后,现在内部写入数据,然后异步发送给slave node
     

     

     redis主从架构下如何才能做到99.99%的高可用性?

     


    1、什么是99.99%高可用?

    架构上,高可用性,99.99%的高可用性

    讲的学术,99.99%,公式,系统可用的时间 / 系统故障的时间,365天,在365天 * 99.99%的时间内,你的系统都是可以哗哗对外提供服务的,那就是高可用性,99.99%

    系统可用的时间 / 总的时间 = 高可用性,然后会对各种时间的概念,说一大堆解释

     

    2、redis不可用是什么?单实例不可用?主从架构不可用?不可用的后果是什么?

    3、redis怎么才能做到高可用?

     

    高可用是什么

     

     redis哨兵架构的相关基础知识的讲解

    哨兵集群

    https://www.cnblogs.com/jaycekon/p/6237562.html
    1、哨兵的介绍

    sentinal,中文名是哨兵

    哨兵是redis集群架构中非常重要的一个组件,主要功能如下

    (1)集群监控,负责监控redis master和slave进程是否正常工作
    (2)消息通知,如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员
    (3)故障转移,如果master node挂掉了,会自动转移到slave node上
    (4)配置中心,如果故障转移发生了,通知client客户端新的master地址

    哨兵本身也是分布式的,作为一个哨兵集群去运行,互相协同工作

    (1)故障转移时,判断一个master node是宕机了,需要大部分的哨兵都同意才行,涉及到了分布式选举的问题
    (2)即使部分哨兵节点挂掉了,哨兵集群还是能正常工作的,因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的,那就很坑爹了

    目前采用的是sentinal 2版本,sentinal 2相对于sentinal 1来说,重写了很多代码,主要是让故障转移的机制和算法变得更加健壮和简单

    2、哨兵的核心知识

    (1)哨兵至少需要3个实例,来保证自己的健壮性
    (2)哨兵 + redis主从的部署架构,是不会保证数据零丢失的,只能保证redis集群的高可用性
    (3)对于哨兵 + redis主从这种复杂的部署架构,尽量在测试环境和生产环境,都进行充足的测试和演练

    3、为什么redis哨兵集群只有2个节点无法正常工作?

    哨兵集群必须部署2个以上节点

    如果哨兵集群仅仅部署了个2个哨兵实例,quorum=1

    +----+         +----+
    | M1 |---------| R1 |
    | S1 |         | S2 |
    +----+         +----+

    Configuration: quorum = 1

    master宕机,s1和s2中只要有1个哨兵认为master宕机就可以还行切换,同时s1和s2中会选举出一个哨兵来执行故障转移

    同时这个时候,需要majority,也就是大多数哨兵都是运行的,2个哨兵的majority就是2(2的majority=2,3的majority=2,5的majority=3,4的majority=2),2个哨兵都运行着,就可以允许执行故障转移

    但是如果整个M1和S1运行的机器宕机了,那么哨兵只有1个了,此时就没有majority来允许执行故障转移,虽然另外一台机器还有一个R1,但是故障转移不会执行

    4、经典的3节点哨兵集群

           +----+
           | M1 |
           | S1 |
           +----+
              |
    +----+    |    +----+
    | R2 |----+----| R3 |
    | S2 |         | S3 |
    +----+         +----+

    Configuration: quorum = 2,majority

    如果M1所在机器宕机了,那么三个哨兵还剩下2个,S2和S3可以一致认为master宕机,然后选举出一个来执行故障转移

    同时3个哨兵的majority是2,所以还剩下的2个哨兵运行着,就可以允许执行故障转移

     

     

     redis哨兵主备切换的数据丢失问题:异步复制、集群脑裂

    1、两种数据丢失的情况
    2、解决异步复制和脑裂导致的数据丢失

    ------------------------------------------------------------------

    1、两种数据丢失的情况

    主备切换的过程,可能会导致数据丢失

    (1)异步复制导致的数据丢失

    因为master -> slave的复制是异步的,所以可能有部分数据还没复制到slave,master就宕机了,此时这些部分数据就丢失了

    (2)脑裂导致的数据丢失

    脑裂,也就是说,某个master所在机器突然脱离了正常的网络,跟其他slave机器不能连接,但是实际上master还运行着

    此时哨兵可能就会认为master宕机了,然后开启选举,将其他slave切换成了master

    这个时候,集群里就会有两个master,也就是所谓的脑裂

    此时虽然某个slave被切换成了master,但是可能client还没来得及切换到新的master,还继续写向旧master的数据可能也丢失了

    因此旧master再次恢复的时候,会被作为一个slave挂到新的master上去,自己的数据会清空,重新从新的master复制数据

    ------------------------------------------------------------------

    2、解决异步复制和脑裂导致的数据丢失

    min-slaves-to-write 1
    min-slaves-max-lag 10

    要求至少有1个slave,数据复制和同步的延迟不能超过10秒

    如果说一旦所有的slave,数据复制和同步的延迟都超过了10秒钟,那么这个时候,master就不会再接收任何请求了

    上面两个配置可以减少异步复制和脑裂导致的数据丢失

    (1)减少异步复制的数据丢失

    有了min-slaves-max-lag这个配置,就可以确保说,一旦slave复制数据和ack延时太长,就认为可能master宕机后损失的数据太多了,那么就拒绝写请求,这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内

    (2)减少脑裂的数据丢失

    如果一个master出现了脑裂,跟其他slave丢了连接,那么上面两个配置可以确保说,如果不能继续给指定数量的slave发送数据,而且slave超过10秒没有给自己ack消息,那么就直接拒绝客户端的写请求

    这样脑裂后的旧master就不会接受client的新数据,也就避免了数据丢失

    上面的配置就确保了,如果跟任何一个slave丢了连接,在10秒后发现没有slave给自己ack,那么就拒绝新的写请求

    因此在脑裂场景下,最多就丢失10秒的数据

     

     

     怎么保证redis是高并发以及高可用的?\09_redis哨兵的多个核心底层原理的深入解析(包含slave选举算法)


    1、sdown和odown转换机制

    sdown和odown两种失败状态

    sdown是主观宕机,就一个哨兵如果自己觉得一个master宕机了,那么就是主观宕机

    odown是客观宕机,如果quorum数量的哨兵都觉得一个master宕机了,那么就是客观宕机

    sdown达成的条件很简单,如果一个哨兵ping一个master,超过了is-master-down-after-milliseconds指定的毫秒数之后,就主观认为master宕机

    sdown到odown转换的条件很简单,如果一个哨兵在指定时间内,收到了quorum指定数量的其他哨兵也认为那个master是sdown了,那么就认为是odown了,客观认为master宕机

    2、哨兵集群的自动发现机制

    哨兵互相之间的发现,是通过redis的pub/sub系统实现的,每个哨兵都会往__sentinel__:hello这个channel里发送一个消息,这时候所有其他哨兵都可以消费到这个消息,并感知到其他的哨兵的存在

    每隔两秒钟,每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息,内容是自己的host、ip和runid还有对这个master的监控配置

    每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel,然后去感知到同样在监听这个master+slaves的其他哨兵的存在

    每个哨兵还会跟其他哨兵交换对master的监控配置,互相进行监控配置的同步

    3、slave配置的自动纠正

    哨兵会负责自动纠正slave的一些配置,比如slave如果要成为潜在的master候选人,哨兵会确保slave在复制现有master的数据; 如果slave连接到了一个错误的master上,比如故障转移之后,那么哨兵会确保它们连接到正确的master上

    4、slave->master选举算法

    如果一个master被认为odown了,而且majority哨兵都允许了主备切换,那么某个哨兵就会执行主备切换操作,此时首先要选举一个slave来

    会考虑slave的一些信息

    (1)跟master断开连接的时长
    (2)slave优先级
    (3)复制offset
    (4)run id

    如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍,外加master宕机的时长,那么slave就被认为不适合选举为master

    (down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

    接下来会对slave进行排序

    (1)按照slave优先级进行排序,slave priority越低,优先级就越高
    (2)如果slave priority相同,那么看replica offset,哪个slave复制了越多的数据,offset越靠后,优先级就越高
    (3)如果上面两个条件都相同,那么选择一个run id比较小的那个slave

    5、quorum和majority

    每次一个哨兵要做主备切换,首先需要quorum数量的哨兵认为odown,然后选举出一个哨兵来做切换,这个哨兵还得得到majority哨兵的授权,才能正式执行切换

    如果quorum < majority,比如5个哨兵,majority就是3,quorum设置为2,那么就3个哨兵授权就可以执行切换

    但是如果quorum >= majority,那么必须quorum数量的哨兵都授权,比如5个哨兵,quorum是5,那么必须5个哨兵都同意授权,才能执行切换

    6、configuration epoch

    哨兵会对一套redis master+slave进行监控,有相应的监控的配置

    执行切换的那个哨兵,会从要切换到的新master(salve->master)那里得到一个configuration epoch,这就是一个version号,每次切换的version号都必须是唯一的

    如果第一个选举出的哨兵切换失败了,那么其他哨兵,会等待failover-timeout时间,然后接替继续执行切换,此时会重新获取一个新的configuration epoch,作为新的version号

    7、configuraiton传播

    哨兵完成切换之后,会在自己本地更新生成最新的master配置,然后同步给其他的哨兵,就是通过之前说的pub/sub消息机制

    这里之前的version号就很重要了,因为各种消息都是通过一个channel去发布和监听的,所以一个哨兵完成一次新的切换之后,新的master配置是跟着新的version号的

    其他的哨兵都是根据版本号的大小来更新自己的master配置的


     

     

    展开全文
  • 这可能是目前最全的Redis高可用技术解决方案

    万次阅读 多人点赞 2018-08-27 16:27:06
    转自:... 原作者:张东洪 常见的使用方式 Redis的几种常见的使用方式包括:  Redis 单副本  Redis 多副本(主从)  Redis Sentinel(哨兵)  Redis Cluster  Redis 自...

    转自:https://mp.weixin.qq.com/s/Z-PyNgiqYrm0ZYg0r6MVeQ

    原作者:张东洪


    常见的使用方式

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

            Redis 单副本

            Redis 多副本(主从)

            Redis Sentinel(哨兵)

            Redis Cluster

            Redis 自研

    各种使用的优缺点

    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)。
    • 合理设置参数,防止误切,控制切换灵敏度控制:
    1. quorum
    2. down-after-milliseconds 30000
    3. failover-timeout 180000
    4. maxclient
    5. 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 的处理机制上,通常需要根据企业业务的实际线上环境来定制化。

    优点

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

    缺点

    • 实现复杂,开发成本高;
    • 需要建立配套的周边设施,如监控,域名服务,存储元数据信息的数据库等;
    • 维护成本高。
    展开全文
  • Redis 高可用架构最佳实践

    千次阅读 2017-08-13 21:33:16
    一、前言 2017 年 5 月 13 日,应用性能管理大讲堂广州站圆满落幕,其中来自三七...Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库,并提供多种语言的
  • Redis高可用方案-哨兵与集群

    千次阅读 2018-05-26 00:03:00
    Redis高可用方案一.名词解释二.主从复制 Redis主从复制模式可以将主节点的数据同步给从节点,从而保障当主节点不可达的情况下,从节点可以作为后备顶上来,并且可以保障数据尽量不丢失(主从复制可以保障最终一致性...
  • 如何保证 redis并发和高可用

    千次阅读 2019-05-25 11:45:46
    对于缓存来说,一般都是用来支撑读并发的。因此架构做成主从(master-slave)架构,一主多从,主负责写,并且将数据复制到其它的 slave 节点,从节点负责读。所有的读请求全部走从节点。这样也可以很轻松...
  • Redis高可用

    千次阅读 2020-02-05 23:20:33
    目录 集群 主从复制 全量复制 增量复制 无硬盘复制 sentinel(哨兵) ...Redis-Cluster(集群) ...Redis的数据分区 ...先来简单了解下redis中提供的集群策略, 虽然redis有持久化功能能够保障r...
  • Redis实战总结-Redis高可用

    千次阅读 2018-01-28 18:10:46
    在之前的博客《Redis实战总结-配置、持久化、复制》给出了一种Redis主从复制机制,简单地实现了Redis高可用。然后,如果Master服务器宕机,会导致整个Redis瘫痪,这种方式的高可用性较低。正常会采用多台Redis服务器...
  • No cross,no crown . 不经历风雨,怎么见彩虹。 Redis哨兵模式,用现在流行的话可以说就是一个“哨兵机器人”,给“哨兵机器人”进行相应的配置之后...Redis-sentinel是Redis的作者antirez,因为Redis集群的被...
  • Redis中的CAP理论

    万次阅读 2020-08-21 08:34:02
    Redis中的CAP理论CAP理论C:consistency(一致性)A:avalibility(可用性)P:Partition(分区)-tolerence to partition(分区容忍度)图解CAPP【分区】A【可用性】C【一致性】解释CAP分区:一个分布式系统,网络不通讯,导致...
  • redis sentinel是redis高可用的实现方案,在实际生产环境中,对提高整个系统的高可用性是非常有帮助的,当主节点发生故障时,redis sentinel能自动完成故障发现和故障转移,并通知应用方,从而实现高可用。...
  • redis读写分离下的高可用设计与实现(上)

    万次阅读 多人点赞 2013-12-14 09:07:06
    通过Redis笔记(一)纯小白版篇,Redis笔记(二)主从复制和Redis笔记(三)添加密码并修改默认端口后的主从同步三篇文章,我们已经能建立一个可以使用的主从复制的Redis了,例如下图: 在此基础上,我们做了...
  •   之前介绍了用docker来搭建redis主从环境,但这只是对数据添加了从库备份(主从复制),当主库down掉的时候,从库是不会自动升级为主库的,也就是说,该redis主从集群并非是高可用的。   目前来说,高可用(主从...
  • 目录: Redis 学习笔记

    千次阅读 2019-08-28 10:57:10
    Redis 学习笔记 ...05. Redis 环境搭建-高可用集群(HA) 06. Redis 环境搭建-分片集群Cluster 07. Redis 客户端访问 08. Redis 五种数据类型-字符串String 09. Redis 五种数据类型-列表List 10. Redi...
  • redis如何实现高可用【主从复制、哨兵机制】

    千次阅读 多人点赞 2018-10-07 00:56:51
    实现redis高可用机制的一些方法: 保证redis高可用机制需要redis主从复制、redis持久化机制、哨兵机制、keepalived等的支持。 主从复制的作用:数据备份、读写分离、分布式集群、实现高可用、宕机容错机制等。  ...
  • 有A,B,C三个节点的集群,在没有复制模型的情况下,如果节点B失败了,那么整个集群就会以为缺少5501-11000这个范围的槽而不可用
  • Redis高可用Sentinel哨兵

    万次阅读 2019-02-22 12:33:02
    Sentinel哨兵是redis官方提供的高可用方案,可以用它来监控多个Redis服务实例的运行情况。Redis Sentinel 是一个运行在特殊模式下的Redis服务器。Redis Sentinel是在多个Sentinel进程环境下互相协作工作的。 ...
  • redis-cluster一台机器宕机后集群不可用部署现状: 测试环境部署4台机器,每台机器上启动5个redis实例,总共20个实例;创建集群,10个主,10个从;问题呈现: 1.测试过程中,kill掉一台机器,集群正常恢复; 2....
  • Redis三种部署方案

    千次阅读 2019-01-18 11:46:54
    standaloan(单机模式) standaloan 是redis单机模式,及所有服务连接一台redis服务,该模式不...redis-Sentinel(哨兵模式)是Redis官方推荐的高可用性(HA)解决方案,当用Redis做Master-slave的高可用方案时,假如mas...
1 2 3 4 5 ... 20
收藏数 118,191
精华内容 47,276
关键字:

redis高可用