文章目录概念主从复制的作用主要包括主从复制环境配置主从复制绑定操作主从复制的同步过程宕机后的处理策略哨兵模式哨兵模式的三个作用哨兵的工作方式开启哨兵测试哨兵模式哨兵模式的优点哨兵模式配置详解哨兵模式与集群模式的核心区别应用场景-哨兵模式应用场景-集群模式概念主从复制是指将一台Redis服务器的数据复制到其他的Redis服务器。前者称为主节点(master/leader),后者称为从节点(slave/follower);数据的复制是单向的只能由主节点到从节点。Maste以写为主Slave以读为主。默认情况下每台Redis服务器都是主节点且一个主节点可以有多个从节点(或没有从节点)但一个从节点只能有一个主节点。主从复制的作用主要包括1、负载均衡在主从复制的基础上配合读写分离可以由主节点提供写服务由从节点提供读服务分担服务器负载尤其是在写少读多的场景下通过多个从节点分担读负载可以大大提高Redis服务器的并发量及效率。2、数据冗余主从复制实现了数据的热备份是持久化之外的一种数据冗余方式。3、故障恢复当主节点出现问题时可以由从节点提供服务实现快速的故障恢复;实际上是一种服务的冗余。4、高可用基石除了上述作用以外主从复制还是哨兵和集群能够实施的基础因此说主从复制是Redis高可用的基础。一般来说要将Redis运用于工程项目中只使用一台Redis是万万不能的原因如下1、从结构上单个Redis服务器会发生单点故障并且一台服务器需要处理所有的请求负载压力较大2、从容量上单个Redis服务器内存容量有限就算一台Redis服务器内存容量为256G ,也不能将所有内存用作Redis存储内存一般来说单台Redis最大使用内存不应该超过20G.电商网站上的商品一般都是一次上传无数次浏览的,说专业点也就是“多读少写对于这种场景我们可以使如下这种架构主从复制环境配置查看主机信息我们这里只有一台服务器所以就只复制redis.conf通过启动不同的配置文件来模拟多台机器现实场景大家就可以在不同的服务器上都安装redis然后启动再配置即可。原理是一样的。首先我们复制多份redis.conf修改每个配置文件以redis80.conf为例1.bind监听的地址2.端口号3.开启后台启动4.pid文件保存位置5.日志文件保存位置6.rbd文件保存位置修改文件保存位置是为了防止文件被覆盖,如果redis在不同的服务器上那么上面大部分配置都不用修改修改完成指定配置文件启动各个redis服务redis -server /配置文件目录/redis6380.conf redis -server /配置文件目录/redis6381.conf redis -server /配置文件目录/redis6379.conf主从复制绑定操作方式1命令绑定slaveof ip prot 指定主节点redis所在的ip与端口该方式配置主从关系后假如从机宕机后再启动那么从机丢失之前的主从关系变成默认的主机而主机宕机后依旧保持原来的主从关系。方式2通过配置文件该方式配置的主从关系是永久的就算从机宕机后恢复那么它依然是从机。不会丢失主从关系。主从测试主机插入数据从机读取数据从机插入数据会报错默认从机只能读不能写。可以在配置文件中开启非只读:slave-read-only no主从复制的同步过程1.从节点启动成功连接到主节点后会发送一个sync命令2.主节点接到sync命令后启动一个子线程根据缓存中的数据生产一份持久化文件同时收集所有接收到的用于修改数据集命令。3.主节点的bgsave执行完成后将持久化文件发送给从节点从节点首先清除自己的旧数据然后载入接收的持久化文件将数据库状态更新至主节点执行bgsave时的数据库状态。全量同步根据主节点中的数据生产持久化文件从节点执行持久化文件完成全量同步。ps:从节点每次连接主节点都是一次全量同步增量同步Master继续将新的所有收集到的修改命令依次传给slave完成同步宕机后的处理策略手动版反客为主1.如果主节点宕机那么剩下的从节点是没办法写操作的那么此时可通过执行slaveof no one命令指定一台从节点转为主节点。来解决不能写的问题然后再更改其它从节点指向6381为主节点即可(ps此时原来的6379就算恢复那么手下也没有从节点了。)哨兵模式目的哨兵模式就是为了在主从复制模式下主节点发生问题时自动选举新的主节点自动修改主从配置提高redis可用性。概述自动版反客为主Redis的主从复制模式下 一旦主节点由于故障不能提供服务 需要人工将从节点晋升为主节点 同时还要通知其他从节点更新主节点地址 对于很多应用场景这种故障处理的方式是无法接受的。于是redis从2.8开始正式提供了Redis Sentinel哨兵 架构来解决这个问题。简单来说哨兵模式其实就是自动版的反客为主当主节点故障后会自动投票在剩下的从节点中选择一个从节点晋升成主节点。哨兵模式每个哨兵都是一个独立的进程哨兵会向被监控的主节点不断发送心跳验证来监测主节点是否正常运行。哨兵模式的三个作用监测通过发送命令让redis服务器返回当前运行的状态故障转移当哨兵监测的主节点宕机就会通过投票的方式自动选择一个从节点升级为主节点然后通过发布订阅模式通知其他redis服务器修改配置文件重新认主节点。通知当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。然而一个哨兵监控redis可能出现问题因此可以引入哨兵集群哨兵的工作方式**持续监控**每个哨兵节点会以每秒一次的频率向所有被监控的主节点、从节点以及其他哨兵节点发送 PING 命令。– 通信方式哨兵与 Redis 服务器建立 TCP 长连接通过发送心跳包来检测对方是否存活。**主观下线**当一个哨兵节点在规定时间由 down-after-milliseconds 配置项决定默认30秒内没有收到某个实例的有效 PONG 响应或其他有效回复如 -LOADING该哨兵就会独自将这个实例标记为“主观下线”。**客观下线**为了防止误判它会通过 SENTINEL is-master-down-by-addr 命令向其他哨兵节点发起询问集群中所有的哨兵都会向出问题的节点发生ping命令当超过法定数量Quorum 的哨兵该数量在配置文件中定义都认为主节点下线时主节点才会被标记为“客观下线”。– 达成共识当超过法定数量Quorum 的哨兵该数量在配置文件中定义都认为主节点下线时主节点才会被标记为“客观下线”。主节点被确认为客观下线后哨兵集群需要选出一个“新的主节点”来执行后续的故障转移操作。这个选举过程基于 Raft 共识算法的变种实现。开启哨兵ps:开启哨兵前首先要进行主从配置只有这样哨兵在监视主节点时才会将从节点也纳入进来。目前我们设置的是一主二从创建并修改哨兵的配置文件sentinel.conf如果redis版本高的话默认会有这个配置文件。配置监测节点先配置最基本的后面会有进阶配置sentinel monitor 节点名随意起 redis节点地址 端口 投票权重投票权重如果主机宕机投票选举主节点时如果权重为1则相当于只能投一票。那个从节点得票最多则晋升主节点。启动哨兵进入redis bin目录里面有redis-sentinelredis-sentinel 指定哨兵配置文件的位置启动成功测试哨兵模式1.首先模拟主节点宕机关闭63792.等待哨兵打印监测日志根据上图可看到6379发生了故障然后执行故障转移到了6381并且修改了6380与6379的主从配置认6381为主节点。同时也会修改哨兵监测6381。3.观察各机状态638063816379此时6379已恢复状态但已经成为6381的从节点了哨兵模式的优点自动化的故障转移主从可以自动切换。哨兵模式配置详解# Example sentinel.conf # 哨兵sentinel实例运行的端口 默认26379 port 26379 # 哨兵sentinel的工作目录 dir /tmp # 哨兵sentinel监控的redis主节点的 ip port # master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符.-_组成。 # quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了 # sentinel monitor master-name ip redis-port quorum sentinel monitor mymaster 127.0.0.1 6379 2 # 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码 # 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码 # sentinel auth-pass master-name password sentinel auth-pass mymaster MySUPER--secret-0123passw0rd # 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒 # sentinel down-after-milliseconds master-name milliseconds sentinel down-after-milliseconds mymaster 30000 # 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步 这个数字越小完成failover所需的时间就越长 但是如果这个数字越大就意味着越 多的slave因为replication而不可用。 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。 # sentinel parallel-syncs master-name numslaves sentinel parallel-syncs mymaster 1 # 故障转移的超时时间 failover-timeout 可以用在以下这些方面 #1. 同一个sentinel对同一个master两次failover之间的间隔时间。 #2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。 #3.当想要取消一个正在进行的failover所需要的时间。 #4.当进行failover时配置所有slaves指向新的master所需的最大时间。不过即使过了这个超时slaves依然会被正确配置为指向master但是就不按parallel-syncs所配置的规则来了 # 默认三分钟 # sentinel failover-timeout master-name milliseconds sentinel failover-timeout mymaster 180000 # SCRIPTS EXECUTION #配置当某一事件发生时所需要执行的脚本可以通过脚本来通知管理员例如当系统运行不正常时发邮件通知相关人员。 #对于脚本的运行结果有以下规则 #若脚本执行后返回1那么该脚本稍后将会被再次执行重复次数目前默认为10 #若脚本执行后返回2或者比2更高的一个返回值脚本将不会重复执行。 #如果脚本在执行过程中由于收到系统中断信号被终止了则同返回值为1时的行为相同。 #一个脚本的最大执行时间为60s如果超过这个时间脚本将会被一个SIGKILL信号终止之后重新执行。 #通知型脚本:当sentinel有任何警告级别的事件发生时比如说redis实例的主观失效和客观失效等等将会去调用这个脚本 这时这个脚本应该通过邮件SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时将传给脚本两个参数 一个是事件的类型 一个是事件的描述。 如果sentinel.conf配置文件中配置了这个脚本路径那么必须保证这个脚本存在于这个路径并且是可执行的否则sentinel无法正常启动成功。 #通知脚本 # sentinel notification-script master-name script-path sentinel notification-script mymaster /var/redis/notify.sh # 客户端重新配置主节点参数脚本 # 当一个master由于failover而发生改变时这个脚本将会被调用通知相关的客户端关于master地址已经发生改变的信息。 # 以下参数将会在调用脚本时传给脚本: # master-name role state from-ip from-port to-ip to-port # 目前state总是“failover”, # role是“leader”或者“observer”中的一个。 # 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的 # 这个脚本应该是通用的能被多次调用不是针对性的。 # sentinel client-reconfig-script master-name script-path sentinel client-reconfig-script mymaster /var/redis/reconfig.sh哨兵模式与集群模式的核心区别哨兵模式一主多从主要避免单点故障集群模式多主多从拥有更高的高可用丶高并发丶水平拓展的能力。应用场景-哨兵模式1.适用于数据总量不超过单机内存。2.读多写少的场景一台主节点可以应对所有的改写操作因为只有一个主节点可以进行改写操作而且横向拓展多个主节点如果要提升性能只能升级机器本身的配置提升有限。应用场景-集群模式1.适用于海量的数据总量单个机器的内存不够存储需要通过哈希计算分片将数据分散到多个机器节点中拓展存储容量。2.qps很高的情况下单台主节点的改写操作成为性能瓶颈需要多个主节点同时进行改写操作且因为可以有多个主节点所以机器可以水平拓展。分片的原理将所有主节点分成若干哈希槽16384 然后通过哈希函数CRC16 计算出哈希值然后再对哈希槽的数量进行取模就能得到具体的分片槽位3.不支持多数据库 集群模式下只能使用 db0。4.集群模式下如果使用lua脚本要保证传入的key的分片槽位要在同一节点中。可以通过{}号包裹相同的前缀使其分配到同一节点中被{}号修饰过的key只会用{}内的内容进行分片计算。核心区别对比表格详细解释Redis 哨兵模式哨兵模式的核心是 “主从复制 哨兵机制”。架构一个主节点 负责处理所有写请求和部分读请求。一个或多个从节点 复制主节点的数据负责读请求起到负载均衡和备份的作用。一个哨兵集群 由多个哨兵进程组成它们不存储数据只负责监控所有Redis节点主、从的健康状况。当主节点宕机时哨兵会自动将一个从节点提升为新的主节点并让其他从节点复制新的主节点。同时它会通知客户端新的主节点地址。优点高可用 实现了自动化的故障转移服务在主机宕机后能快速恢复。读负载均衡 可以将读请求分发到多个从节点上。配置相对简单 概念清晰易于理解和部署。缺点写性能瓶颈 所有写操作都集中在单个主节点无法扩展写性能。存储瓶颈 每个节点都存储全量数据数据量受单机内存限制。故障转移期间数据丢失 使用异步复制在主节点宕机前未同步到从节点的数据会丢失。Redis 集群模式集群模式的核心是 “数据分片 主从复制 高可用”。架构数据分片 Redis集群将整个数据集划分为16384个哈希槽。这些槽被分配给多个主节点。例如一个3主节点的集群可能分配为Node1 (0-5460), Node2 (5461-10922), Node3 (10923-16383)。写入操作 当客户端要写入一个键值对时集群会对 key 进行 CRC16 校验并取模 16384计算出它属于哪个哈希槽然后将其存储到负责该槽的主节点上。这样写压力就被分散到了多个主节点。主从复制 每个主节点都有一个或多个从节点同步其数据。高可用 当某个主节点宕机时它的从节点会自动被提升为新的主节点继续服务它负责的那部分哈希槽。优点高性能 读写请求可以分散到不同节点真正实现了高性能的横向扩展。海量数据存储 数据分片使得可以突破单机内存限制存储超大规模数据。兼具高可用 内置了类似哨兵的故障转移能力。缺点架构复杂 部署和维护比哨兵模式复杂。客户端要求高 客户端需要支持集群协议能够正确处理重定向命令如 -MOVED。不支持多数据库 集群模式下只能使用 db0。事务/Lua脚本限制 涉及多个key的操作、事务和Lua脚本必须确保所有这些key都位于同一个节点即同一个哈希槽。通常使用哈希标签 来强制将一组key映射到同一个槽。如何选择选择哨兵模式当你的数据量不大在一台服务器内存范围内。你的业务是读多写少写操作的并发量还没有达到单台服务器无法处理的程度。你主要的需求是保证服务不中断即高可用。你希望架构简单易于管理。选择集群模式当你的数据量巨大一台服务器内存根本装不下。你面临高并发读写单台服务器已经成为性能瓶颈。你既需要高可用又需要横向扩展性能和存储容量。你的团队有能力管理和维护更复杂的分布式系统。