下载文档原格式
redis异地灾备方案咱来说说Redis的异地灾备方案哈。
一、为啥要搞异地灾备呢？你想啊，Redis里存着咱好多重要的数据呢，就像宝贝一样。
要是本地出了啥岔子，比如机房着火啦（虽然这事儿有点吓人，但也不是没可能），或者遭遇洪水啦，或者就是服务器突然抽风全挂了，那数据可就没了，这可不行啊。
所以得搞个异地灾备，就像给这些数据宝贝在别的地方找个安全的小窝。
二、数据同步是关键。
1. 基于主从复制。
咱可以先在本地弄个Redis主节点，这个主节点就像老大一样，管着数据。
然后在异地弄个从节点。
主节点的数据一变，就把变化的部分告诉从节点，让从节点跟着变。
这就像是老大做了个啥决策，马上派人告诉在异地的小弟一样。
不过这里面有个小问题，就是网络要是不好，可能会有点延迟，数据同步就没那么及时。
2. 使用Redis Sentinel（哨兵模式）这就像是给主从结构找了个小管家。
哨兵会一直盯着主节点和从节点。
要是主节点出问题了，比如说突然死机了，哨兵就会发现，然后让从节点变成新的主节点。
这样就能保证服务一直能有个主节点在工作。
而且在异地灾备的时候，异地的从节点也能在本地主节点出问题的时候顶上去。
不过要注意，哨兵的配置也得小心，别让它误判了。
3. Redis Cluster（集群模式）跨地域部署。
把Redis集群分布在不同的地域。
比如说一部分节点在本地，一部分在异地。
集群里的数据是分散存储的，而且会自动进行数据的重新分片啥的。
这样即使本地的一些节点完蛋了，异地的节点还能把数据找回来重新组合起来。
就像搭积木一样，本地的积木倒了，异地还有备份的积木可以重新搭起来。
不过这种方式对网络要求比较高，毕竟节点之间要经常通信来协调数据的事儿。
三、网络方面的考虑。
1. 网络带宽。
网络带宽得足够大，不然数据同步就会像蜗牛爬一样慢。
就好比你要搬家，车太小了，东西就得来回运好多趟，浪费时间还容易出问题。
所以要根据数据量和同步频率来选择合适的网络带宽。
数据库的高可用性与容灾方案在现代信息化的背景下，数据库高可用和容灾方案已经成为日常工作的重要需求。
在此背景下，为了确保数据中心的可靠性和稳定性，数据库的高可用性以及容灾方案备受关注。
因此，本文将讨论数据库的高可用性和容灾方案，以及如何选择合适的方案，从而确保数据的安全和稳定。
一、数据库高可用性高可用性是指系统在遇到故障或异常情况时仍然能够保持可用性和处理能力的能力。
对于数据库而言，高可用性主要包括以下几个方面：1. 硬件冗余通过使用冗余的硬件设备，如双电源、双网卡、双控制器等，以及硬件级别的阵列RAID技术，可以提高系统的可用性。
当一个硬件组件发生故障时，系统可以自动转移到备用组件上，从而减少系统宕机的风险。
2. 数据库复制数据库复制是指将主数据库上的数据完全复制到备用数据库上，当主数据库发生故障时，可以快速切换到备用数据库上。
此外，数据库复制还可以提高系统的读取能力和负载均衡能力，提高整体系统的性能。
3. 数据库集群数据库集群是将多个数据库服务器组成一个集群，共同提供服务，以实现高可用性和负载均衡。
在数据库集群中，每个节点都可以独立的处理数据请求，并且可以实现动态扩容和缩容，从而提高系统的可用性。
二、数据库容灾方案容灾方案是指系统遭受严重灾难时，如地震、火灾等自然灾害、人为破坏等情况下，能够尽快恢复系统运行的能力。
对于数据库而言，容灾方案主要包括以下几个方面：1. 数据库备份定期的数据库备份可以确保在系统发生灾难时，可以快速恢复数据库。
备份可以在本地或者远程位置存储，以确保即使本地数据中心遭受损失，备份仍然可以在本地或者远程数据中心恢复。
2. 数据库复制数据库复制不仅可以用于提高系统的可用性，还可以用于实现数据在不同数据中心之间的同步复制。
当一个数据中心发生灾难时，可以快速切换到另一个数据中心，并且数据不会丢失。
3. 数据库异地容灾数据库的异地容灾是通过在不同的地理位置部署不同的数据库系统，以实现数据在不同地理位置之间的同步复制。
redis6种策略Redis是一种流行的开源内存数据库，它提供了多种策略来处理数据。
本文将介绍Redis的六种策略，包括数据持久化、主从复制、高可用性、分布式缓存、事务处理和发布订阅。
一、数据持久化数据持久化是Redis的核心特性之一，它允许将内存中的数据保存到硬盘中，以防止数据丢失。
Redis提供了两种数据持久化策略：RDB和AOF。
1. RDB（Redis DataBase）是一种快照式的持久化策略，它会将数据保存为二进制文件。
RDB的优点是文件体积小、加载速度快，适合用于备份和恢复数据。
缺点是在发生故障时可能会有数据丢失。
2. AOF（Append Only File）是一种追加式的持久化策略，它会将每个写操作追加到文件末尾。
AOF的优点是可以提供更好的数据安全性，因为每个操作都会被记录下来。
缺点是文件体积相对较大，加载速度相对较慢。
二、主从复制主从复制是一种将数据从一个Redis服务器复制到多个Redis服务器的策略，用于提高系统的读写性能和可用性。
主从复制的过程分为三个步骤：复制初始化、全量复制和增量复制。
1. 复制初始化：从服务器连接主服务器，并通过发送SYNC命令来进行复制初始化。
2. 全量复制：主服务器将自己的数据发送给从服务器，从服务器接收并加载数据。
3. 增量复制：主服务器将自己的写操作发送给从服务器，从服务器接收并执行写操作，从而保持数据的一致性。
主从复制可以提高系统的读写性能，同时还可以提供故障切换和负载均衡的功能。
三、高可用性高可用性是指系统在发生故障时能够保持正常运行的能力。
Redis 提供了多种策略来实现高可用性，包括哨兵模式和集群模式。
1. 哨兵模式：哨兵模式是通过监控主服务器的状态来实现高可用性。
当主服务器发生故障时，哨兵会自动将一个从服务器升级为主服务器，从而保证系统的可用性。
2. 集群模式：集群模式是通过将数据分布在多个节点上来实现高可用性。
当某个节点发生故障时，其他节点会自动接管该节点的工作，从而保证系统的可用性。
redis灾备方案Redis是一款开源的内存数据结构存储系统，具有高性能、高可用性和易于使用的特点，被广泛用于缓存、消息队列和实时分析等场景。
然而，由于Redis的单机模式存在单点故障的风险，为了保障数据的安全性和高可用性，需要进行灾备方案的规划和实施。
一、灾备方案概述灾备方案主要包括主从复制和哨兵模式两种常见的解决方案。
主从复制通过将主节点的数据复制到从节点上，实现数据的冗余和备份；哨兵模式则引入了哨兵节点，通过监控Redis主从节点的健康状态和自动切换，提供了更高的可用性。
二、主从复制方案1. 配置主节点和从节点在Redis的配置文件中，将主节点的ip地址和端口号配置为从节点的masterof参数。
从节点将会连接到主节点并复制其数据。
同时，可以设置复制的安全性密码，提高数据的安全性。
2. 复制过程主节点将每次写操作的数据变更记录到本地的AOF（Append Only File）或RDB（Redis Database）文件中，从节点通过连接到主节点，获取并复制这些数据变更，将其应用到本地的数据库中。
3. 数据同步从节点可以通过全量复制和增量复制两种方式与主节点进行数据同步。
全量复制通过复制整个数据库来初始化从节点，而增量复制则仅复制主节点的增量数据变更。
4. 角色切换在主从复制方案中，当主节点发生故障或者需要维护时，需要手动将某个从节点切换为主节点，保证系统的可用性。
切换过程需要修改从节点的配置文件并重启该节点。
三、哨兵模式1. 配置哨兵节点在Redis的配置文件中，配置哨兵节点的ip地址和端口号，并指定监控的主节点信息。
哨兵节点会周期性地检测主从节点的健康状态，当主节点宕机或不可用时，会通过选举机制自动将某个从节点切换为新的主节点。
2. 监控主从节点哨兵节点通过发送PING命令和PONG回复来监控主从节点的健康状态。
当主节点长时间无法回复PING命令时，哨兵节点将主节点标记为主观下线。
3. 主节点切换当主节点被标记为主观下线后，哨兵节点会执行选举过程，选出一个新的主节点，并将其他从节点切换至新的主节点。
系统故障解决方案之容灾与高可用架构容灾与高可用架构是系统故障解决方案中重要的组成部分。
在今天依赖计算机系统的信息时代，系统故障可能导致严重的业务中断和数据丢失，因此采取有效的容灾与高可用架构是保障系统稳定运行和数据安全的关键。
一、容灾与高可用架构概述容灾（Disaster Recovery）是指在系统遭受硬件故障、软件故障、自然灾害等不可预测事件影响后，能够快速恢复系统正常运行状态。
高可用（High Availability）则是指系统能够在故障发生时保持连续运行，确保业务持续性和可用性。
容灾与高可用架构则是为实现系统的容灾与高可用而构建的技术架构。
它通过使用冗余系统、负载均衡、故障转移等技术手段，确保系统在发生故障时能够自动切换到备份系统或备用设备上，从而快速恢复服务，确保业务不中断。
二、容灾与高可用架构的实现方式1. 冗余备份：通过备份系统、数据冗余、硬件冗余等方式进行备份与冗余，确保系统在关键组件或设备故障时能够无缝切换到备用设备上，减少业务中断时间。
2. 负载均衡：通过将用户请求分发到多个服务器上，平衡系统的负载，避免单点故障导致系统崩溃。
常见的负载均衡方式包括DNS轮询、硬件负载均衡器等。
3. 故障转移：将主要服务运行在主节点上，备份服务运行在备用节点上，通过实时监测主节点状态，一旦主节点发生故障，备用节点可以自动接管并提供服务，实现故障的快速切换。
4. 数据同步与备份：建立数据同步机制，确保主节点上的数据可以实时或定时地同步到备用节点上，保障数据的一致性和完整性。
同时，将数据备份至远程或离线存储，防止数据丢失。
5. 分布式系统：通过将系统拆分成多个独立的子系统，各个子系统运行在不同的服务器上，实现资源的分布和负载的均衡，提高系统的可用性和可扩展性。
三、容灾与高可用架构的应用场景容灾与高可用架构广泛应用于关键业务、金融、电子商务、互联网等领域，以确保系统的稳定运行和业务的连续性。
1. 数据中心：大型数据中心通常采用多层架构来实现容灾与高可用性。
redis灾备方案简介：Redis是一种常用的Key-Value存储系统，具有高性能、高可用等特点。
然而，Redis服务器也存在着风险，例如硬件故障、网络中断、数据丢失等。
为了应对这些风险，本文将介绍redis灾备方案。
1.数据备份Redis使用快照和AOF两种方式进行数据备份。
1.1 快照备份快照备份是通过将Redis服务器当前内存中的数据保存到磁盘上的RDB文件中来实现的。
该备份方式具有高效、可控性强的特点。
定期进行快照备份，以保证数据在出现灾难时能够及时恢复。
1.2 AOF备份AOF备份是通过将Redis服务器接收到的每个写操作追加到AOF文件中来实现的。
该备份方式具有实时性强、恢复速度快的特点。
建议将AOF备份与快照备份结合使用，以保证数据的持久性和可靠性。
2.容灾方案为了保证在出现服务器故障时能够快速切换到备用服务器，我们可以使用以下两种容灾方案：2.1 主从备份通过设置Redis的主从复制，将主服务器的数据实时复制到从服务器中。
当主服务器发生故障时，从服务器可以立即接替主服务器的工作。
这种方案的优点是容灾性强，但是如果主服务器的数据发生错误，从服务器也会同步错误。
2.2 Sentinel哨兵Sentinel是Redis的哨兵系统，旨在监控Redis实例的状态。
当主服务器发生故障时，哨兵会自动将从服务器提升为主服务器，保证系统的高可用性。
哨兵可以配置多个节点，以实现多主多从的情况下的灾备切换。
3.跨数据中心备份在分布式系统中，为了应对区域性灾难，可以将Redis服务器部署在多个数据中心中，实现跨数据中心备份。
跨数据中心备份的关键是数据同步和数据一致性的保证。
可以使用开源工具如Twemproxy、Codis等来实现数据的同步和负载均衡。
4.监控与预警为了及时发现和处理问题，我们需要对Redis服务器进行监控和预警。
可以使用工具如Redis Monitor、Redis Sentinel、Zabbix等进行监控，并及时设置预警规则，一旦发现异常情况立即报警。
高可用性方案随着社会的发展和科技的进步，对于计算机系统的高可用性要求越来越高。
高可用性方案是指在计算机系统运行过程中，通过配置硬件和软件的方式，以达到减少系统故障或服务中断时间的目标。
本文将介绍几种常见的高可用性方案。
一、冗余备份冗余备份是一种常见的高可用性方案，通过将系统组件复制多份，并将其配置在不同的物理位置，以防止个别组件故障导致整个系统的中断。
常见的冗余备份方案包括主备份和集群。
主备份是指将系统的主要组件和数据复制到备份设备上，在主设备发生故障时，自动切换到备份设备上继续提供服务。
这种方案可以有效地减少系统中断时间，并且实现快速自动切换。
集群是指将多台服务器组成一个集群，在集群内实现资源共享和故障转移。
当集群中的一台服务器发生故障时，其他服务器可以接管其任务，保证系统的持续运行。
集群方案可以提高系统的可靠性和可扩展性。
二、负载均衡负载均衡是一种通过分发系统的负载来实现高可用性的方案。
负载均衡可以将请求分发到多个服务器上，以避免单个服务器过载。
常见的负载均衡方案包括DNS负载均衡和硬件负载均衡。
DNS负载均衡是指通过DNS服务器将请求分发到不同的服务器上。
当用户访问一个域名时，DNS服务器会根据一定的策略将用户的请求转发到不同的服务器上。
这种方案可以提高系统的可用性和性能。
硬件负载均衡是一种通过使用专门的硬件设备来实现负载均衡的方案。
这种方案可以有效地分发系统的负载，并且具有高可靠性和高性能的特点。
三、容灾备份容灾备份是一种通过配置备份系统来实现高可用性的方案。
容灾备份可以将主要系统的备份数据和配置文件存储在其他位置，以防止主要系统发生故障时数据的丢失。
常见的容灾备份方案包括远程备份和异地备份。
远程备份是指将数据和配置文件复制到远程的备份系统上。
当主要系统发生故障时，可以从备份系统恢复数据，并继续提供服务。
这种方案可以减少数据的损失，并且可以在较短的时间内恢复系统。
异地备份是指将备份系统部署在与主要系统不同的地理位置。
redis容灾方案Redis作为一种高性能的内存数据库，在很多互联网公司中得到了广泛的应用，但是由于Redis本身是单节点的架构，一旦节点宕机就会影响到整个系统的正常运行。
因此，为保证Redis集群的高可用性，我们需要采取相应的容灾方案。
Redis容灾方案主要有以下几种：1. Redis SentinelRedis Sentinel是Redis官方提供的高可用性解决方案，它通过监控Redis节点的状态来实现自动故障转移。
当主节点宕机时，Sentinel会自动将从节点升级为新的主节点，从而保证整个集群的可用性。
Sentinel集群至少需要3个节点，其中一个为主节点，其他为从节点。
Sentinel使用哨兵模式来监视Redis节点的状态，哨兵之间通过发送ping/pong信息来保持通信，从而实现集群的高可用性。
2. Redis ClusterRedis Cluster是Redis官方提供的分布式解决方案，它可以将多个节点组合成一个集群，通过分片存储和节点自动发现等机制实现数据的高可用性和负载均衡。
Redis Cluster至少需要3个主节点和3个从节点，其中每个主节点都需要有一个从节点作为备份。
Redis Cluster采用哈希分区的方式将数据分散到多个节点中，实现负载均衡和故障转移。
3. 第三方解决方案除Redis Sentinel和Redis Cluster外，还有一些第三方提供的Redis 容灾方案，比如Twemproxy、codis等。
这些方案可以根据具体业务需求进行选择，有些方案可以提供比Redis Sentinel和Redis Cluster 更加灵活和高效的容灾解决方案。
无论采用哪种Redis容灾方案，都需要注意以下几点：1. 节点数量不要过少，推荐不少于3个节点。
2. 不同节点要避免使用相同的硬件和物理位置，以防出现单点故障。
3. 配置文件要进行合理的配置，包括节点的网络连接、主从节点的角色等。
redis主从备份原理Redis主从备份原理什么是Redis主从备份Redis主从备份是一种数据复制技术，用于将Redis数据库中的数据从一个主节点复制到一个或多个从节点，以提供数据冗余和高可用性。
为什么需要Redis主从备份•数据冗余：通过备份数据到从节点，即使主节点崩溃，数据也不会丢失。
•负载均衡：通过将读操作分发到多个从节点，可以减轻主节点的负载。
•高可用性：当主节点崩溃时，从节点可以自动接管成为新的主节点，避免业务中断。
主从备份的原理1.客户端向主节点发送写入命令。
2.主节点将写入命令记录到本地日志（AOF日志或RDB快照）中，并执行命令。
3.主节点将执行后的命令通过网络发送给从节点。
4.从节点接收到命令后，将命令写入本地日志，并执行命令。
5.客户端向主节点发送读取命令。
6.如果读取命令是只读操作，则主节点可以直接返回结果给客户端。
7.如果读取命令是写操作，则主节点将写操作发送给从节点。
8.从节点执行写操作后，将结果返回给主节点。
9.主节点将结果返回给客户端。
主从备份的配置步骤1.启动Redis主节点。
2.配置从节点的Redis配置文件，设置slaveof指令将从节点连接到主节点。
3.启动Redis从节点。
4.验证主从节点是否成功连接，可以通过redis-cli工具的INFOreplication命令查看复制信息。
主从备份的常用配置参数•repl-diskless-sync：在复制过程中，从节点是否将数据存储在磁盘中。
•repl-backlog-size：保存主节点复制缓冲区的大小，用于在从节点断开连接后重新连接时进行数据补偿。
•repl-timeout：主节点等待从节点回复的超时时间。
•slave-read-only：从节点是否只允许读操作。
注意事项•主从备份只会复制数据，不会复制主节点的配置信息。
•主从备份是异步进行的，从节点可能与主节点有一定的延迟。
•主节点的崩溃可能会导致一段时间内的数据丢失，因此需要使用AOF日志或RDB快照来提高数据的持久性。
redis高可用方案
目录
1. 介绍redis高可用方案
1.1 什么是redis高可用方案
1.2 为什么需要redis高可用方案
2. 主从复制
2.1 主从复制原理
2.2 主从复制的优缺点
3. 哨兵模式
3.1 哨兵模式原理
3.2 哨兵模式的作用
4. 集群模式
4.1 集群模式原理
4.2 集群模式的优势
介绍redis高可用方案
redis高可用方案是针对redis单节点可能出现的故障或性能瓶
颈而设计的一种解决方案。
通过一些机制保证redis服务的稳定性和
可靠性，确保数据的安全和连续性。
主从复制
主从复制是redis中一种常见的高可用方案，通过将主节点的数
据复制到多个从节点，实现数据的备份和读写分离，提高系统的性能
和扩展性。
主从复制可以实现简单的容灾备份和高并发读取。
哨兵模式
哨兵模式是redis提供的一种自动化的高可用解决方案，通过监
控redis节点的运行状态，自动进行故障转移和故障恢复，确保系统
的稳定性和可靠性。
哨兵模式可以实现主节点的自动选举和故障恢复，减少了人工干预的需求。
集群模式
集群模式是redis用来实现分布式存储和高可用性的一种方案，
通过将数据分片存储在多个节点上，实现数据的均衡和高性能的访问。
集群模式可以有效提高redis的吞吐量和扩展性，满足大规模数据存
储和访问的需求。
Redis 备份、容灾及高可用方案
一，Redis简单介绍
Redis是一个高性能的key-value非关系型数据库，由于其具有高性能的特性，支持高可用、持久化、多种数据结构、集群等，使其脱颖而出，成为常用的非关系型数据库。
此外，Redis的使用场景也比较多。
我们常通过Reids的队列功能做购买限制。
比如到节假日或者推广期间，进行一些活动，对用户购买行为进行限制，限制今天只能购买几次商品或者一段时间内只能购买一次。
也比较适合适用。
4.排名
Redis在内存中对数字进行递增或递减的操作实现得非常好。
所以我们在很多排名的场景中会应用Redis来进行，比如小说网站对小说进行排名，根据排名，将排名靠前的小说推荐给用户。
5.发布/订阅
Redis提供发布和订阅功能，发布和订阅的场景很多，比如我们可以基于发布和订阅的脚本触发器，实现用Redis的发布和订阅功能建立起来的聊天系统。
此外还有很多其它场景，Redis都表现的不错。
二，Redis使用中单点故障问题
正是由于Redis具备多种优良特新，且应用场景非常丰富，以至于Redis在各个公司都有它存在的身影。
那么随之而来的问题和风险也就来了。
Redis虽然应用场景丰富，但部分公司在实践Redis应用的时候还是相对保守使用单节点部署，那为日后的维护带来了安全风险。
在2015年的时候，曾处理过一个因为单点故障原因导致的业务中断问题。
当时的Redis都未采用分布式部署，采用单实例部署，并未考虑容灾方面的问题。
当时我们通过Redis服务器做用户购买优惠商品的行为控制，但后来由于未知原因Redis节点的服务器宕机了，导致我们无法对用户购买行为进行控制，造成了用户能够在一段时间内多次购买优惠商品的行为。
这种宕机事故可以说已经对公司造成了不可挽回的损失了，安全风险问题非常严重，作为当时运维这个系统的我来说有必要对这个问题进行修复和在架构上的改进。
于是我开始了解决非分布式应用下Redis单点故障方面的研究学习。
三，非分布式场景下Redis应用的备份与容灾
Redis主从复制现在应该是很普遍了。
常用的主从复制架构有如下两种架构方案。
常用Redis主从复制
方案一
这是最常见的一种架构，一个Master节点，两个Slave节点。
客户端写数据的时候是写Master 节点，读的时候，是读取两个Slave，这样实现读的扩展，减轻了Master节点读负载。
这种架构同样是一个Master和两个Slave。
不同的是Master和Slave1使用keepalived进行VIP转移。
Client连接Master的时候是通过VIP进行连接的。
避免了方案一IP更改的情况。
Redis主从复制优点与不足
∙优点
1.实现了对master数据的备份，一旦master出现故障，slave节点可以提升为新的master，
顶替旧的master继续提供服务
2.实现读扩展。
使用主从复制架构，一般都是为了实现读扩展。
Master主要实现写功能， Slave
实现读的功能
架构方案一
当Master出现故障时，Client就与Master端断开连接，无法实现写功能，同时Slave也无法从Master进行复制。
架构方案二
当master出现故障后，Client可以连接到Slave1上进行数据操作，但是Slave1就成了一个单点，就出现了经常要避免的单点故障(single point of failure)。
之后需要经过如下操作：
可以发现，无论是哪种架构方案都需要人工干预来进行故障转移(failover)。
需要人工干预就增加了运维工作量，同时也对业务造成了巨大影响。
这时候可以使用Redis的高可用方案-Sentinel
四，Redis Sentinel介绍
Redis Sentinel为Redis提供了高可用方案。
从实践方面来说，使用Redis Sentinel可以创建一个无需人为干预就可以预防某些故障的Redis环境。
Redis Sentinel设计为分布式的架构，运行多个Sentinel进程来共同合作的。
运行多个Sentinel进程合作，当多个Sentinel同一给定的master无法再继续提供服务，就会执行故障检测，这会降低误报的可能性。
五，Redis Sentinel功能
Redis Sentinel在Redis高可用方案中主要作用有如下功能：
∙监控
Sentinel会不断的检查master和slave是否像预期那样正常运行
∙通知
通过API，Sentinel能够通知系统管理员、程序监控的Redis实例出现了故障∙自动故障转移
如果master不像预想中那样正常运行，Sentinel可以启动故障转移过程，其中的一个slave 会提成为master，其它slave会重新配置来使用新的master，使用Redis服务的应用程序，当连接时，也会被通知使用新的地址。
配置提供者
Sentinel可以做为客户端服务发现的认证源：客户端连接Sentinel来获取目前负责给定服务的Redis master地址。
如果发生故障转移，Sentinel会报告新的地址。
Sentinel集群对自身和Redis主从复制进行监控。
当发现Master节点出现故障时，会经过如下步骤：∙1）Sentinel之间进行选举，选举出一个leader，由选举出的leader进行failover
∙2）Sentinel leader选取slave节点中的一个slave作为新的Master节点。
对slave选举需要对slave进行选举的方法如下：
a) 与master断开时间
如果与master断开的时间超过down-after-milliseconds(sentinel配置）* 10秒加上从sentinel判定master不可用到sentinel开始执行故障转移之间的时间，就认为该slave不适合提升为master。
b) slave优先级
每个slave都有优先级，保存在redis.conf配置文件里。
如果优先级相同，则继续进行。
c) 复制偏移位置
复制偏移纪录着从master复制数据复制到哪里，复制偏移越大表明从master接受的数据越多，如果复制偏移量也一样，继续进行选举
d) Run ID
选举具有最小Run ID的Slave作为新的Master
流程图如下：
∙3) Sentinel leader会在上一步选举的新master上执行slaveof no one操作，将其提升为master节点
∙4）Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave ∙5）Sentinel leader会让原来的master降级为slave，当恢复正常工作，Sentinel leader会发送命令让其从新的master进行复制
以上failover操作均有sentinel自己独自完成，完全无需人工干预。
总结
使用sentinel实现了Redis的高可用，当master出现故障时，完全无需人工干预即可实现故障转移。
避免了对业务的影响，提高了运维工作效率。
在部署sentinel的时候，建议使用奇数个sentinel节点，最少三个sentinel节点。
