0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

如何从0到1构建一个稳定、高性能的Redis集群?

数据分析与开发 来源:数据分析与开发 2023-07-19 15:19 次阅读

现如今 Redis 变得越来越流行,几乎在很多项目中都要被用到,不知道你在使用 Redis 时,有没有思考过,Redis 到底是如何稳定、高性能地提供服务的?

你也可以尝试回答一下以下这些问题:

我使用 Redis 的场景很简单,只使用单机版 Redis 会有什么问题吗?

我的 Redis 故障宕机了,数据丢失了怎么办?如何能保证我的业务应用不受影响?

为什么需要主从集群?它有什么优势?

什么是分片集群?我真的需要分片集群吗?

...

如果你对 Redis 已经有些了解,肯定也听说过数据持久化、主从复制、哨兵这些概念,它们之间又有什么区别和联系呢?

如果你存在这样的疑惑,这篇文章,我会从 0 到 1,再从 1 到 N,带你一步步构建出一个稳定、高性能的 Redis 集群。

在这个过程中,你可以了解到 Redis 为了做到稳定、高性能,都采取了哪些优化方案,以及为什么要这么做?

掌握了这些原理,这样平时你在使用 Redis 时,就能够做到「游刃有余」。

这篇文章干货很多,希望你可以耐心读完。

e45f0ece-25e7-11ee-962d-dac502259ad0.png

从最简单的开始:单机版 Redis

首先,我们从最简单的场景开始。

假设现在你有一个业务应用,需要引入 Redis 来提高应用的性能,此时你可以选择部署一个单机版的 Redis 来使用,就像这样:

e46d656e-25e7-11ee-962d-dac502259ad0.jpg

这个架构非常简单,你的业务应用可以把 Redis 当做缓存来使用,从 MySQL 中查询数据,然后写入到 Redis 中,之后业务应用再从 Redis 中读取这些数据,由于 Redis 的数据都存储在内存中,所以这个速度飞快。

如果你的业务体量并不大,那这样的架构模型基本可以满足你的需求。是不是很简单?

随着时间的推移,你的业务体量逐渐发展起来了,Redis 中存储的数据也越来越多,此时你的业务应用对 Redis 的依赖也越来越重。

但是,突然有一天,你的 Redis 因为某些原因宕机了,这时你的所有业务流量,都会打到后端 MySQL 上,这会导致你的 MySQL 压力剧增,严重的话甚至会压垮 MySQL。

e478154a-25e7-11ee-962d-dac502259ad0.jpg

这时你应该怎么办?

我猜你的方案肯定是,赶紧重启 Redis,让它可以继续提供服务。

但是,因为之前 Redis 中的数据都在内存中,尽管你现在把 Redis 重启了,之前的数据也都丢失了。重启后的 Redis 虽然可以正常工作,但是由于 Redis 中没有任何数据,业务流量还是都会打到后端 MySQL 上,MySQL 的压力还是很大。

这可怎么办?你陷入了沉思。

有没有什么好的办法解决这个问题?

既然 Redis 只把数据存储在内存中,那是否可以把这些数据也写一份到磁盘上呢?

如果采用这种方式,当 Redis 重启时,我们把磁盘中的数据快速恢复到内存中,这样它就可以继续正常提供服务了。

是的,这是一个很好的解决方案,这个把内存数据写到磁盘上的过程,就是「数据持久化」。

数据持久化:有备无患

现在,你设想的 Redis 数据持久化是这样的:

e48098aa-25e7-11ee-962d-dac502259ad0.jpg

但是,数据持久化具体应该怎么做呢?

我猜你最容易想到的一个方案是,Redis 每一次执行写操作,除了写内存之外,同时也写一份到磁盘上,就像这样:

e48a7636-25e7-11ee-962d-dac502259ad0.jpg

没错,这是最简单直接的方案。

但仔细想一下,这个方案有个问题:客户端的每次写操作,既需要写内存,又需要写磁盘,而写磁盘的耗时相比于写内存来说,肯定要慢很多!这势必会影响到 Redis 的性能。

如何规避这个问题?

我们可以这样优化:Redis 写内存由主线程来做,写内存完成后就给客户端返回结果,然后 Redis 用另一个线程去写磁盘,这样就可以避免主线程写磁盘对性能的影响。

这确实是一个好方案。除此之外,我们可以换个角度,思考一下还有什么方式可以持久化数据?

这时你就要结合 Redis 的使用场景来考虑了。

回忆一下,我们在使用 Redis 时,通常把它用作什么场景?

是的,缓存。

把 Redis 当做缓存来用,意味着尽管 Redis 中没有保存全量数据,对于不在缓存中的数据,我们的业务应用依旧可以通过查询后端数据库得到结果,只不过查询后端数据的速度会慢一点而已,但对业务结果其实是没有影响的。

基于这个特点,我们的 Redis 数据持久化还可以用「数据快照」的方式来做。

那什么是数据快照呢?

简单来讲,你可以这么理解:

你把 Redis 想象成一个水杯,向 Redis 写入数据,就相当于往这个杯子里倒水

此时你拿一个相机给这个水杯拍一张照片,拍照的这一瞬间,照片中记录到这个水杯中水的容量,就是水杯的数据快照

e491050a-25e7-11ee-962d-dac502259ad0.jpg

也就是说,Redis 的数据快照,是记录某一时刻下 Redis 中的数据,然后只需要把这个数据快照写到磁盘上就可以了。

它的优势在于,只在需要持久化时,把数据「一次性」写入磁盘,其它时间都不需要操作磁盘。

基于这个方案,我们可以定时给 Redis 做数据快照,把数据持久化到磁盘上。

e49a56b4-25e7-11ee-962d-dac502259ad0.jpg

其实,上面说的这些持久化方案,就是 Redis 的「RDB」和「AOF」:

RDB:只持久化某一时刻的数据快照到磁盘上(创建一个子进程来做)

AOF:每一次写操作都持久到磁盘(主线程写内存,根据策略可以配置由主线程还是子线程进行数据持久化)

它们的区别除了上面讲到的,还有以下特点:

RDB 采用二进制 + 数据压缩的方式写磁盘,这样文件体积小,数据恢复速度也快

AOF 记录的是每一次写命令,数据最全,但文件体积大,数据恢复速度慢

如果让你来选择持久化方案,你可以这样选择:

如果你的业务对于数据丢失不敏感,采用 RDB 方案持久化数据

如果你的业务对数据完整性要求比较高,采用 AOF 方案持久化数据

假设你的业务对 Redis 数据完整性要求比较高,选择了 AOF 方案,那此时你又会遇到这些问题:

AOF 记录每一次写操作,随着时间增长,AOF 文件体积会越来越大

这么大的 AOF 文件,在数据恢复时变得非常慢

这怎么办?数据完整性要求变高了,恢复数据也变困难了?有没有什么方法,可以缩小文件体积?提升恢复速度呢?

我们继续来分析 AOF 的特点。

由于 AOF 文件中记录的都是每一次写操作,但对于同一个 key 可能会发生多次修改,我们只保留最后一次被修改的值,是不是也可以?

是的,这就是我们经常听到的「AOF rewrite」,你也可以把它理解为 AOF 「瘦身」。

我们可以对 AOF 文件定时 rewrite,避免这个文件体积持续膨胀,这样在恢复时就可以缩短恢复时间了。

e49fbda2-25e7-11ee-962d-dac502259ad0.jpg

再进一步思考一下,还有没有办法继续缩小 AOF 文件?

回顾一下我们前面讲到的,RDB 和 AOF 各自的特点:

RDB 以二进制 + 数据压缩方式存储,文件体积小

AOF 记录每一次写命令,数据最全

我们可否利用它们各自的优势呢?

当然可以,这就是 Redis 的「混合持久化」。

具体来说,当 AOF rewrite 时,Redis 先以 RDB 格式在 AOF 文件中写入一个数据快照,再把在这期间产生的每一个写命令,追加到 AOF 文件中。因为 RDB 是二进制压缩写入的,这样 AOF 文件体积就变得更小了。

e4a86146-25e7-11ee-962d-dac502259ad0.jpg

此时,你在使用 AOF 文件恢复数据时,这个恢复时间就会更短了!

Redis 4.0 以上版本才支持混合持久化。

这么一番优化,你的 Redis 再也不用担心实例宕机了,当发生宕机时,你就可以用持久化文件快速恢复 Redis 中的数据。

但这样就没问题了吗?

仔细想一下,虽然我们已经把持久化的文件优化到最小了,但在恢复数据时依旧是需要时间的,在这期间你的业务应用还是会受到影响,这怎么办?

我们来分析有没有更好的方案。

一个实例宕机,只能用恢复数据来解决,那我们是否可以部署多个 Redis 实例,然后让这些实例数据保持实时同步,这样当一个实例宕机时,我们在剩下的实例中选择一个继续提供服务就好了。

没错,这个方案就是接下来要讲的「主从复制:多副本」。

主从复制:多副本

此时,你可以部署多个 Redis 实例,架构模型就变成了这样:

e4b2fd5e-25e7-11ee-962d-dac502259ad0.jpg

我们这里把实时读写的节点叫做 master,另一个实时同步数据的节点叫做 slave。

采用多副本的方案,它的优势是:

缩短不可用时间:master 发生宕机,我们可以手动把 slave 提升为 master 继续提供服务

提升读性能:让 slave 分担一部分读请求,提升应用的整体性能

e4ba39f2-25e7-11ee-962d-dac502259ad0.jpg

这个方案不错,不仅节省了数据恢复的时间,还能提升性能,那它有什么问题吗?

你可以思考一下。

其实,它的问题在于:当 master 宕机时,我们需要「手动」把 slave 提升为 master,这个过程也是需要花费时间的。

虽然比恢复数据要快得多,但还是需要人工介入处理。一旦需要人工介入,就必须要算上人的反应时间、操作时间,所以,在这期间你的业务应用依旧会受到影响。

怎么解决这个问题?我们是否可以把这个切换的过程,变成自动化呢?

对于这种情况,我们需要一个「故障自动切换」机制,这就是我们经常听到的「哨兵」所具备的能力。

哨兵:故障自动切换

现在,我们可以引入一个「观察者」,让这个观察者去实时监测 master 的健康状态,这个观察者就是「哨兵」。

具体如何做?

哨兵每间隔一段时间,询问 master 是否正常

master 正常回复,表示状态正常,回复超时表示异常

哨兵发现异常,发起主从切换

e4c3fe88-25e7-11ee-962d-dac502259ad0.jpg

有了这个方案,就不需要人去介入处理了,一切就变得自动化了,是不是很爽?

但这里还有一个问题,如果 master 状态正常,但这个哨兵在询问 master 时,它们之间的网络发生了问题,那这个哨兵可能会误判。

e4cd6fe0-25e7-11ee-962d-dac502259ad0.jpg

这个问题怎么解决?

答案是,我们可以部署多个哨兵,让它们分布在不同的机器上,它们一起监测 master 的状态,流程就变成了这样:

多个哨兵每间隔一段时间,询问 master 是否正常

master 正常回复,表示状态正常,回复超时表示异常

一旦有一个哨兵判定 master 异常(不管是否是网络问题),就询问其它哨兵,如果多个哨兵(设置一个阈值)都认为 master 异常了,这才判定 master 确实发生了故障

多个哨兵经过协商后,判定 master 故障,则发起主从切换

所以,我们用多个哨兵互相协商来判定 master 的状态,这样一来,就可以大大降低误判的概率。

哨兵协商判定 master 异常后,这里还有一个问题:由哪个哨兵来发起主从切换呢?

答案是,选出一个哨兵「领导者」,由这个领导者进行主从切换。

问题又来了,这个领导者怎么选?

想象一下,在现实生活中,选举是怎么做的?

是的,投票。

在选举哨兵领导者时,我们可以制定这样一个选举规则:

每个哨兵都询问其它哨兵,请求对方为自己投票

每个哨兵只投票给第一个请求投票的哨兵,且只能投票一次

首先拿到超过半数投票的哨兵,当选为领导者,发起主从切换

其实,这个选举的过程就是我们经常听到的:分布式系统领域中的「共识算法」。

什么是共识算法?

我们在多个机器部署哨兵,它们需要共同协作完成一项任务,所以它们就组成了一个「分布式系统」。

在分布式系统领域,多个节点如何就一个问题达成共识的算法,就叫共识算法。

在这个场景下,多个哨兵共同协商,选举出一个都认可的领导者,就是使用共识算法完成的。

这个算法还规定节点的数量必须是奇数个,这样可以保证系统中即使有节点发生了故障,剩余超过「半数」的节点状态正常,依旧可以提供正确的结果,也就是说,这个算法还兼容了存在故障节点的情况。

共识算法在分布式系统领域有很多,例如 Paxos、Raft,哨兵选举领导者这个场景,使用的是 Raft 共识算法,因为它足够简单,且易于实现。

现在,我们用多个哨兵共同监测 Redis 的状态,这样一来,就可以避免误判的问题了,架构模型就变成了这样:

e4d60452-25e7-11ee-962d-dac502259ad0.jpg

好了,到这里我们先小结一下。

你的 Redis 从最简单的单机版,经过数据持久化、主从多副本、哨兵集群,这一路优化下来,你的 Redis 不管是性能还是稳定性,都越来越高,就算节点发生故障,也不用担心了。

你的 Redis 以这样的架构模式部署,基本上就可以稳定运行很长时间了。

...

随着时间的发展,你的业务体量开始迎来了爆炸性增长,此时你的架构模型,还能够承担这么大的流量吗?

我们一起来分析一下:

稳定性:Redis 故障宕机,我们有哨兵 + 副本,可以自动完成主从切换

性能:读请求量增长,我们可以再部署多个 slave,读写分离,分担读压力

性能:写请求量增长,但我们只有一个 master 实例,这个实例达到瓶颈怎么办?

看到了么,当你的写请求量越来越大时,一个 master 实例可能就无法承担这么大的写流量了。

要想完美解决这个问题,此时你就需要考虑使用「分片集群」了。

分片集群:横向扩展

什么是「分片集群」?

简单来讲,一个实例扛不住写压力,那我们是否可以部署多个实例,然后把这些实例按照一定规则组织起来,把它们当成一个整体,对外提供服务,这样不就可以解决集中写一个实例的瓶颈问题吗?

所以,现在的架构模型就变成了这样:

e4dfae9e-25e7-11ee-962d-dac502259ad0.jpg

现在问题又来了,这么多实例如何组织呢?

我们制定规则如下:

每个节点各自存储一部分数据,所有节点数据之和才是全量数据

制定一个路由规则,对于不同的 key,把它路由到固定一个实例上进行读写

而分片集群根据路由规则所在位置的不同,还可以分为两大类:

客户端分片

服务端分片

客户端分片指的是,key 的路由规则放在客户端来做,就是下面这样:

e4ed3046-25e7-11ee-962d-dac502259ad0.jpg

这个方案的缺点是,客户端需要维护这个路由规则,也就是说,你需要把路由规则写到你的业务代码中。

如何做到不把路由规则耦合在业务代码中呢?

你可以这样优化,把这个路由规则封装成一个模块,当需要使用时,集成这个模块就可以了。

这就是 Redis Cluster 的采用的方案。

e4f7dc76-25e7-11ee-962d-dac502259ad0.jpg

Redis Cluster 内置了哨兵逻辑,无需再部署哨兵。

当你使用 Redis Cluster 时,你的业务应用需要使用配套的 Redis SDK,这个 SDK 内就集成好了路由规则,不需要你自己编写了。

再来看服务端分片。

这种方案指的是,路由规则不放在客户端来做,而是在客户端和服务端之间增加一个「中间代理层」,这个代理就是我们经常听到的 Proxy。

而数据的路由规则,就放在这个 Proxy 层来维护。

这样一来,你就无需关心服务端有多少个 Redis 节点了,只需要和这个 Proxy 交互即可。

Proxy 会把你的请求根据路由规则,转发到对应的 Redis 节点上,而且,当集群实例不足以支撑更大的流量请求时,还可以横向扩容,添加新的 Redis 实例提升性能,这一切对于你的客户端来说,都是透明无感知的。

业界开源的 Redis 分片集群方案,例如 Twemproxy、Codis 就是采用的这种方案。

e5012ea2-25e7-11ee-962d-dac502259ad0.jpg

分片集群在数据扩容时,还涉及到了很多细节,这块内容不是本文章重点,所以暂不详述。

至此,当你使用分片集群后,对于未来更大的流量压力,都可以从容面对了!

总结

好了,我们来总结一下,我们是如何一步步构建一个稳定、高性能的 Redis 集群的。

首先,在使用最简单的单机版 Redis 时,我们发现当 Redis 故障宕机后,数据无法恢复的问题,因此我们想到了「数据持久化」,把内存中的数据也持久化到磁盘上一份,这样 Redis 重启后就可以从磁盘上快速恢复数据。

在进行数据持久化时,我们又面临如何更高效地将数据持久化到磁盘的问题。之后我们发现 Redis 提供了 RDB 和 AOF 两种方案,分别对应了数据快照和实时的命令记录。当我们对数据完整性要求不高时,可以选择 RDB 持久化方案。如果对于数据完整性要求较高,那么可以选择 AOF 持久化方案。

但是我们又发现,AOF 文件体积会随着时间增长变得越来越大,此时我们想到的优化方案是,使用 AOF rewrite 的方式对其进行瘦身,减小文件体积,再后来,我们发现可以结合 RDB 和 AOF 各自的优势,在 AOF rewrite 时使用两者结合的「混合持久化」方式,又进一步减小了 AOF 文件体积。

之后,我们发现尽管可以通过数据恢复的方式还原数据,但恢复数据也是需要花费时间的,这意味着业务应用还是会受到影响。我们进一步优化,采用「多副本」的方案,让多个实例保持实时同步,当一个实例故障时,可以手动把其它实例提升上来继续提供服务。

但是这样也有问题,手动提升实例上来,需要人工介入,人工介入操作也需要时间,我们开始想办法把这个流程变得自动化,所以我们又引入了「哨兵」集群,哨兵集群通过互相协商的方式,发现故障节点,并可以自动完成切换,这样就大幅降低了对业务应用的影响。

最后,我们把关注点聚焦在如何支撑更大的写流量上,所以,我们又引入了「分片集群」来解决这个问题,让多个 Redis 实例分摊写压力,未来面对更大的流量,我们还可以添加新的实例,横向扩展,进一步提升集群的性能。

至此,我们的 Redis 集群才得以长期稳定、高性能的为我们的业务提供服务。

这里我画了一个思维导图,方便你更好地去理解它们之间的关系,以及演化的过程。

e50a7296-25e7-11ee-962d-dac502259ad0.png

后记

看到这里,我想你对如何构建一个稳定、高性能的 Redis 集群问题时,应该会有自己的见解了。

其实,这篇文章所讲的优化思路,围绕的主题就是「架构设计」的核心思想:

高性能:读写分离、分片集群

高可用:数据持久化、多副本、故障自动切换

易扩展:分片集群、横向扩展

当我们讲到哨兵集群、分片集群时,这还涉及到了「分布式系统」相关的知识:

分布式共识:哨兵领导者选举

负载均衡:分片集群数据分片、数据路由

当然,除了 Redis 之外,对于构建任何一个数据集群,你都可以沿用这个思路去思考、去优化,看看它们到底是如何做的。

例如当你在使用 MySQL 时,你可以思考一下 MySQL 与 Redis 有哪些不同?MySQL 为了做到高性能、高可用,又是如何做的?其实思路都是类似的。

我们现在到处可见分布式系统、数据集群,我希望通过这篇文章,你可以理解这些软件是如何一步步演化过来的,在演化过程中,它们遇到了哪些问题,为了解决这些问题,这些软件的设计者设计了怎样的方案,做了哪些取舍?

你只有了解了其中的原理,掌握了分析问题、解决问题的能力,这样在以后的开发过程中,或是学习其它优秀软件时,就能快速地找到「重点」,在最短的时间掌握它,并能在实际应用中发挥它们的优势。

其实这个思考过程,也是做「架构设计」的思路。在做软件架构设计时,你面临的场景就是发现问题、分析问题、解决问题,一步步去演化、升级你的架构,最后在性能、可靠性方面达到一个平衡。虽然各种软件层出不穷,但架构设计的思想不会变,我希望你真正吸收的是这些思想,这样才可以做到以不变应万变。

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • 模型
    +关注

    关注

    1

    文章

    3172

    浏览量

    48711
  • MySQL
    +关注

    关注

    1

    文章

    802

    浏览量

    26444
  • Redis
    +关注

    关注

    0

    文章

    371

    浏览量

    10846

原文标题:如何从0到1构建一个稳定、高性能的 Redis 集群?(附16张图解)

文章出处:【微信号:DBDevs,微信公众号:数据分析与开发】欢迎添加关注!文章转载请注明出处。

收藏 人收藏

    评论

    相关推荐

    某证券公司智能云投资交易云集群高性能分布式存储应用

    某证券公司智能云投资交易云集群高性能分布式存储应用
    的头像 发表于 09-27 09:57 233次阅读
    某证券公司智能云投资交易云<b class='flag-5'>集群</b><b class='flag-5'>高性能</b>分布式存储应用

    K8S学习教程(二):在 PetaExpress KubeSphere容器平台部署高可用 Redis 集群

    并且需要手动重启节点,相较之下,使用 PetaExpress 提供的 Kubernetes(k8s) 服务 进行 Redis 集群的部署,则展现出了显著的优势: 1、安装便捷:使用镜像或者 yaml 配置文件即可
    的头像 发表于 07-03 15:30 675次阅读
    K8S学习教程(二):在 PetaExpress KubeSphere容器平台部署高可用 <b class='flag-5'>Redis</b> <b class='flag-5'>集群</b>

    高性能计算集群的能耗优化

    高性能计算(HighPerformanceComputing,HPC)是指利用大规模并行计算机集群来解决复杂的科学和工程问题的技术。高性能计算集群的应用领域非常广泛,包括天气预报、生物
    的头像 发表于 05-25 08:27 382次阅读
    <b class='flag-5'>高性能</b>计算<b class='flag-5'>集群</b>的能耗优化

    01 微硕开发出系列高性能功率系磁材

    针对功率系磁材发展的四大方向,微硕推出了对应的四大系列的磁性材料,适用于多种终端产品。 “磁性材料的开发是0
    的头像 发表于 01-25 15:17 525次阅读
    <b class='flag-5'>从</b><b class='flag-5'>0</b><b class='flag-5'>到</b><b class='flag-5'>1</b> 微硕开发出<b class='flag-5'>一</b>系列<b class='flag-5'>高性能</b>功率系磁材

    【爱芯派 Pro 开发板试用体验】Redis源码编译和基准测试

    Redis基准测试。测试结果显示,爱芯派上Redis性能明显由于树莓派4B,这定程度上说明——爱芯派的CPU、内存综合性能优于树莓派4B
    发表于 12-10 22:18

    【昉·星光 2 高性能RISC-V单板计算机体验】Redis源码编译和性能测试以及与树莓派4B对比

    本文首先介绍Redis是什么,然后介绍如何在VisionFive2上编译Redis源码,以及源码安装Redis,最后介绍如何在VisionFive2上运行
    发表于 12-10 21:27

    redis是关系型数据库吗

    Server)是开源的高性能键值对存储系统。它使用C语言编写,具有内存中数据存储和持久化硬盘的功能。Redis支持多种数据结构,如字
    的头像 发表于 12-05 10:32 1498次阅读

    redis的increment方法

    Redis种流行的开源键值存储数据库,具有高性能和卓越的可扩展性。它支持多种数据结构和功能,包括字符串、列表、哈希、集合和有序集合。其中,Redis的 INCR 命令是
    的头像 发表于 12-05 09:57 1167次阅读

    redis的持久化方式RDB和AOF的区别

    Redis高性能的键值对数据库,提供了两种持久化方式:RDB 和 AOF。RDB 是将 Redis 的数据快照保存到磁盘上,而 AO
    的头像 发表于 12-04 16:25 743次阅读

    redis的哨兵和集群有什么区别

    Redis开源的内存数据库,被广泛用于构建高性能和可扩展的应用程序。在使用Redis时,有
    的头像 发表于 12-04 14:53 2802次阅读

    redis查看集群状态命令

    Redis开源的、内存中的数据结构存储系统,提供了系列命令来管理和操作数据。在 Redis 中,
    的头像 发表于 12-04 11:39 1020次阅读

    redis集群性能测试工具有哪些

    Redis高性能的内存键值存储系统,它被广泛应用于各种互联网应用和大规模的数据存储中。为了评估Redis在不同场景下的性能,我们需要使
    的头像 发表于 12-04 11:36 756次阅读

    redis连接数对性能测试影响

    Redis基于内存的键值存储数据库,它以其高性能和低延迟而闻名。在使用Redis进行性能
    的头像 发表于 12-04 11:33 955次阅读

    redis集群中的hash致性算法的理解

    Redis集群种为了增强Redis的可扩展性和高可用性而设计的集群方案。在Redis
    的头像 发表于 12-04 10:45 713次阅读

    redis集群状态查看命令

    Redis集群种高可用性的分布式架构,可以通过多个节点实现数据的复制和负载均衡。为了维护集群稳定性和可靠性,管理员需要监控和查看
    的头像 发表于 12-04 10:44 1239次阅读