面试官：Redis 有哪些拓展方案？

最新推荐文章于 2024-08-23 12:37:01 发布

2401_84046545

最新推荐文章于 2024-08-23 12:37:01 发布

阅读量779

点赞数 8

分类专栏：程序员文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/2401_84046545/article/details/137489158

版权

程序员专栏收录该内容

477 篇文章 0 订阅

订阅专栏

概述数据迁移

常说的主从(Master-Slave)，也就是复制(Replication)方式，怎么称呼都可以。

同上面的分区一样，也是Redis高可用架构的基础，新手可能会误以为这类基础模式即是“高可用”，这并不是十分正确的。

分区暂时能解决单点无法容纳的数据量问题，但是一个Key还是只在一个实例上，在大流量时代显得不那么可靠。

主从就是另一个纬度的拓展，节点将数据同步到从节点，就像将实例“分身”了一样，可靠性又提高了不少。

图画的有些夸张了，主要还是想体现结构灵活，是一主一从，还是一主多从，还是一主多从多从… 看你心情

有了“实例分身”，自然就可以做读写分离，将读流量均摊在各个从节点。

使用方式

高手云集的时代，聊天软件难免要备上这么一张表情包。

这表情包和使用方式有什么关系呢？首先看看使用方式：

作为主节点的Redis实例，并不要求配置任何参数，只需要正常启动
作为从节点的实例，使用配置文件或命令方式REPLICAOF 主节点Host 主节点port即可完成主从配置

是不是和表情包一样，“dalao”没动，我去“抱大腿”。

这样一个主从最小配置就完成了，主从实例即可对外提供服务。

命令里的“主节点”是相对的，slave也可以抱slave大腿，也就是上文提到的结构灵活。

缺点

slave节点都是只读的，如果写流量大的场景，就有些力不从心了。那我把slave节点只读关掉不就行了？当然不行，数据复制是由主到从，从节点独有数据同步不到主节点，数据就不一致了。
故障转移不友好，主节点挂掉后，写处理就无处安放，需要手工的设定新的主节点，如使用REPLICAOF no one(谁大腿我都不抱了) 晋升为主节点，再梳理其他slave节点的新主配置，相对来说比较麻烦。

哨兵

概述

主从的手工故障转移，肯定让人很难接受，自然就出现了高可用方案-哨兵（Sentinel）。

我们可以在主从架构不变的场景，直接加入Redis Sentinel，对节点进行监控，来完成自动的故障发现与转移。

并且还能够充当配置提供者，提供主节点的信息，就算发生了故障转移，也能提供正确的地址。

哨兵本身也是Redis实例的一种，但不作为数据存储方使用，启动命令也是不一样的。

虽然图有些复杂，看起来像要召唤光能使者。

其实实际使用起来是很便捷的。

使用方式

Sentinel的最小配置，一行即可：

sentinel monitor <主节点别名> <主节点host> <主节点端口> <票数>

只需要配置master即可，然后用redis-sentinel <配置文件> 命令即可启用。

Redis官网提到的“最小配置”是如下所示，除了上面提到的一行，还有其它的一些配置：

sentinel monitor mymaster 127.0.0.1 6379 2sentinel down-after-milliseconds mymaster 60000sentinel failover-timeout mymaster 180000sentinel parallel-syncs mymaster 1sentinel monitor resque 192.168.1.3 6380 4sentinel down-after-milliseconds resque 10000sentinel failover-timeout resque 180000sentinel parallel-syncs resque 5

这是因为官网加了一个修饰词，是“典型的最小配置”，把重要参数和多主的例子都写出来了，照顾大家CV大法的时候，不要忘记重要参数，其实都是有默认值的。

正如该例所示，设置主节点别名就是为了监控多主的时候，与其额外配置项能够与其对应, 以及sentinel一些命令，如SENTINEL get-master-addr-by-name就要用到别名了。

哨兵数量建议在三个以上且为奇数，在Redis官网也提到了各种情况的“布阵”方式，非常值得参考。

既然是高可用方案，并非有严格意义上的“缺点”，还需配合使用场景进行考量。

故障转移期间短暂的不可用，但其实官网的例子也给出了parallel-syncs参数来指定并行的同步实例数量，以免全部实例都在同步出现整体不可用的情况，相对来说要比手工的故障转移更加方便。
分区逻辑需要自定义处理，虽然解决了主从下的高可用问题，但是Sentinel并没有提供分区解决方案，还需开发者考虑如何建设。
既然是还是主从，如果异常的写流量搞垮了主节点，那么自动的“故障转移”会不会变成自动“灾难传递”，即slave提升为Master之后挂掉，又进行提升又被挂掉。不过最后这点也是笔者猜测，并没有听说过出现这种案例，可不必深究。

集群

概述

Redis Cluster是官方在3.0版本后推出的分布式方案。

对开发者而言，“官方支持”一词是大概率非常美好的，小到issue，大到feature。自定义去解决问题，成本总是要高一些。

有了官方的正式集群方案，从请求路由、故障转移、弹性伸缩几个纬度的使用上，将更为容易。

Cluster不同于哨兵，是支持分区的。有说法Cluster是哨兵的升级，这是不严谨的。

二者纬度不一样，如果因为Cluster也有故障转移的功能，就说它是哨兵的升级款，略显牵强。

Cluster在分区管理上，使用了“哈希槽”(hash slot)这么一个概念，一共有16384个槽位，每个实例负责一部分槽，通过CRC16（key）&16383这样的公式，计算出来key所对应的槽位。

虽然在节点和key二者中又引入了槽的概念，看起来不易理解，实际上因为颗粒度更细了，减少了节点的扩容和收缩难度，相比传统策略还是很有优势。

当然，“槽”是虚拟的概念，节点自身去维护“槽”的关系，并不是要真正下载启动个“槽服务”在跑。

使用方式

Redis的各种玩法，都是从配置文件着手，集群也不例外。

cluster-enabled yescluster-config-file “redis-node.conf”

关键配置简洁明了，有两步

开启集群
指定集群配置文件

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

即使是面试跳槽，那也是一个学习的过程。只有全面的复习，才能让我们更好的充实自己，武装自己，为自己的面试之路不再坎坷！今天就给大家分享一个Github上全面的Java面试题大全，就是这份面试大全助我拿下大厂Offer，月薪提至30K！

我也是第一时间分享出来给大家，希望可以帮助大家都能去往自己心仪的大厂！为金三银四做准备！
一共有20个知识点专题，分别是：