前言
- 我们都知道Redis是一个很优秀的缓存框架,很大程度上提高了我们获取数据的效率,然而在现在的互联网环境下,Redis存储的数据有限,并且为了保证高可用性,我们得想办法来保证Redis能够一直高效的运转,使得我们的请求到达时,能快速并且准确的返回我们需要的数据,所以我们得做集群,保证随时都有一个Redis服务可用
- 为什么Redis要做集群,总结下来有以下三点
【1】解决单点故障问题,保证随时都有一个Redis服务可用
【2】处理高并发的读写请求,提高Redis的作业能力
【3】Redis容量有限,部署多个Redis节点来存储更多数据
Redis集群的三种方案
- 前面说到为什么要对Redis做集群,现在就来说说Redis的集群方案
【1】主从复制
【2】哨兵模式
【3】cluster集群
一、主从复制
- 将一台Redis服务器的数据复制到另一台Redis服务器中,前者称为主节点(Master),后者称为从节点(Slave)。
- 数据的复制是单向的,只能从主节点复制到从节点
- 主和从之间是一对多的关系,一个主节点可以有多个从节点(或者没有),一个从节点只能有一个主节点
- 主节点可以进行读写操作,主要是写操作,从节点只能进行读操作
Redis主从复制原理
- 从服务器连接主服务器,发送SYNC命令;
- 主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令;
- 主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令;
- 从服务器收到快照文件后丢弃所有旧数据,载入收到的快照;
- 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令;
- 从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;
全量同步
- 简单来说就是第一次复制主节点时,从节点会加载主节点的快照信息,并且执行写命令,也就是上述的第四步
增量同步
- 简单来说就是从节点执行完主节点的快照后,同步的进行主节点的写操作,也就是上述的第六步
主从复制的作用
-
数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
-
故障恢复:当主节点出现问题时可以由从节点提供服务实现快速的故障恢复;实际上是一种服务的冗余
-
负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
-
读写分离:可以用于实现读写分离,主库写、从库读,读写分离不仅可以提高服务器的负载能力,同时可根据需求的变化,改变从库的数量。
-
高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。
二、哨兵模模式
- 主服务器服务中断之后,选择一个从服务器担任主服务器,以前是人工手动,Redis2.8提供了哨兵
哨兵(Redis-Sentinel)的三个作用
- 监控(Monitoring):哨兵会一直检查主服务器和从服务器是否正常运作,通过PING的方式
- 提醒(Notification):当发现某个服务不正常时,会通过API向管理员或者其他应用程序发送信息
- 自动故障迁移(Automatic failover) :当主服务器不可用时,哨兵会选举一个从服务器作为主服务器,让其他从服务器从新的主服务器中复制数据,并让用户请求发送到新的主服务器中
哨兵的原理
- 更详细的参考Redis哨兵sentinel深入分析
主观下线
- 每个哨兵(Sentinel)以1次/秒的频率PING主服务器,从服务器和其他哨兵
- 如果一个实例(主服务器,从服务器和其他哨兵)最后一个恢复PING的时间超过了down-after-milliseconds 的值,这个实例会被哨兵标记为主观下线(SDOWN)
- 发现主服务器主观下线的这个哨兵会通过发布订阅的方式通知其他哨兵去PING主服务器(给其他哨兵节点发送is-master-down-by-addr命令)
客观下线
- 当有超过一半并且大于等于quorum(用这个命令配置sentinel monitor )的哨兵认为主节点主观下线,那么主节点就会标记为客观下线
- 没有足够数量的哨兵认为主服务器客观下线,那么就会移除主服务器客观下线状态
- 主服务器在有效时间内回复了哨兵的PING,那么就会移除主服务器的主观下线状态
故障转移
- 确定主服务已经客观下线之后就要进行故障恢复,也就是选举一个从服务器作为主服务器
- 为了保证只有一个哨兵进行故障恢复,会在哨兵之间进行Leader选举,选择一个领头哨兵,如果有选出两个最高票的会重新选举
- 领头哨兵选出从服务器之后通过slaveif no ont将该从服务器升为新主服务器
- 从服务器成为主服务器的规则是:
(1)在所有从数据库中选择优先级最高的,优先级通过replica-priority参数设置
(2)优先级相同,则复制的命令偏移量越大(复制越完整)越优先
(3)如果以上都一样,则选择运行ID(PID)较小的从数据库 - 领头哨兵向其他从数据库发送 SLAVEOF命令来使其成为新主数据库的从数据库
- 最后一步则是更新内部的记录,将已经停止服务的旧的主数据库更新为新的主数据库的从数据库,使得当其恢复服务时自动以从数据库的身份继续服务
哨兵的优点
- 哨兵基于主从,有主从所有优点
- 主从可以切换,可用性和健壮性更高
哨兵的缺点
- 主从数据要经常复制,性能低
- 更换主从时,集群不可用
- 在线扩容复杂
Redis-Cluster集群
- Redis-Cluster采用无中心结构,集群中的每个节点都是平等的关系,都是对等的,每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接,而且这些连接保持活跃,这样就保证了我们只需要连接集群中的任意一个节点,就可以获取到其他节点的数据。
为什么要使用Redis-Cluster集群?
- Redis的哨兵模式已经基本实现了高可用和读写分离,但是每台服务器中存储的数据是相同的,对内存空间造成了极大的浪费。
- Redis3.0使用了Redis-Cluster集群,实现了Redis的分布式存储,每个节点中存储的数据都不相同
那么问题来了,我怎么知道数据到底存到那个Redis节点上呢?
- Redis 集群没有并使用传统的一致性哈希来分配数据,而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的
- redis cluster 默认分配了 16384 个slot,当我们set一个key 时,会用CRC16算法来取模得到所属的slot,然后将这个key 分到哈希槽区间的节点上,具体算法就是:CRC16(key) % 16384
- 这些槽位是平均分配给master节点的,slave节点中是没有的
万一某个节点宕机了,存在哪个节点的数据怎么办呢?
- 为了防止主节点数据丢失,可以为每个主节点可以准备特定数目的备节点,主节点挂掉从节点可以升级为主节点(哨兵模式) 。
- 容错机制指的是,如果半数以上master节点与故障节点通信超过(cluster-node-timeout),认为该节点故障,自动触发故障转移操作. 故障节点对应的从节点自动升级为主节点 , 如果某个主挂掉,而没有从节点可以使用,那么整个Redis集群进入宕机状态
Redis集群搭建
- 了解了以上三种集群模式,我们就在本地搭建集群
环境准备
- Redis3.2 高版本的可能搭不起来,搭之前要关闭Redis服务
- 准备6个Redis服务器作为节点,端口分别是6380-6385(随意指定,不被占用即可)
- Ruby,使用Ruby脚本为我们搭建集群
Redis集群安装
Redis配置
- 准备一个文件夹,用于放置所有的集群
- 解压Redis3.2的安装包,为了方便,直接以端口号命名
- 修改
redis.windows.conf 文件- 端口号 :port
- 开启集群 :cluster-enabled yes
- 集群配置文件:cluster-config-file nodes-端口号.conf
- 指定超时:cluster-node-timeout 15000
- 开启持久化:appendonly yes
【注意】只截取了一部分,配置要顶格,否则可能不生效
- 在安装目录下(和redis.windows.conf平级)创建启动脚本start.bat(需要自己创建这个文件),内容如下(按照如下格式换行)
title redis
redis-server.exe redis.windows.conf
- 修改完一个服务之后再复制,这样只需要修改文件名,redis.windows.conf中的port和cluster-config-file nodes-端口号.conf。
安装Ruby
- rubyinstaller-2.6.3-1-x64.exe 傻瓜式安装即可
安装Ruby驱动
- 解压rubygems-3.0.6
- 进入根目录,cmd执行
ruby setup.rb
- 在Redis(6380)服务的根目录执行
gem install redis
【注意】如果迟迟没反应,切换国内镜像
#删除源
gem source -r https://rubygems.org/
#添加源
gem sources --add https://gems.ruby-china.com
执行集群构建脚本
- 分别点击6个Redis中的start.bat文件,将6个Redis启动起来
- 将
redis-trib.rb 文件拷贝到Redis(6380)的根目录下 - 在Redis(6380)的根目录下进入cmd,执行以下脚本
redis-trib.rb create --replicas 1 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 127.0.0.1:6385
遇到 Can I set the above configuration? (type ‘yes’ to accept): 输入
就可以看到集群的加入了
测试集群
- 启动客户端,进入任意一台服务的根目录,cmd执行
redis-cli.exe –c –h 127.0.0.1 –p 6380 - 查看这个集群的信息:
cluster info - 查看当前Redis:
info replication - 查看槽位:
cluster nodes
【分析】虽然进入的是6883,但是启动的是6380,所以进入的是6380那个Redis的命令行,当前这个Redis还是6383,并且可以看到master有三个,分别是6380,6381,6382;slave也有三个,分别是6383,6384,6385。和他们的槽位信息(槽位前面提到过,总共是16384位,平均分配到master节点中)
测试数据
- 可以看到,不同值存在了不同的Redis节点上
- 获取值的时候也是如此
在SpringBoot项目中使用Redis集群
- yml配置
spring: redis: #单机模式=============================================================== # database: 0 # 默认数据库 # host: 127.0.0.1 # Redis的Ip # port: 6379 # Redis的端口 # password: 123456 # Redis的秘密 # jedis: # Redis连接池配置,避免连接重复的创建和销毁 # pool: # max-wait: 2000ms # 连接最大等待毫秒数, 单位为 ms, 超过时间会出错误信息 # max-active: 8 # 连接池的最大数据库连接数。设为0表示无限制 #======================================================================== #哨兵模式=============================================================== # database: 1 # password: 123456 # jedis: # Redis连接池配置,避免连接重复的创建和销毁 # pool: # max-wait: 2000ms # 连接最大等待毫秒数, 单位为 ms, 超过时间会出错误信息 # max-active: 8 # 连接池的最大数据库连接数。设为0表示无限制 # sentinel: # master: my-master # nodes: 127.0.0.1:6380,127.0.0.1:6381,127.0.0.1:6382 #======================================================================== #集群模式=============================================================== password: 123456 jedis: # Redis连接池配置,避免连接重复的创建和销毁 pool: max-wait: 2000ms # 连接最大等待毫秒数, 单位为 ms, 超过时间会出错误信息 max-active: 8 # 连接池的最大数据库连接数。设为0表示无限制 cluster: nodes: - 127.0.0.1:6380 - 127.0.0.1:6381 - 127.0.0.1:6382 - 127.0.0.1:6383 - 127.0.0.1:6384 - 127.0.0.1:6385 #========================================================================
- Redisson配置类
@Configuration public class RedissonConfig { //创建客户端 @Bean public RedissonClient redissonClient(){ Config config = new Config(); //config.useSingleServer().setAddress("redis://127.0.0.1:6379").setPassword("123456"); config.useClusterServers() .addNodeAddress("redis://127.0.0.1:6380","redis://127.0.0.1:6381","redis://127.0.0.1:6382","redis://127.0.0.1:6383","redis://127.0.0.1:6384","redis://127.0.0.1:6385") .setPassword("123456"); return Redisson.create(config); } }