精华内容
下载资源
问答
  • db服务器连接mysql+redis可用高性能框架干货1、使用c++语言,vs2019开发垮平台[windows和linux]连接MySql和redis框架。2、使用MySql持久化玩家数据,redis做玩家数据缓存层,redis不做数据持久化。mysql搭配redis...
  • redis高可用主从配置

    2018-02-08 10:58:17
    redis的安装,主从的配置,redis+keepalive的高可用方案的配置
  • Redis高可用概述 在Redis中,实现高可用的技术主要包括:持久化、复制(读写分离)、哨兵、集群。 持久化: 持久化是最简单的高可用方法(有时甚至不被归为高可用手段),主要作用是数据备份,即将数据存储在硬盘,保证...
  • Redis高可用概述 Redis持久化概述 RDB持久化 AOF持久化

    免费视频福利推荐:

    2T学习视频教程+电子书 免费送BAT面试精讲视频,亿级流量秒杀系统,分布式系统架构,中间件消息队列,Python Go入门到精通,Java实战项目,Linux, 网络,MySQL高性能,Redis集群架构,大数据,架构师速成,微服务,容器化Docker K8s, ELK Stack日志系统等免费视频教程!

    欢迎关注公众号:「码农富哥」,致力于分享后端技术 (高并发架构,分布式集群系统,消息队列中间件,网络,微服务,Linux, TCP/IP, HTTP, MySQL, Redis), Python 等 原创干货 和 面试指南

    关注公众号后回复【资源】免费获取 2T 编程视频和电子书,回复【Redis】获取 Redis高可用集群架构视频

    Redis高可用概述

    在介绍Redis高可用之前,先说明一下在Redis的语境中高可用的含义。

    我们知道,在web服务器中,高可用是指服务器可以正常访问的时间,衡量的标准是在多长时间内可以提供正常服务(99.9%、99.99%、99.999% 等等)。但是在Redis语境中,高可用的含义似乎要宽泛一些,除了保证提供正常服务(如主从分离、快速容灾技术),还需要考虑数据容量的扩展、数据安全不会丢失等。

    在Redis中,实现高可用的技术主要包括持久化、复制、哨兵和集群,下面分别说明它们的作用,以及解决了什么样的问题。

    1. 持久化:持久化是最简单的高可用方法(有时甚至不被归为高可用的手段),主要作用是数据备份,即将数据存储在硬盘,保证数据不会因进程退出而丢失。
    2. 复制:复制是高可用Redis的基础,哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份,以及对于读操作的负载均衡和简单的故障恢复。缺陷:故障恢复无法自动化;写操作无法负载均衡;存储能力受到单机的限制。
    3. 哨兵:在复制的基础上,哨兵实现了自动化的故障恢复。缺陷:写操作无法负载均衡;存储能力受到单机的限制。
    4. 集群:通过集群,Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。

    Redis持久化概述

    Redis 的数据全部在内存里,如果突然宕机,数据就会全部丢失,因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失,这种机制就是 Redis 的持久化机制。

    Redis为持久化提供了两种方式:

    • RDB:在指定的时间间隔能对你的数据进行快照存储。
    • AOF:记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。

    由于AOF持久化的实时性更好,即当进程意外退出时丢失的数据更少,因此AOF是目前主流的持久化方式,不过RDB持久化仍然有其用武之地。

    下面依次介绍RDB持久化和AOF持久化;

    RDB持久化

    RDB是默认的持久化方式,按照一定的策略周期性的将内存中的数据生成快照保存到磁盘。

    每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步脏数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘io操作,可能会严重影响性能。

    1. 工作原理:

    • Redis调用fork(),产生一个子进程。
    • 子进程把数据写到一个临时的RDB文件。
    • 当子进程写完新的RDB文件后,把旧的RDB文件替换掉。

    2. 触发机制

    RDB触发持久化分为手动触发和自动触发

    1. save 命令(手动触发)

    当客户端向Redis server发送save命令请求进行持久化时,由于Redis是用一个主线程来处理所有,save命令会阻塞Redis server处理其他客户端的请求,直到数据同步完成。save命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在Redis服务器阻塞期间,服务器不能处理任何命令请求,因此线上环境不推荐使用

    2. bgsave命令(手动触发)

    与save命令不同,bgsave是异步执行的,当执行bgsave命令之后,Redis主进程会fork 一个子进程将数据保存到rdb文件中,同步完数据之后,对原有文件进行替换,然后通知主进程表示同步完成。

    3. 自动触发

    除了手动触发RDB持久化,Redis内部还存在自动触发机制,

    在配置中集中配置 save m n 的方式,表示 m秒内数据集存在n次修改时,系统自动触发bgsave 操作。 

    3. RDB自动持久化配置

    # 时间策略
    save 900 1
    save 300 10
    save 60 10000
    
    # 文件名称
    dbfilename dump.rdb
    
    # 文件保存路径
    dir /etc/redis/data/
    
    # 如果持久化出错,主进程是否停止写入
    stop-writes-on-bgsave-error yes
    
    # 是否压缩
    rdbcompression yes
    
    # 导入时是否检查
    rdbchecksum yes

    rdb持久化策略比较简单,下面解释一下:

    • save 900 1 表示900s内如果有1条是写入命令,就触发产生一次快照,可以理解为就进行一次备份
    • save 300 10 表示300s内有10条写入,就产生快照

    下面的类似,那么为什么需要配置这么多条规则呢?因为Redis每个时段的读写请求肯定不是均衡的,为了平衡性能与数据安全,我们可以自由定制什么情况下触发备份。所以这里就是根据自身Redis写入情况来进行合理配置。

    stop-writes-on-bgsave-error yes 这个配置也是非常重要的一项配置,这是当备份进程出错时,主进程就停止接受新的写入操作,是为了保护持久化的数据一致性问题。如果自己的业务有完善的监控系统,可以禁止此项配置, 否则请开启。

    rdbcompression yes ,用于配置是否压缩RDB文件,建议没有必要开启,毕竟Redis本身就属于CPU密集型服务器,再开启压缩会带来更多的CPU消耗,相比硬盘成本,CPU更值钱。

    rdbchecksum yes:是否开启RDB文件的校验,在写入文件和读取文件时都起作用;关闭checksum在写入文件和启动文件时大约能带来10%的性能提升,但是数据损坏时无法发现

    dbfilename dump.rdb:RDB文件名

    dir ./:RDB文件和AOF文件所在目录

    当然如果你想要禁用RDB配置,也是非常容易的,只需要在save的最后一行写上:save ""

    4. 执行流程图:

    1)  Redis父进程首先判断:当前是否在执行save,或bgsave/bgrewriteaof(后面会详细介绍该命令)的子进程,如果在执行则bgsave命令直接返回。bgsave/bgrewriteaof 的子进程不能同时执行,主要是基于性能方面的考虑:两个并发的子进程同时执行大量的磁盘写操作,可能引起严重的性能问题。

    2)  父进程执行fork操作创建子进程,这个过程中父进程是阻塞的,Redis不能执行来自客户端的任何命令

    3)  父进程fork后,bgsave命令返回”Background saving started”信息并不再阻塞父进程,并可以响应其他命令

    4)  子进程创建RDB文件,根据父进程内存快照生成临时快照文件,完成后对原有文件进行原子替换

    5)  子进程发送信号给父进程表示完成,父进程更新统计信息

    5. 数据恢复 & Redis启动加载数据

    RDB文件的载入工作是在服务器启动时自动执行的,并没有专门的命令。但是由于AOF的优先级更高,因此当AOF开启时,Redis会优先载入AOF文件来恢复数据;

    只有当AOF关闭时,才会在Redis服务器启动时检测RDB文件,并自动载入。服务器载入RDB文件期间处于阻塞状态,直到载入完成为止。

    所以Redis的内存数据如果很大,会导致数据恢复时间比较长,因此线上实践更倾向于限制单个Redis的内存不能太大,同时结合Redis Cluster集群使用多节点部署

    Redis启动日志中可以看到自动载入的执行:

    Redis载入RDB文件时,会对RDB文件进行校验,如果文件损坏,则日志中会打印错误,Redis启动失败。

    大家如果更系统了解Redis 高可用集群架构知识,可以关注公众号【码农富哥】后回复【Redis】获取 Redis高可用集群架构视频

    AOF持久化

    RDB快照并不是很可靠。如果你的电脑突然宕机了,或者电源断了,又或者不小心杀掉了进程,那么最新的数据就会丢失。而AOF文件则提供了一种更为可靠的持久化方式。每当Redis接受到会修改数据集的命令时,就会把命令追加到AOF文件里,当你重启Redis时,AOF里的命令会被重新执行一次,重建数据。

    1.工作原理

    由于需要记录Redis的每条写命令,因此AOF不需要触发, AOF的执行流程包括:

    • 命令追加(append):将Redis的写命令追加到缓冲区aof_buf;
    • 文件写入(write)和文件同步(sync):根据不同的同步策略将aof_buf中的内容同步到硬盘;
    • 文件重写(rewrite):定期重写AOF文件,达到压缩的目的。

    2. AOF 持久化配置

    # 是否开启aof
    appendonly yes
    
    # 文件名称
    appendfilename "appendonly.aof"
    
    # 同步方式
    appendfsync everysec
    
    # aof重写期间是否同步
    no-appendfsync-on-rewrite no
    
    # 重写触发配置
    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb
    
    # 加载aof时如果有错如何处理
    aof-load-truncated yes
    
    # 文件重写策略
    aof-rewrite-incremental-fsync yes

    3. AOF同步策略

    同步步骤分为两步:

    • Redis收到写命令后首先会追加到AOF缓冲区aof_buf,而不是直接写入文件系统,因为AOF缓冲区是内存提存的,写入速度极高,可以避免每次写入命令到硬盘,导致硬盘IO成为Redis的负载瓶颈
    • 通过调用系统函数 fsync() 把AOF缓冲区的数据真正写到磁盘里面持久化。由于数据是先存储在缓冲区内存里面,如果碰到断电,宕机那么缓冲区里面的数据没来得急落盘就会丢失,因此我们必须有一个相对可靠的机制保证数据落盘。

    Redis写命令写入磁盘的命令是通过appendfsync来配置的。

    appendfsync 三个取值代表三种落盘策略:

    • always:命令写入aof缓冲区后立即调用系统fsync操作同步到AOF文件,fsync完成后线程返回。这种情况下,每次有写命令都要同步到AOF文件,硬盘IO成为性能瓶颈。
    • no:命令写入aof缓冲区后调用系统write操作,不对AOF文件做fsync同步;同步由操作系统负责,通常同步周期为30秒。这种情况下,文件同步的时间不可控,且缓冲区中堆积的数据会很多,数据安全性无法保证。
    • everysec:命令写入aof缓冲区后调用系统write操作,write完成后线程返回;fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中,是性能和数据安全性的平衡,因此是Redis的默认配置,也是我们推荐的配置。

    4. AOF文件重写(rewrite)

    随着写操作的不断增加,AOF文件会越来越大。例如你递增一个计数器100次,那么最终结果就是数据集里的计数器的值为最终的递增结果,但是AOF文件里却会把这100次操作完整的记录下来。而事实上要恢复这个记录,只需要1个命令就行了,也就是说AOF文件里那100条命令其实可以精简为1条。所以Redis支持这样一个功能:在不中断服务的情况下在后台重建AOF文件。

    重写流程:

    Redis 持久化与恢复

    关于文件重写的流程,有两点需要特别注意:

    (1)重写由父进程fork子进程进行;

    (2)重写期间Redis执行的写命令,需要追加到新的AOF文件中,为此Redis引入了aof_rewrite_buf缓存。

    对照上图,文件重写的流程如下:

    1) Redis父进程首先判断当前是否存在正在执行 bgsave/bgrewriteaof的子进程,如果存在则bgrewriteaof命令直接返回,如果存在bgsave命令则等bgsave执行完成后再执行。前面曾介绍过,这个主要是基于性能方面的考虑。

    2) 父进程执行fork操作创建子进程,这个过程中父进程是阻塞的。

    3.1) 父进程fork后,bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程,并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区,并根据appendfsync策略同步到硬盘,保证原有AOF机制的正确。

    3.2) 由于fork操作使用写时复制技术,子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令,因此Redis使用AOF重写缓冲区(图中的aof_rewrite_buf)保存这部分数据,防止新AOF文件生成期间丢失这部分数据。也就是说,bgrewriteaof执行期间,Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。

    4) 子进程根据内存快照,按照命令合并规则写入到新的AOF文件。

    5.1) 子进程写完新的AOF文件后,向父进程发信号,父进程更新统计信息,具体可以通过info persistence查看。

    5.2) 父进程把AOF重写缓冲区的数据写入到新的AOF文件,这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。

    5.3) 使用新的AOF文件替换老文件,完成AOF重写。

    重写触发:

    1. 手动触发:直接调用bgrewriteaof命令,该命令的执行与bgsave有些类似:都是fork子进程进行具体的工作,且都只有在fork时阻塞。

    2. 自动触发:通过配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size来完成

    auto-aof-rewrite-percentage 100 :Redis会记住自从上一次重写后AOF文件的大小(如果自Redis启动后还没重写过,则记住启动时使用的AOF文件的大小)。如果当前的文件大小比起记住的那个大小超过指定的百分比,则会触配置发重写。 

    auto-aof-rewrite-min-size 64mb:同时需要设置一个文件大小最小值,只有大于这个值文件才会重写,以防文件很小,但是已经达到百分比的情况。  

    要禁用自动的日志重写功能,我们可以把百分比设置为0:

    auto-aof-rewrite-percentage 0: 禁用日志重写功能

    5. 数据恢复 & Redis启动加载数据

    前面提到过,当AOF开启时,Redis启动时会优先载入AOF文件来恢复数据;

    只有当AOF关闭时,才会载入RDB文件恢复数据。

    当AOF开启,且AOF文件存在时,Redis启动日志:

     

    持久化方案选择

    1. RDB和AOF的优缺点

    RDB和AOF各有优缺点:

    RDB持久化

    优点:RDB文件紧凑,体积小,网络传输快,适合全量复制;恢复速度比AOF快很多。当然,与AOF相比,RDB最重要的优点之一是对性能的影响相对较小。

    缺点:RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化,而在数据越来越重要的今天,数据的大量丢失很多时候是无法接受的,因此AOF持久化成为主流。此外,RDB文件需要满足特定格式,兼容性差(如老版本的Redis不兼容新版本的RDB文件)。

    AOF持久化

    与RDB持久化相对应,AOF的优点在于支持秒级持久化、兼容性好,缺点是文件大、恢复速度慢、对性能影响大。

    2. 性能与实践

    通过上面的分析,我们都知道RDB的快照、AOF的重写都需要fork,这是一个重量级操作,会对Redis造成阻塞。因此为了不影响Redis主进程响应,我们需要尽可能降低阻塞。

    1. 降低fork的频率,比如可以手动来触发RDB生成快照、与AOF重写;
    2. 控制Redis最大使用内存,防止fork耗时过长;
    3. 使用更牛逼的硬件;
    4. 合理配置Linux的内存分配策略,避免因为物理内存不足导致fork失败。

    在线上我们到底该怎么做?我提供一些自己的实践经验。

    1. 如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据,可以关闭持久化,如果丢失数据可以通过其它途径补回;
    2. 自己制定策略定期检查Redis的情况,然后可以手动触发备份、重写数据;
    3. 单机如果部署多个实例,要防止多个机器同时运行持久化、重写操作,防止出现内存、CPU、IO资源竞争,让持久化变为串行;
    4. 可以加入主从机器,利用一台从机器进行备份处理,其它机器正常响应客户端的命令;
    5. RDB持久化与AOF持久化可以同时存在,配合使用。

    总结

    Redis的高可用系列:持久化就已经讲完了,持久化主要有RDB和AOF两种技术,大家按照上面所介绍的原理和流程,根据线上具体需求选择适合自己的持久化方案。

    另外,写原创技术文章不易,要花费好多时间和精力,希望大家看到文章也能有所收获!你们的点赞和收藏就能成为我继续坚持输出原创文章的动力!大家也可以关注我的公众号,订阅更多我的文章!

    欢迎关注公众号:「码农富哥」,致力于分享后端技术 (高并发架构,分布式集群系统,消息队列中间件,网络,微服务,Linux, TCP/IP, HTTP, MySQL, Redis), Python 等 原创干货 和 面试指南

    关注公众号后回复【资源】免费获取 2T 编程视频和电子书,回复【Redis】获取 Redis高可用集群架构视频

    展开全文
  • 该资源是本人在学习redis过程中积累总结的经验以分享给大家:redis-sentinel高可用一键配置工具就是一键帮你从下载->安装->配置 好 redis 高可用的服务环境,省去了很多弯路,节约了更多的时间花在自己项目的主要...
  • 本文将要介绍的哨兵,它基于Redis主从复制,主要作用便是解决主节点故障恢复的自动化问题,进一步提高系统的高可用性。(注:文章内容基于Redis3.0版本)在介绍哨兵之前,首先从宏观角度回顾一下Redis实现高可用相关...
  • 该资源是本人在学习redis过程中积累总结的经验以分享给大家:redis-sentinel高可用一键配置工具就是一键帮你从下载->安装->配置 好 redis 高可用的服务环境,省去了很多弯路,节约了更多的时间花在自己项目的主要...
  • Redis高可用方案对比

    千次阅读 2018-11-05 23:00:11
    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-15 17:51:29
    目录 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配置的


     

     

    展开全文
  • 基于SpringBoot搭建 使用面向切面将所有方法上带有@Lock的方法进行拦截 进行锁的处理
  • Redis 高可用架构最佳实践

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

    http://www.sohu.com/a/150426358_505802

    一、前言

    2017 年 5 月 13 日,应用性能管理大讲堂广州站圆满落幕,其中来自三七互娱的 DBA 温国兵在会场与各位进行了精彩的 Redis 技术分享。

    Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库,并提供多种语言的 API。

    如今,互联网业务的数据正以更快的速度在增长,数据类型越来越丰富,这对数据处理的速度和能力提出了更高要求。Redis 是一种开源的内存非关系型数据库,给开发人员带来的体验是颠覆性的。在自始至终的设计过程中,都充分考虑高性能,这使得 Redis 成为当今速度最快的 NoSQL 数据库。

    考虑高性能的同时,高可用也是很重要的考虑因素。互联网 7x24 无间断服务,在故障期间以最快的速度 Failover,能给企业带来最小的损失。

    那么,在实际应用中,都有哪些高可用架构呢?架构之间有何优劣?我们应该怎么取舍?有哪些最佳实践?

    二、Sentinel 原理

    在讲解 Redis 高可用方案之前,我们先来看看 Redis Sentinel 原理(https://redis.io/topics/sentinel)是怎么样的。

    1. Sentinel 集群通过给定的配置文件发现 master,启动时会监控 master。通过向 master 发送 info 信息获得该服务器下面的所有从服务器。

    2. Sentinel 集群通过命令连接向被监视的主从服务器发送 hello 信息 (每秒一次),该信息包括 Sentinel 本身的 IP、端口、id 等内容,以此来向其他 Sentinel 宣告自己的存在。

    3. Sentinel 集群通过订阅连接接收其他 Sentinel 发送的 hello 信息,以此来发现监视同一个主服务器的其他 Sentinel;集群之间会互相创建命令连接用于通信,因为已经有主从服务器作为发送和接收 hello 信息的中介,Sentinel 之间不会创建订阅连接。

    4. Sentinel 集群使用 ping 命令来检测实例的状态,如果在指定的时间内(down-after-milliseconds)没有回复或则返回错误的回复,那么该实例被判为下线。

    5. 当 failover 主备切换被触发后,failover 并不会马上进行,还需要 Sentinel 中的大多数 Sentinel 授权后才可以进行 failover,即进行 failover 的 Sentinel 会去获得指定 quorum 个的 Sentinel 的授权,成功后进入 ODOWN 状态。如在 5 个 Sentinel 中配置了 2 个 quorum,等到 2 个 Sentinel 认为 master 死了就执行 failover。

    6. Sentinel 向选为 master 的 slave 发送 SLAVEOF NO ONE 命令,选择 slave 的条件是 Sentinel 首先会根据 slaves 的优先级来进行排序,优先级越小排名越靠前。如果优先级相同,则查看复制的下标,哪个从 master 接收的复制数据多,哪个就靠前。如果优先级和下标都相同,就选择进程 ID 较小的。

    7. Sentinel 被授权后,它将会获得宕掉的 master 的一份最新配置版本号 (config-epoch),当 failover 执行结束以后,这个版本号将会被用于最新的配置,通过广播形式通知其它 Sentinel,其它的 Sentinel 则更新对应 master 的配置。

    1 到 3 是自动发现机制:

    • 以 10 秒一次的频率,向被监视的 master 发送 info 命令,根据回复获取 master 当前信息。

    • 以 1 秒一次的频率,向所有 redis 服务器、包含 Sentinel 在内发送 PING 命令,通过回复判断服务器是否在线。

    • 以 2 秒一次的频率,通过向所有被监视的 master,slave 服务器发送当前 Sentinel master 信息的消息。

    4 是检测机制,5 和 6 是 failover 机制,7 是更新配置机制。[1]

    三、Redis 高可用架构

    讲解完 Redis Sentinel 原理之后,接下来讲解常用的 Redis 高可用架构

    • Redis Sentinel 集群 + 内网 DNS + 自定义脚本

    • Redis Sentinel 集群 + VIP + 自定义脚本

    • 封装客户端直连 Redis Sentinel 端口

      • JedisSentinelPool,适合 Java

      • PHP 基于 phpredis 自行封装

    • Redis Sentinel 集群 + Keepalived/Haproxy

    • Redis M/S + Keepalived

    • Redis Cluster

    • Twemproxy

    • Codis

    接下来配合图文逐个讲解。

    1、Redis Sentinel 集群 + 内网 DNS + 自定义脚本

    Redis Sentinel 集群 + 内网 DNS + 自定义脚本

    上图是已经在线上环境应用的方案。底层是 Redis Sentinel 集群,代理着 Redis 主从,Web 端连接内网 DNS 提供服务。内网 DNS 按照一定的规则分配,比如 xxxx.redis.cache/queue.port.xxx.xxx,第一个段表示业务简写,第二个段表示这是 Redis 内网域名,第三个段表示 Redis 类型,cache 表示缓存,queue 表示队列,第四个段表示 Redis 端口,第五、第六个段表示内网主域名。

    当主节点发生故障,比如机器故障、Redis 节点故障或者网络不可达,Sentinel 集群会调用 client-reconfig- 配置的脚本,修改对应端口的内网域名。对应端口的内网域名指向新的 Redis 主节点。

    优点:

    秒级切换,在 10s 内完成整个切换操作

    脚本自定义,架构可控

    对应用透明,前端不用担心后端发生什么变化

    缺点:

    维护成本略高,Redis Sentinel 集群建议投入 3 台机器以上

    依赖 DNS,存在解析延时

    Sentinel 模式存在短时间的服务不可用

    服务通过外网访问不可采用此方案

    2、Redis Sentinel 集群 + VIP + 自定义脚本

    Redis Sentinel 集群 + VIP + 自定义脚本

    此方案和上一个方案相比,略有不同。第一个方案使用了内网 DNS,第二个方案把内网 DNS 换成了虚拟 IP。底层是 Redis Sentinel 集群,代理着 Redis 主从,Web 端通过 VIP 提供服务。在部署 Redis 主从的时候,需要将虚拟 IP 绑定到当前的 Redis 主节点。当主节点发生故障,比如机器故障、Redis 节点故障或者网络不可达,Sentinel 集群会调用 client-reconfig- 配置的脚本,将 VIP 漂移到新的主节点上。

    优点:

    • 秒级切换,在 5s 内完成整个切换操作

    • 脚本自定义,架构可控

    • 对应用透明,前端不用担心后端发生什么变化

    缺点:

    • 维护成本略高,Redis Sentinel 集群建议投入 3 台机器以上

    • 使用 VIP 增加维护成本,存在 IP 混乱风险

    • Sentinel 模式存在短时间的服务不可用

    • 3.3 封装客户端直连 Redis Sentinel 端口

    3、封装客户端直连 Redis Sentinel 端口

    部分业务只能通过外网访问 Redis,上述两种方案均不可用,于是衍生出了这种方案。Web 使用客户端连接其中一台 Redis Sentinel 集群中的一台机器的某个端口,然后通过这个端口获取到当前的主节点,然后再连接到真实的 Redis 主节点进行相应的业务员操作。需要注意的是,Redis Sentinel 端口和 Redis 主节点均需要开放访问权限。如果前端业务使用 Java,有 JedisSentinelPool 可以复用;如果前端业务使用 PHP,可以在 phpredis 的基础上做二次封装。

    优点:

    • 服务探测故障及时

    • DBA 维护成本低

    缺点:

    • 依赖客户端支持 Sentinel

    • Sentinel 服务器和 Redis 节点需要开放访问权限

    • 对应用有侵入性

    4、Redis Sentinel 集群 + Keepalived/Haproxy

    Redis Sentinel 集群 + Keepalived/Haproxy

    底层是 Redis Sentinel 集群,代理着 Redis 主从,Web 端通过 VIP 提供服务。当主节点发生故障,比如机器故障、Redis 节点故障或者网络不可达,Redis 之间的切换通过 Redis Sentinel 内部机制保障,VIP 切换通过 Keepalived 保障。

    优点:

    • 秒级切换

    • 对应用透明

    缺点:

    • 维护成本高

    • 存在脑裂

    • Sentinel 模式存在短时间的服务不可用

    5、Redis M/S + Keepalived

    Redis M/S + Keepalived

    此方案没有使用到 Redis Sentinel。此方案使用了原生的主从和 Keepalived,VIP 切换通过 Keepalived 保障,Redis 主从之间的切换需要自定义脚本实现。

    优点:

    • 秒级切换

    • 对应用透明

    • 部署简单,维护成本低

    缺点:

    • 需要脚本实现切换功能

    • 存在脑裂

    6、Redis Cluster

    Redis Cluster

    From: http://intro2libsys.com/focused-redis-topics/day-one/intro-redis-cluster

    Redis 3.0.0 在 2015 年 4 月 2 日正式发布,距今已有两年多的时间。Redis 集群采用 P2P 模式,无中心化。把 key 分成 16384 个 slot,每个实例负责一部分 slot。客户端请求对应的数据,若该实例 slot 没有对应的数据,该实例会转发给对应的实例。另外,Redis 集群通过 Gossip 协议同步节点信息。

    优点:

    • 组件 all-in-box,部署简单,节约机器资源

    • 性能比 proxy 模式好

    • 自动故障转移、Slot 迁移中数据可用

    • 官方原生集群方案,更新与支持有保障

    缺点:

    • 架构比较新,最佳实践较少

    • 多键操作支持有限(驱动可以曲线救国)

    • 为了性能提升,客户端需要缓存路由表信息

    • 节点发现、reshard 操作不够自动化

    7、Twemproxy

    Twemproxy

    From: http://engineering.bloomreach.com/the-evolution-of-fault-tolerant-redis-cluster

    多个同构 Twemproxy(配置相同)同时工作,接受客户端的请求,根据 hash 算法,转发给对应的 Redis。

    Twemproxy 方案比较成熟了,之前我们团队长期使用此方案,但是效果并不是很理想。一方面是定位问题比较困难,另一方面是它对自动剔除节点的支持不是很友好。

    优点:

    • 开发简单,对应用几乎透明

    • 历史悠久,方案成熟

    缺点:

    • 代理影响性能

    • LVS 和 Twemproxy 会有节点性能瓶颈

    • Redis 扩容非常麻烦

    • Twitter 内部已放弃使用该方案,新使用的架构未开源

    8、Codis

    Codis

    From: https://github.com/CodisLabs/codis

    Codis 是由豌豆荚开源的产品,涉及组件众多,其中 ZooKeeper 存放路由表和代理节点元数据、分发 Codis-Config 的命令;Codis-Config 是集成管理工具,有 Web 界面供使用;Codis-Proxy 是一个兼容 Redis 协议的无状态代理;Codis-Redis 基于 Redis 2.8 版本二次开发,加入 slot 支持,方便迁移数据。

    优点:

    • 开发简单,对应用几乎透明

    • 性能比 Twemproxy 好

    • 有图形化界面,扩容容易,运维方便

    缺点:

    • 代理依旧影响性能

    • 组件过多,需要很多机器资源

    • 修改了 Redis 代码,导致和官方无法同步,新特性跟进缓慢

    • 开发团队准备主推基于 Redis 改造的 reborndb

    四、最佳实践

    所谓的最佳实践,都是最适合具体场景的实践。

    主推以下方案:

    • Redis Sentinel 集群 + 内网 DNS + 自定义脚本

    • Redis Sentinel 集群 + VIP + 自定义脚本

    以下是实战过程中总结出的最佳实践:

    • Redis Sentinel 集群建议使用 >= 5 台机器

    • 不同的大业务可以使用一套 Redis Sentinel 集群,代理该业务下的所有端口

    • 根据不同的业务划分好 Redis 端口范围

    • 自定义脚本建议采用 Python 实现,扩展便利

    • 自定义脚本需要注意判断当前的 Sentinel 角色

    • 自定义脚本传入参数:<service_name> <role> <comment> <from_ip> <from_port> <to_ip> <to_port>

    • 自定义脚本需要远程 ssh 操作机器,建议使用 paramiko 库,避免重复建立 SSH 连接,消耗时间

    • 加速 SSH 连接,建议关闭以下两个参数

    • UseDNS no

    • GSSAPIAuthentication no

    • 微信或者邮件告警,建议 fork 一个进程,避免主进程阻塞

    • 自动切换和故障切换,所有操作建议在 15s 以内完成

    五、小结

    此次活动分享了 Redis 高可用的必要性、Sentinel 原理、Redis 高可用常用架构和实战过程中总结出的最佳实践,希望对读者有所帮助,如果有需要后续交流的,可以添加我的微信(Wentasy),或者发邮件到:dbarobinwen@gmail.com

    附 PPT 下载:https://github.com/dbarobin/slides

    视频回放:Redis 高可用架构最佳实践 http://www.itdks.com/dakashuo/detail/1437

    六、致谢

    感谢听云和运维帮的精心组织,感谢大家冒着大雨前来参加此次活动。此次分享由 IT 大咖说全程录像,感谢 IT 大咖说的技术支持。

    展开全文
  • 实现redis高可用机制的一些方法

    千次阅读 2018-09-30 10:29:13
    实现redis高可用机制的一些方法: 保证redis高可用机制需要redis主从复制、redis持久化机制、哨兵机制、keepalived等的支持。 主从复制的作用:数据备份、读写分离、分布式集群、实现高可用、宕机容错机制等。 ...
  • 1.创建一个redis_docker目录 mkdir redis_docker cd redis_docker 2.下载redis压缩包(这里我下载的是4.0.13版本) wget http://download.redis.io/releases/redis-4.0.13.tar.gz 3.解压并编译redis tar zxvf redis-...
  • 这可能是目前最全的Redis高可用技术解决方案

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

    万次阅读 2019-02-20 16:35:15
    Sentinel哨兵是redis官方提供的高可用方案,可以用它来监控多个Redis服务实例的运行情况。Redis Sentinel 是一个运行在特殊模式下的Redis服务器。Redis Sentinel是在多个Sentinel进程环境下互相协作工作的。 ...
  • 由于单台redis出现单点故障,就会导致整个系统不可用,所以想到的办法自然就是备份(一般工业界认为比较安全的备份数应该是3份)。当一台redis出现问题了,另一台redis可以继续提供服务。 备份 三、自动故障转移...
  • zookeeper+redis高可用完整实例.zip

    热门讨论 2014-04-29 01:50:38
    zookeeper实现redis高可用,包括监控心跳和切换,以及恢复等
  • redis高可用方案.docx

    2019-11-12 09:29:05
    文档简单描述的redis的集中高可用架构,并且对redis 哨兵架构进行了搭建记录和介绍,文末给出了针对于哨兵模式高可用架构的各种宕机测试报告以及解决方案
  • redis高可用集群解决方案

    千次阅读 2017-07-09 15:26:07
    redis高可用集群解决方案redis介绍 redis简介 Redis 是完全开源免费的,遵守BSD协议,是一个性能的key-value数据库。 Redis 与其他 key - value 缓存产品有以下三个特点: Redis支持数据的持久化,可以将内存...
  • Redis 高可用架构最佳实践.ppt
  • Redis高可用方案-哨兵与集群

    千次阅读 2018-05-26 00:03:00
    Redis高可用方案一.名词解释二.主从复制 Redis主从复制模式可以将主节点的数据同步给从节点,从而保障当主节点不可达的情况下,从节点可以作为后备顶上来,并且可以保障数据尽量不丢失(主从复制可以保障最终一致性...
  •   之前介绍了用docker来搭建redis主从环境,但这只是对数据添加了从库备份(主从复制),当主库down掉的时候,从库是不会自动升级为主库的,也就是说,该redis主从集群并非是高可用的。   目前来说,高可用(主从...
  • keepalived-redis高可用配置脚本,内含主从的keepalived.conf 及脚本
  • 目录 概述 哨兵的分布式特性 安装Redis-Sentinel集群 Redis-Sentinel集群配置 redis.conf配置 sentinel.conf配置 ...Redis-Sentinel哨兵机制为Redis提供了高可用性,这意味着你可以使用哨兵模式创建...
  • redis高可用:keepalived+redis主从部署

    万次阅读 2017-08-11 15:30:56
    Redis主从+Keepalived
  • 【windows】redis高可用主从+哨兵,有详细的word操作文档和已经配置好的主从文件,只需要把文件放在不同节点的电脑上按照word的说明进行更改就可以使用了,公司让我为新系统提供高可用真的是很折腾~~~
  • redis+Keepalived实现Redis高可用性 主要包含两个文件: 1、安装文档 2、各种脚本文件
  • redis高可用笔记
  • 作者:张冬洪,极数云舟数据库架构师、极数学院联合创始人、前新浪微博高级DBA、Redis中国用户组主席、阿里云MVP。微信:zhangdh1113继采访 “对话张冬洪 |...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 162,520
精华内容 65,008
关键字:

redis高可用

redis 订阅