一、Redis-Sentinel(哨兵)
1、介绍
Redis-Sentinel是redis官方推荐的高可用性解决方案,
当用redis作master-slave的高可用时,如果master本身宕机,redis本身或者客户端都没有实现主从切换的功能。
而redis-sentinel就是一个独立运行的进程,用于监控多个master-slave集群,
自动发现master宕机,进行自动切换slave > master。
sentinel主要功能如下:
1. 不时的监控redis是否良好运行,如果节点不可达就会对节点进行下线标识
2. 如果被标识的是主节点,sentinel就会和其他的sentinel节点“协商”,如果其他节点也认为主节点不可达,
就会选举一个sentinel节点来完成自动故障转移
3. 在master-slave进行切换后,master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变,
即master_redis.conf中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换
2、工作原理
每个Sentinel以每秒钟一次的频率向它所知的Master,Slave以及其他 Sentinel 实例发送一个 PING 命令
如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel 标记为主观下线。
如果一个Master被标记为主观下线,则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
当有足够数量的 Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态, 则Master会被标记为客观下线
在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master,Slave发送 INFO 命令
当Master被 Sentinel 标记为客观下线时,Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
若没有足够数量的 Sentinel 同意 Master 已经下线, Master 的客观下线状态就会被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回复, Master 的主观下线状态就会被移除。
主观下线和客观下线
主观下线:Subjectively Down,简称 SDOWN,指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线:Objectively Down, 简称 ODOWN,指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后,得出的Master Server下线判断,然后开启failover.
SDOWN适合于Master和Slave,只要一个 Sentinel 发现Master进入了ODOWN, 这个 Sentinel 就可能会被其他 Sentinel 推选出, 并对下线的主服务器执行自动故障迁移操作。
ODOWN只适用于Master,对于Slave的 Redis 实例,Sentinel 在将它们判断为下线前不需要进行协商, 所以Slave的 Sentinel 永远不会达到ODOWN。
3、master宕机处理
如果master宕机,我们应该先选一个slave出来,让他成为新的master,其他redis都修改成这个新的master的slave,但是redis本身或者客户端都没有实现主从切换的功能,当然,人为地修改配置文件,实现上图的功能也是可以的,但是如果是在深夜,所有人都睡觉了呢,谁来修改配置信息?这个时候就可以使用redis的Sentinel功能了,它就是实现了,当发现master宕机,自动帮我们去修改其他redis配置文件,选举出一个新master。
4、Sentinel功能实现图
5、redis一些查看命令
1 | redis-cli info # 查看redis数据库信息 |
6、Redis主从配置
1 | 1.准备三个redis实例,一主两从 |
7、Redis Sentinel安装配置
1 | 1. Sentinel配置解析 |
二、redis分区和集群
1、什么是分区和集群
分区
分区是分割数据到多个Redis实例的处理过程,因此每个实例只保存key的一个子集。
分区可以让Redis管理更大的内存,Redis将可以使用所有机器的内存。如果没有分区,你最多只能使用一台机器的内存。
分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。集群
redis集群就是分区的一种的实现
2、为什么要用分区
- 并发问题
官方声称 redis 每秒可以执行10万条命令
但是假如业务需要每秒100万的命令执行呢(例如新浪微博某某明星出轨、官宣之类的)
- 数据量
当数据量太大的时候,一台服务器内存正常是16~256G,假如你的业务需要500G内存,怎么办?
- 解决方案
- 方案一:
配置一台超级牛逼的服务器,拥有超大内存和超强的cpu,
但是这么做的成本是非常高的,而且,万一这台机器宕掉了,那你的服务还不是全挂了。 - 方案二:
考虑分布式,加机器,把数据分到不同的位置,分摊集中式的压力,一堆机器做一件事。
- 方案一:
3、分区的数据分布理论
redis是一个非关系型数据库,它的存储是key-value形式的,
redis实例集群主要思想是将redis数据的key进行散列,通过hash函数特定的key会映射到指定的redis节点上
分布式数据库首要解决把整个数据集按照分区规则映射到多个节点的问题,即把数据集划分到多个节点上,每个节点负责整个数据的一个子集。
常见的分区规则有哈希分区和顺序分区。
4、顺序分区
假设我有三个节点,100个redis的数据,按照平均值(几乎是平均的),顺序分区的规则就是:
把1-33个数据 放在 node1
把34-66个数据 放在node2
把67-100个数据 放在node3
5、哈希分区
- 节点取余
例如按照节点取余的方式,分三个节点
1~100的数据对3取余,可以分为三类
余数为0
余数为1
余数为2
把余数为0的数据存到同一个节点
把余数为1的数据存到同一个节点
把余数为2的数据存到同一个节点
那么同样的分4个节点就是hash(key)%4,余数相同的存到同一个节点
节点取余的优点是简单,客户端分片直接是哈希+取余
- 一致性哈希
客户端进行分片,哈希+顺时针取余 - 虚拟槽分区
本文研究哈希分区之虚拟槽分区,因此下面单独来聊一聊
三、哈希分区之虚拟槽分区
1、介绍
Redis Cluster采用的就是虚拟槽分区
虚拟槽分区巧妙地使用了哈希空间,使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合,
这些整数就定义为槽(slot)。
Redis Cluster槽的范围是0 ~ 16383,即一共16384个槽。
槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展,
每个节点(redis实例)负责一定数量的槽。
2、虚拟槽图解
3、搭建redis cluster
redis支持多实例的功能,我们在单机演示集群搭建,需要6个实例,三个是主节点,三个是从节点,数量为6个节点才能保证高可用的集群。
1 | 1.准备6个节点,用于存储数据,分配槽位,每个节点的配置,如下,仅仅是端口的区别 |
参考地址
如果大家喜欢我的文章,可以关注个人订阅号。欢迎随时留言、交流。如果想加入微信群的话一起讨论的话,请加管理员简栈文化-小助手(lastpass4u),他会拉你们进群。