redis主从+哨兵

redis主从+哨兵,第1张

主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。 这不是一种推荐的方式,更多时候,我们优先考虑 哨兵模式

哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是 哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。

这里的哨兵有两个作用

然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。

用文字描述一下 故障切换(failover) 的过程。假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为 主观下线 。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover *** 作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为 客观下线 。这样对于客户端而言,一切都是透明的。

配置3个哨兵和1主2从的Redis服务器来演示这个过程。

首先配置Redis的主从服务器,修改redis.conf文件如下

主从服务器都需要配置

配置3个哨兵,每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinel.conf文件,copy一份进行修改

上述关闭了保护模式,便于测试。

单个Redis服务如果宕机的话,服务就不可用了,为了解决这种问题,redis也提供有集群服务。传统的Redis集群采用的主从复制模式,一般为一主多从,主节点有读写权限,但是从节点只有读的权限。主节点会定期将数据同步到从节点中,保证数据一致性的问题。这种集群方式在运行时存在一些问题:

Redis的哨兵机制就是解决主从复制存在缺陷(选举问题),解决问题保证我们的Redis高可用,实现自动化故障发现与故障转移。

要使用哨兵机制,除了启动Redis服务以外,还要启动哨兵服务来进行监控,会介绍详细步骤。哨兵服务的工作原理如下:

演示集群采用1主2从,采用伪集群,在一台虚拟机中启动,端口暂定6381、6382、6383,集群结构可以选择下面2种,因为数量较少,此次采用普通样式。

主节点配置文件和单机的时候一样,主要修改以下几点

基本和主节点差不多,但要加上 slaveof 配置和主节点账号密码。

哨兵配置文件是 sentinel.conf ,因为有3个redis服务,所以启动3个哨兵服务,对应的配置文件分别为: sentinel_26381.conf 、 sentinel_26382.conf 、 sentinel_26383.conf

Redis服务和哨兵服务都启动了,可以测试哨兵的自动选举了,将6381沙雕,等几秒,再查看6382,6382的主从信息

注意:这个时候如果去看redis的配置文件,会发现配置文件中已经自动改好了主节点为6383了;而且哨兵的配置文件中,也改了主节点为6383了。这些都是哨兵帮我们做的

因集群中已有了新主节点,所以6381再启动只能作为从节点。此时6381启动,需要在配置文件中加入主节点信息:

所谓的高可用,也叫 HA(High Availability),是分布式系统架构设计中必须考虑的因素之一,它是保证系统SLA的重要指标。Redis 高可用的主要有三种模式: 主从模式 哨兵模式和集群模式

Redis 提供了 Redis 提供了复制(replication)功能,当一台 redis 数据库中的数据发生了变化,这个变化会被自动地同步到其他的 redis 机器上去。

Redis 多机器部署时,这些机器节点会被分成两类,一类是主节点(master 节点),一类是从节点(slave 节点)。一般 主节点可以进行读、写 *** 作 ,而 从节点只能进行读 *** 作 。一个主节点可以有多个从节点,但是一个从节点只会有一个主节点,也就是所谓的 一主多从结构

· 支持主从复制,主机会自动将数据同步到从机,可以进行读写分离

· Master 是以非阻塞的方式为主 Slaves 提供服务。所以在 Master-Slave 同步期间,客户端仍然可以提交查询或修改请求

· Slave 同样是以非阻塞的方式完成数据同步。在同步期间,如果有客户端提交查询请求,Redis 则返回同步之前的数据。

· Redis 不具备自动容错和恢复功能,主机从机的宕机都会导致前端部分读写请求失败,需要等待机器重启或者手动切换前端的 IP 才能恢复

· 主机宕机,宕机前有部分数据未能及时同步到从机,切换 IP 后面还会引入数据不一致的问题,降低了系统的可用性

· Redis 较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂

· Redis 的主节点和从节点中的数据是一样的,降低的内存的可用性

实际生产中,我们优先考虑哨兵模式。这种模式下,master 宕机,哨兵会自动选举 master 并将其他的 slave 指向新的 master。

在主从模式下,redis 同时提供了哨兵命令 redis-sentinel ,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵进程向所有的 redis 机器人发送命令,等待 Redis 服务器响应,从而监控运行的多个 Redis 实例。一般为了便于决策选举,使用 奇数个哨兵 。多个哨兵构成一个哨兵集群,哨兵直接也会相互通信,检查哨兵是否正常运行,同时发现 master 战机哨兵之间会进行决策选举新的 master

哨兵模式的作用:

· 通过发送命令,让 Redis 服务器返回监控其运行状态,包括主服务器和从服务器

· 然而一个哨兵进程对 Redis 服务器进行监控,也可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多种哨兵模式。

哨兵很像 kafka 集群中的 zookeeper 的功能。

· 哨兵模式是基于主从模式的,所有主从的优点,哨兵模式都具有。

· 主从可以自动切换,系统更健壮,可用性更高。

· 具有主从模式的缺点,每台机器上的数据是一样的,内存的可用性较低。

· Redis 较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。

Redis 集群模式本身没有使用一致性 hash 算法,而是使用 slots 插槽

Redis 哨兵模式基本已经可以实现高可用,读写分离 ,但是在这种模式下每台 Redis 服务器都存储相同的数据,很浪费内存,所以在 redis3.0 上加入了 Cluster 集群模式,实现了 Redis 的分布式存储,对数据进行分片,也就是说每台 Redis 节点上存储不同的内容;每个节点都会通过集群总线(cluster bus),与其他的节点进行通信。 通讯时使用特殊的端口号,即对外服务端口号加 10000。例如如果某个 node 的端口号是 6379,那么它与其它 nodes 通信的端口号是 16379。nodes 之间的通信采用特殊的二进制协议。

对客户端来说,整个 cluster 被看做是一个整体,客户端可以连接任意一个 node 进行 *** 作,就像 *** 作单一 Redis 实例一样, 当客户端 *** 作的时候 key 没有分配到该 node 上时,Redis 会返回转向指令,指向正确的 node,这有点儿像浏览器页面的 302 redirect 跳转。

根据官方推荐,集群部署至少要 3 台以上的 master 节点,最好使用 3 主 3 从六个节点的模式。

在 Redis 的每一个节点上,都有这么两个东西, 一个是插槽(slot),它的的取值范围是:0-16383, 可以从上面 redis-trib.rb 执行的结果看到这 16383 个 slot 在三个 master 上的分布。还有一个就是 cluster,可以理解为是一个集群管理的插件,类似的哨兵。

当我们的存取的 Key 到达的时候,Redis 会根据 crc16 的算法对计算后得出一个结果,然后把结果和 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,通过这个值,去找到对应的插槽所对应的节点,然后直接自动跳转到这个对应的节点上进行存取 *** 作。

为了保证高可用, redis-cluster 集群引入了主从模式 ,一个主节点对应一个或者多个从节点。当其它主节点 ping 主节点 master 1 时,如果半数以上的主节点与 master 1 通信超时,那么认为 master 1 宕机了,就会启用 master 1 的从节点 slave 1,将 slave 1 变成主节点继续提供服务。

如果 master 1 和它的从节点 slave 1 都宕机了,整个集群就会进入 fail 状态,因为集群的 slot 映射不完整。 如果集群超过半数以上的 master 挂掉,无论是否有 slave,集群都会进入 fail 状态。

redis-cluster 采用去中心化的思想 ,没有中心节点的说法,客户端与 Redis 节点直连,不需要中间代理层,客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

对 redis 集群的扩容就是向集群中添加机器,缩容就是从集群中删除机器,并重新将 16383 个 slots 分配到集群中的节点上(数据迁移)。

扩缩容也是使用集群管理工具 redis-tri.rb。

扩容时,先使用 redis-tri.rb add-node 将新的机器加到集群中,这是新机器虽然已经在集群中了,但是没有分配 slots,依然是不起做用的。在使用 redis-tri.rb reshard 进行分片重哈希(数据迁移),将旧节点上的 slots 分配到新节点上后,新节点才能起作用。

缩容时,先要使用 redis-tri.rb reshard 移除的机器上的 slots,然后使用 redis-tri.rb add-del 移除机器。

采用去中心化思想,数据按照 slot 存储分布在多个节点,节点间数据共享,可动态调整数据分布

可扩展性:可线性扩展到 1000 多个节点,节点可动态添加或删除

高可用性:部分节点不可用时,集群仍可用。通过增加 Slave 做 standby 数据副本,能够实现故障自动 failover,节点之间通过 gossip 协议交换状态信息,用投票机制完成 Slave 到 Master 的角色提升

降低运维成本,提高系统的扩展性和可用性。

1.Redis Cluster 是无中心节点的集群架构,依靠 Goss 协议(谣言传播)协同自动化修复集群的状态。但 GosSIp 有消息延时和消息冗余的问题,在集群节点数量过多的时候,节点之间需要不断进行 PING/PANG 通讯,不必须要的流量占用了大量的网络资源。虽然 Reds4.0 对此进行了优化,但这个问题仍然存在。

2.数据迁移问题

Redis Cluster 可以进行节点的动态扩容缩容,这一过程,在目前实现中,还处于半自动状态,需要人工介入。在扩缩容的时候,需要进行数据迁移。

而 Redis 为了保证迁移的一致性,迁移所有 *** 作都是同步 *** 作 ,执行迁移时,两端的 Redis 均会进入时长不等的阻塞状态,对于小 Key,该时间可以忽略不计,但如果一旦 Key 的内存使用过大,严重的时候会接触发集群内的故障转移,造成不必要的切换。

主从模式:master 节点挂掉后,需要手动指定新的 master,可用性不高,基本不用。

哨兵模式:master 节点挂掉后,哨兵进程会主动选举新的 master,可用性高,但是每个节点存储的数据是一样的,浪费内存空间。数据量不是很多,集群规模不是很大,需要自动容错容灾的时候使用。

集群模式:数据量比较大,QPS 要求较高的时候使用。 Redis Cluster 是 Redis 3.0 以后才正式推出,时间较晚,目前能证明在大规模生产环境下成功的案例还不是很多,需要时间检验。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/bake/11753687.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-18
下一篇 2023-05-18

发表评论

登录后才能评论

评论列表(0条)

保存