乐趣区

关于javascript:Redis高可用集群方案主从复制哨兵模式Redis集群

Redis-cluster 是近年来 Redis 架构不断改进中的绝对较好的 Redis 高可用计划。本文波及到近年来 Redis 多实例架构的演变过程,包含一般主从架构(Master、slave 可进行写读拆散)、哨兵模式下的主从架构、Redis-cluster 高可用架构(Redis 官网默认 cluster 下不进行读写拆散)的简介。同时还介绍应用 Java 的两大 redis 客户端:Jedis 与 Lettuce 用于读写 redis-cluster 的数据的个别办法。再通过官网文档以及互联网的相干技术文档,给出 redis-cluster 架构下的读写能力的优化计划,包含官网的举荐的扩大 redis-cluster 下的 Master 数量以及非官方默认的 redis-cluster 的读写拆散计划,案例中应用 Lettuce 的特定办法进行 redis-cluster 架构下的数据读写拆散。

近年来 redis 多实例用架构的演变过程

redis 是基于内存的高性能 key-value 数据库,若要让 redis 的数据更稳固平安,须要引入多实例以及相干的高可用架构。而近年来 redis 的高可用架构亦不断改进,先后呈现了本地长久化、主从备份、哨兵模式、redis-cluster 群集高可用架构等等计划。

1、redis 一般主从模式

通过长久化性能,Redis 保障了即便在服务器重启的状况下也不会损失(或大量损失)数据,因为长久化会把内存中数据保留到硬盘上,重启会从硬盘上加载数据。然而因为数据是存储在一台服务器上的,如果这台服务器呈现硬盘故障等问题,也会导致数据失落。为了防止单点故障,通常的做法是将数据库复制多个正本以部署在不同的服务器上,这样即便有一台服务器呈现故障,其余服务器仍然能够持续提供服务。为此,在 www.sangpi.com 里退出 Redis 提供了复制(replication)性能,能够实现当一台数据库中的数据更新后,主动将更新的数据同步到其余数据库上。

在复制的概念中,数据库分为两类,一类是主数据库(master),另一类是从数据库(slave)。主数据库能够进行读写操作,当写操作导致数据变动时会主动将数据同步给从数据库。而从数据库个别是只读的,并承受主数据库同步过去的数据。一个主数据库能够领有多个从数据库,而一个从数据库只能领有一个主数据库。

0c9ca9b3f2dfaa3c10d6e1777d4a7cb5.png

主从模式的配置,个别只须要再作为 slave 的 redis 节点的 conf 文件上退出“slaveof masterip masterport”,或者作为 slave 的 redis 节点启动时应用如下参考命令:

redis-server –port 6380 –slaveof masterIp masterPort

redis 的一般主从模式,能较好地防止独自故障问题,以及提出了读写拆散,升高了 Master 节点的压力。互联网上大多数的对 redis 读写拆散的教程,都是基于这一模式或架构下进行的。但实际上这一架构并非是目前最好的 redis 高可用架构。

2、redis 哨兵模式高可用架构

当主数据库遇到异常中断服务后,开发者能够通过手动的形式抉择一个从数据库来升格为主数据库,以使得零碎可能持续提供服务。然而整个过程绝对麻烦且须要人工染指,难以实现游戏自动化。为此,Redis 2.8 开始提供了哨兵工具来实现自动化的系统监控和故障复原性能。哨兵的作用就是监控 redis 主、从数据库是否失常运行,主呈现故障主动将从数据库转换为主数据库。

顾名思义,哨兵的作用就是监控 Redis 零碎的运行状况。它的性能包含以下两个。

(1)监控主数据库和从数据库是否失常运行。

(2)主数据库呈现故障时主动将从数据库转换为主数据库。

c3e2ab7f383c61fb5260236d18c33cc9.png

能够用 info replication 查看主从状况 例子:1 主 2 从 1 哨兵, 能够用命令起也能够用配置文件里 能够应用双哨兵,更平安,参考命令如下:

3e9140c3ec928e374fbb5d5777a5e7c8.png

其中,哨兵配置文件 sentinel.conf 参考如下:

sentinel monitor mymaster 192.168.0.167 6379 1

其中 mymaster 示意要监控的主数据库的名字。配置哨兵监控一个零碎时,只须要配置其监控主数据库即可,哨兵会主动发现所有复制该主数据库的从数据库。

Master 与 slave 的切换过程:

(1)slave leader 降级为 master

(2)其余 slave 批改为新 master 的 slave

(3)客户端批改连贯

(4)老的 master 如果重启胜利,变为新 master 的 slave

3、redis-cluster 群集高可用架构

即便应用哨兵,redis 每个实例也是全量存储,每个 redis 存储的内容都是残缺的数据,节约内存且有木桶效应。为了最大化利用内存,能够采纳 cluster 群集,就是分布式存储。即每台 redis 存储不同的内容。

采纳 redis-cluster 架构正是满足这种分布式存储要求的集群的一种体现。redis-cluster 架构中,被设计成共有 16384 个 hash slot。每个 master 分得一部分 slot,其算法为:hash_slot = crc16(key) mod 16384,这就找到对应 slot。采纳 hash slot 的算法,实际上是解决了 redis-cluster 架构下,有多个 master 节点的时候,数据如何散布到这些节点下来。key 是可用 key,如果有 {} 则取 {} 内的作为可用 key,否则整个能够是可用 key。群集至多须要 3 主 3 从,且每个实例应用不同的配置文件。

5047c9d4d9b6ede2c65b191f7ac3c676.jpeg

在 redis-cluster 架构中,redis-master 节点个别用于接管读写,而 redis-slave 节点则个别只用于备份,其与对应的 master 领有雷同的 slot 汇合,若某个 redis-master 意外生效,则再将其对应的 slave 进行降级为长期 redis-master。

在 redis 的官网文档中,对 redis-cluster 架构上,有这样的阐明:在 cluster 架构下,默认的,个别 redis-master 用于接管读写,而 redis-slave 则用于备份,当有申请是在向 slave 发动时,会间接重定向到对应 key 所在的 master 来解决。但如果不介意读取的是 redis-cluster 中有可能过期的数据并且对写申请不感兴趣时,则亦可通过 readonly 命令,将 slave 设置成可读,而后通过 slave 获取相干的 key,达到读写拆散。

退出移动版