关于redis:Redis服务支持5000万的QPS有什么好的思路

一、题目剖析

1. 仅依据qps计算多少机器是不够的

如果一个Redis服务器反对五千万下面的读写申请,那么此题很简略,一个机器,一个Redis过程即可。

但显然没有这样的超级机器,Redis也做不到一个过程就能解决五千万QPS。

那么一个Redis到底能解决多少QPS?

如果是简略的读写,那么一个Redis在一个硬件服务器(只有1个核,CPU为以后支流即可),就能解决Million级别的QPS,即至多百万。

所以,下面的问题如同简略了,咱们只有用50个Redis过程就能反对题目所需的五千万,而后在一个50核的机器上跑这五十个过程,即可。

所以,答案如同很简略:一台五十核机器,五十Redis过程。

然而这样的吗?不是的,因为很可能应用环境并不是只有简略的有限量的key,如果key一直增多,那就会呈现大麻烦。

2. 瓶颈在哪?

难点在那个两千万QPS的写入(即20M qps write),我来仔细分析给你看。

假如:每个写入是100字节(即key+value之和均匀在100Bytes,即0.1KB),而且万一这两千万QPS的写入都是新增数据,而且随后的三千万QPS(即30M qps read)还可能查历史的数据,咱们会有什么麻烦?

显然,下一秒将产生 0.1KB 20M qps = 2GB 新增数据,每天将产生 2GB 86400 秒 = 173 TB 新增数据。

没有任何一台机器的内存能够反对一天的新增数据容量,更何况服务运行工夫以年为单位。

所以,咱们只能用到磁盘。

但问题是:如果将数据存盘,Redis是查不到的。

但如果Redis能查到磁盘上的数据,是否能解此题?

RedRock反对Redis存储磁盘,那么咱们尝试用RedRock解解此题。

二、首先拆分

假如咱们用100台机器,每台跑一个RedRock服务过程。即一个RedRock服务,反对500K qps,其中200K qps write,300K qps read。这样百台机器就能够达到五千万(50M)qps。

首先,每天新增的数据对于每台机器,只有1.7 TB,须要存盘。再加上RedRock采纳压缩存盘,尽管压缩率依据数据的不同而压缩效率不一样,但最差的状况下,咱们也有信念取得至多50%的压缩率(最好能够到10%)。

所以,对于每台机器,每天会新增最多 0.9 TB数据,而后入磁盘。一年的数据能够到300 TB这个量级。

这个是磁盘的理论最大量,古代的机器配置齐全反对一年这个规模的数据存盘。

但理论利用中,很多时候用不到这么大量,可能会有十倍到百倍甚至千倍的缩减,请急躁看上面的剖析。

三、查看磁盘带宽够否

下面的剖析还太简略,因为磁盘还有一个瓶颈,就是读写速度是否够?

1. 先看磁盘写

对于每台机器,注入的速度是:0.1 KB * 200K qps = 20MB/每秒 的注入速度。

再思考RedRock用了RocksDB写入,个别会有10倍的写放大,所以,磁盘写所消耗的带宽是 200MB/每秒,再思考压缩50%,则只有100MB/每秒的写入。

这个对于以后的SSD的性能要求是足够的。

2. 再看磁盘读

30M qps read摊派到100台机器,那么每台机器是300K qps read。

咱们假如90%的读,都是热数据,即都在RedRock的内存中间接读取,那么只有10%的读须要到磁盘上。那么理论磁盘的读的带宽需要是(还需思考50%的压缩):

30K qps read from disk 0.1 KB 50% = 1.5MB read/每秒

必定也够

3. 磁盘读写一起看

对于写的100MB/每秒,RocksDB是程序sequential模式。

对于读的1.5MB/每秒,RocksDB是随机random模式。

混用是否够,须要测试,因为每个SSD对于读写混合模式的反对是不同的

但我本人的大抵判断是:够!不过,倡议你最好测试一下。

四、查看热数据的内存容量

还有一个中央须要查看,就是热数据的量,因为热数据都在内存里。

因为每台机器每秒的新注入数据是:20MB。而新写入的数据个别都是热数据。

所以,如果咱们心愿90%的拜访都落在内存里,那么如果是20G内存,咱们能够包容最近1000秒的数据,即17分钟。

即如果是20G内存,咱们心愿读read的90%都产生在最近新注入的17分钟的数据上。

如果能够扩充到200G内存,那么,就是170分钟,也就是近三个小时。

五、查看key的内存容量

留神,RedRock须要将所有的key都存储在内存里。所以,咱们还须要算算key占用多少内存。

对于每台机器,每秒新进入200K个key。

假如key用16个字节表白(UUID),那么,每秒将产生3M字节的key内存,一天将产生276G的key放在内存里。

所以,真正麻烦的中央是key的内存容量。

解决的方法有几个:

扩充机器数量,如果机器是一千台,那么每天每台机器只产生不到30G的key内存量

心愿key不都是新key,即有很多反复的,比方:每天的写入里,只有10%的新key,则一天新增的key量,对于100台机器,也就不到30G,1000台机器,不到3G。如果每天的写入,只有1%的新key,则再升高10倍。留神:依据业务理论状况,运行越久,则1%的产生概率越高,即可能产生第一天是10%新增,而后开始递加,最初到一个稳固值1%,甚至更低。

不论如何,咱们都必须删除过老的key了。对于100台机器组成的集群(每台机器有300G内寄存key),每天只有10%的新key,则可放10天的key,每天只有1%的新key,则能够放100天。对于1000台机器集群,则别离是100天(三分之一年)和1000天(三年)。过老的key,咱们必须删除,让key的内存空间缩小。

同样地,如果每天新增的key量,只占写入qps的10%或者1%,那么磁盘的容量,一年也不须要下面剖析的300TB这个量级,而是同样升高10倍,或者100倍,即最低只需几个TB的磁盘。

六、客户端如何均分负载

上面咱们须要让客户端平均调配负载到这100台机器上。

有三个解决方案:

1. 客户端逻辑做Shard

最简略的算法是:Shard(key) module 100,比方:咱们能够用CRC16算法,即 node id = crc16(key) % 100。

益处是:简略。害处是:动静扩大(比方:减少、缩小一台机器)不不便

2. 通过代理proxy做Shard

通过应用诸如Envoy这样的代理(proxy),让代理软件做shard,而且还能够实现一致性Shard(consistent hash),这样集群的增减会简略一些。

害处在于,通过proxy,会减少一些时延。不过Envoy采纳side car模式,实践上减少最低几十个us,个别状况下,不会超过1ms的时延,所以,还是能够思考的。

3. 用Redis Cluster

RedRock反对Redis的Cluster模式。所以,间接应用Redis Cluster,增减机器都绝对简略。

害处是:如果机器到了千台,不易做Redis Cluster,因为其Gossip协定在这个量级,问题比拟大。如果是百台机器,则无问题。

七、如果key+value超过百字节

如果value比拟大,比方均匀千字节,那么下面的算法还是成立,只是,须要依据value扩充了10倍,相应地,推算(和测试)磁盘的带宽需要以及热数据的内存需要,即下面的百台机器,可能须要变成千台。

八、用zstd压缩算法进一步减小磁盘

RedRock用RocksDB库时,以后代码里只反对了lz4的压缩算法。

实际上,咱们能够用zstd算法对于磁盘里的LSM树的最底层进行压缩,这样,将大大减少磁盘的容量,缩小多少,请测试。

当然,你须要减少几行代码,让RedRock反对zstd压缩,具体可自行批改 src/rock.c里的init_rocksdb()函数。为了让RedRock依赖的库较少,我没有减少这个个性,你能够自行退出zstd反对,几行代码,并不简单。

九、热数据的拜访不是90%会如何

下面假如90%的拜访还是热数据,但万一是80%,甚至70%,会如何?

如果你仔细阅读了RedRock的文档,答案也很简略:

要么时延Latency变差,不能保障P99还是1ms以下。

要么Throughput变差,即每台服务器不能反对500K qps,这时,须要减少机器。

具体如何,请测试,我也不晓得。

十、如何增强高可用性HA

尽管咱们能够通过Proxy和Redis Cluster,动静地减少机器,但这个过程并不简略,而且有肯定危险(TB级的数据从一台机器转移到另外一台或多台机器上,不是一个简略的事)。

所以,思考增强高可用HA,是一个值得思考的计划。

这时,就须要用到Master/Slave,即读写拆散。

RedRock反对Redis的读写拆散和各种集群计划,所以,对于每个shard,咱们都能够再补充一台机器做slave,这样就进步了HA。

还有一个益处,对于写,加了slave并不能scale out。但对于读,确能够做到scale out。比方,对于下面的百台机器,如果咱们再减少百台机器做slave的话,那么每台机器所接受的读,能够升高到150K qps。

【腾讯云】云产品限时秒杀,爆款1核2G云服务器,首年50元

阿里云限时活动-2核2G-5M带宽-60G SSD-1000G月流量 ,特惠价99元/年(原价1234.2元/年,可以直接买3年),速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表评论

您的电子邮箱地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据