怎么快速排查發(fā)現(xiàn)redis的bigkey

這篇文章主要講解了“怎么快速排查發(fā)現(xiàn)redis的bigkey”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么快速排查發(fā)現(xiàn)redis的bigkey”吧！

先認(rèn)識(shí)一下redis和bigkey吧

redis——互聯(lián)網(wǎng)的寵兒

redis作為一款優(yōu)秀的工業(yè)級(jí)內(nèi)存型數(shù)據(jù)庫(kù)，自誕生后便逐漸成為互聯(lián)網(wǎng)的寵兒，支撐起了互聯(lián)網(wǎng)豐富多彩的功能和巨大的QPS（每秒查詢率），并和nginx一樣成為高性能的代名詞，比如微博上的每一條熱搜背后都有著redis默默守候。從某種意義上來說，redis的使用量也代表著一家互聯(lián)網(wǎng)公司的流量。

在馮諾伊曼計(jì)算體系中，內(nèi)存是一種重要的存在。計(jì)算和存儲(chǔ)之間存在著一定的辯證關(guān)系，通過計(jì)算可以減少存儲(chǔ)，通過存儲(chǔ)可以減少一定量的消耗。因此，緩存的思想也成為系統(tǒng)性能減少計(jì)算量的一種重要優(yōu)化手段。

我們看兩張對(duì)比圖。

這張是cpu、內(nèi)存、磁盤的性能對(duì)比。內(nèi)存的讀寫性能是磁盤的近一千倍，redis作為內(nèi)存型存儲(chǔ)介質(zhì)，對(duì)系統(tǒng)性能提升具有革命性的變化，經(jīng)濟(jì)基礎(chǔ)決定上層建筑，所以經(jīng)濟(jì)效益永遠(yuǎn)是第一位的。

再看下各種存儲(chǔ)的價(jià)格。

支撐起redis高性能的另一個(gè)設(shè)計(jì)實(shí)現(xiàn)就是單線程的任務(wù)處理設(shè)計(jì)。

在面對(duì)一個(gè)巨大工作量時(shí)，為了盡快完成工作任務(wù)，通常都會(huì)選擇加人，把任務(wù)拆解成多份并行處理。這就是一個(gè)簡(jiǎn)單的多線程并發(fā)處理的思想，多線程可以提高任務(wù)處理的吞吐量。

那么為什么redis卻反其道而行之，使用單線程的方式？這里的單線程是指Redis 的網(wǎng)絡(luò) IO 和鍵值對(duì)讀寫是由一個(gè)線程來完成的，這也是 Redis 對(duì)外提供鍵值存儲(chǔ)服務(wù)的主要流程。

先來看下，如果使用多線程，在處理網(wǎng)絡(luò)IO時(shí)會(huì)存在哪些問題？線程是cpu調(diào)度的基本單位，cpu通過時(shí)鐘中斷，進(jìn)行時(shí)間片的切換，對(duì)外表現(xiàn)出并行處理的效果，任務(wù)切換必然消耗資源。當(dāng)開啟很多的線程，到一定量后，這些切換就會(huì)達(dá)到性能的瓶頸。

還有一個(gè)就是多線程下的資源共享問題，這也是并發(fā)編程的核心問題。并發(fā)環(huán)境下存在資源競(jìng)爭(zhēng)，就需要對(duì)共享資源的臨界區(qū)進(jìn)行加鎖處理，把并發(fā)處理轉(zhuǎn)化為串行化處理，redis的數(shù)據(jù)結(jié)構(gòu)中，底層使用的hashMap索引數(shù)據(jù)結(jié)構(gòu)，在多線程處理情況下，必然出現(xiàn)資源爭(zhēng)奪的問題，這即又變成一個(gè)串行同步化的處理過程。因此，我們?cè)诖朔穸硕嗑€程。

那么來看看單線程在這種場(chǎng)景下有什么好處

請(qǐng)求端和服務(wù)端通過tcp三次握手后會(huì)建立網(wǎng)絡(luò)連接，請(qǐng)求數(shù)據(jù)從網(wǎng)卡被寫入到操作系統(tǒng)的內(nèi)核緩沖區(qū)中，用戶程序執(zhí)行read操作，會(huì)將數(shù)據(jù)從內(nèi)核空間寫入到用戶程序執(zhí)行的變量中，如果內(nèi)核空間還未收到數(shù)據(jù)，這里就會(huì)發(fā)生阻塞等待。

這種處理方式我們顯然是不能夠接受的，為了解決這個(gè)技術(shù)問題，一種被叫做IO多路復(fù)用的技術(shù)被創(chuàng)造出來，在linux下一共有三種實(shí)現(xiàn)，select、poll、epoll,，簡(jiǎn)單來說，該機(jī)制允許內(nèi)核中同時(shí)存在多個(gè)監(jiān)聽套接字和已連接套接字，再完成讀寫就緒，通知用戶態(tài)來執(zhí)行。具體這里不做展開，有興趣的朋友可以網(wǎng)上搜下。

nodejs、nginx這些網(wǎng)關(guān)層的技術(shù)，都是單線程的設(shè)計(jì)，在處理網(wǎng)絡(luò)IO上，單線程要比多線程優(yōu)異。但是單線程也有其致命的弱點(diǎn)，一旦處理中的某個(gè)請(qǐng)求任務(wù)處理過長(zhǎng)，就會(huì)阻塞后邊的請(qǐng)求。這也是后文要展開的bigkey危害的主要原因。就像單行道上，某輛車出現(xiàn)了故障，就會(huì)出現(xiàn)堵車現(xiàn)象一個(gè)道理。

一、什么是bigkey？

從上圖的redis底層數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)中，可以看到value具有多種數(shù)據(jù)結(jié)構(gòu)的實(shí)現(xiàn)，因此，value大小在字符串類型，表現(xiàn)為字符串的長(zhǎng)度；value為復(fù)合類型，則表現(xiàn)為元素的個(gè)數(shù)。

bigkey就是redis key/value體系中的大value問題。根據(jù)數(shù)據(jù)類型的劃分，bigkey體現(xiàn)在兩點(diǎn)：

• 存儲(chǔ)數(shù)據(jù)為string類型, value值長(zhǎng)度過大；

• value為復(fù)合類型，包含元素個(gè)數(shù)過多。

在redis中，一個(gè)字符串最大512MB，一個(gè)二級(jí)數(shù)據(jù)結(jié)構(gòu)（例如hash、list、set、zset）可以存儲(chǔ)大約40億個(gè)(2^32-1)個(gè)元素，這是一個(gè)理論值，實(shí)際使用時(shí)，我們可以通過運(yùn)維給到的數(shù)據(jù)來綜合衡量限制數(shù)，一般string類型控制在10KB以內(nèi)，復(fù)合類型hash、 list,、set,和zset元素個(gè)數(shù)不超過5000個(gè)。

二、bigkey有什么危害？產(chǎn)生原因？

看到這里，我們對(duì)bigkey已經(jīng)有一個(gè)初步的了解。接下來，我們針對(duì)bigkey的危害和產(chǎn)生原因一一進(jìn)行介紹。

1、bigkey的四大危害

俗話說“一顆老鼠屎壞掉一鍋湯”，對(duì)于redis而言，bigkey就像是老鼠屎的存在。其危險(xiǎn)性主要表現(xiàn)為以下四個(gè)方面：

1.內(nèi)存空間不均勻

在集群模式中，由于bigkey的存在，會(huì)造成主機(jī)節(jié)點(diǎn)的內(nèi)存不均勻，這樣會(huì)不利于集群對(duì)內(nèi)存的統(tǒng)一管理，存在丟失數(shù)據(jù)的隱患。

2.超時(shí)阻塞

由于redis單線程的特性，操作bigkey通常比較耗時(shí)，也就意味著阻塞redis可能性越大，這樣會(huì)造成客戶端阻塞或者引起故障切換。慢查詢通常就會(huì)有它們的身影。

3.網(wǎng)絡(luò)擁塞

bigkey也就意味著每次獲取要產(chǎn)生的網(wǎng)絡(luò)流量較大。假設(shè)一個(gè)bigkey為1MB，客戶端每秒訪問量為1000，那么每秒產(chǎn)生1000MB的流量，對(duì)于普通的千兆網(wǎng)卡(按照字節(jié)算是128MB/s)的服務(wù)器來說簡(jiǎn)直是滅頂之災(zāi)。

4.阻塞刪除

有個(gè)bigkey，對(duì)它設(shè)置了過期時(shí)間，當(dāng)它過期后會(huì)被刪除，如果使用Redis 4.0之前的版本，過期key是異步刪除，就會(huì)存在阻塞redis的可能性，而且這個(gè)過期刪除不會(huì)從慢查詢發(fā)現(xiàn)（因?yàn)檫@個(gè)刪除不是客戶端產(chǎn)生的，是內(nèi)部循環(huán)事件）。

2、bigkey怎么產(chǎn)生的？

bigkey的產(chǎn)生主要是由于程序的設(shè)計(jì)不當(dāng)所造成的，如以下幾種常見的業(yè)務(wù)場(chǎng)景

• 社交類：粉絲列表，如果某些明星或者大v不精心設(shè)計(jì)下，必是bigkey。

• 統(tǒng)計(jì)類：例如按天存儲(chǔ)某項(xiàng)功能或者網(wǎng)站的用戶集合，除非沒幾個(gè)人用，否則必是bigkey。

• 緩存類：將數(shù)據(jù)從數(shù)據(jù)庫(kù)load出來序列化放到redis里，這個(gè)方式經(jīng)常常用，但有兩個(gè)地方需要注意：第一，是不是有必要把所有字段都緩存；第二，有沒有相關(guān)關(guān)聯(lián)的數(shù)據(jù)。

由此可見，在程序設(shè)計(jì)中，我們要對(duì)數(shù)據(jù)量的增長(zhǎng)和邊界有一個(gè)基本性的評(píng)估，做好技術(shù)選型和技術(shù)架構(gòu)。

三、4種排查發(fā)現(xiàn)bigkey的解決方案

先看一個(gè)思考題：

今天年初，石家莊陸續(xù)爆發(fā)新冠疫情，對(duì)于一個(gè)有著1000萬多人口的中大型城市，疫情防控面臨著巨大的壓力，怎么高效的發(fā)現(xiàn)病毒感染人群和接觸人群，成為疫情防控取勝的關(guān)鍵。政府做了以下幾方面工作，簡(jiǎn)單概括為4點(diǎn)：

1. 禁止人員流通，居家隔離；

2.制定風(fēng)險(xiǎn)等級(jí)；

3.網(wǎng)格化管理；

4.核算檢測(cè)。

根據(jù)流行病醫(yī)學(xué)特點(diǎn)，出現(xiàn)癥狀必須主動(dòng)上報(bào)。這種是主動(dòng)上報(bào)，因?yàn)樾鹿谝咔榫哂幸欢ǖ臐摲?，很多無癥狀患者，因此就需要通過核算檢測(cè)的機(jī)制，主動(dòng)地發(fā)現(xiàn)，這其實(shí)就體現(xiàn)了一種計(jì)算機(jī)處理掃描的思想。

發(fā)現(xiàn)、處理bigkey的思想和疫情防控的做法有些相似，常規(guī)做法也有四種。

1、redis客戶端工具

redis-cli提供了--bigkeys來查找bigkey，例如下面就是一次執(zhí)行結(jié)果。

由于debug object key的執(zhí)行效率很慢，會(huì)存在阻塞redis線程的可能。因此該種方案，對(duì)業(yè)務(wù)也會(huì)存在一定的損傷，在使用時(shí)，可將該執(zhí)行程序運(yùn)行到從節(jié)點(diǎn)之上。

3、RDB文件掃描

我們知道，redis有一種持久化的方案叫做RDB持久化，它是redis內(nèi)存存儲(chǔ)數(shù)據(jù)的一個(gè)磁盤化快照，通過RDB工具對(duì)RDB文件進(jìn)行掃描，可以查找出存在的bigkey。

在選擇這種方案時(shí)，首先需要做RDB文件持久化。RDB持久化是一種內(nèi)存快照的形式，按照一定的頻次進(jìn)行快照落盤，這種方案是一種理想化的選擇，不會(huì)影響redis主機(jī)的運(yùn)行，但在對(duì)數(shù)據(jù)可靠性要求很高的場(chǎng)景，不會(huì)選擇RDB持久化方案，也因此它不具有普遍適用性。

4、DataFlux bigkey的掃描設(shè)計(jì)思想

前面幾種方案，要么由客戶端發(fā)現(xiàn)，要么需要進(jìn)行全量數(shù)據(jù)掃描，掃描是很消耗計(jì)算資源的一種行為。類比疫情，就好比是某千萬人口的城市出現(xiàn)病例后，不分等級(jí)地對(duì)全員進(jìn)行核酸檢測(cè)，這不但消耗巨大的物力、財(cái)力、人力，效率還十分低下，跟需要和時(shí)間賽跑的疫情防控背道而馳。

上文我們也分析了redis bigkey產(chǎn)生的原因，很多都是業(yè)務(wù)的設(shè)計(jì)不合理和評(píng)估不足所導(dǎo)致的。因此DataFlux產(chǎn)品在設(shè)計(jì)中，就讓datakit的redis采集器使用了一種自主配置潛在bigkey進(jìn)行掃描發(fā)現(xiàn)的方案，支持固定key值和key pattern。在key pattern中，通過scan pattern 得到一定范圍的key，再通過length函數(shù)對(duì)每種類型的key（"HLEN""LLEN""SCARD""ZCARD""PFCOUNT""STRLEN"）取值，得到對(duì)應(yīng)的key的length，上報(bào)DataFlux平臺(tái)進(jìn)行監(jiān)控存儲(chǔ)。

這種做法的好處就兩點(diǎn)：

一、由于是針對(duì)目標(biāo)key得到length，而redis中各種數(shù)據(jù)類型的length值獲取都是O(1)時(shí)間復(fù)雜度。因此執(zhí)行效率很高；

二、采集到的結(jié)果數(shù)據(jù)上報(bào)到DataFlux存儲(chǔ)平臺(tái)，在該平臺(tái)下，可以對(duì)指標(biāo)數(shù)據(jù)做各種圖表展示，監(jiān)控告警。

模擬初始隊(duì)列push 10個(gè)value

再push一定量的數(shù)據(jù)

在DataFlux平臺(tái)上，通過指標(biāo)可對(duì)監(jiān)控的key進(jìn)行圖表展示、監(jiān)控報(bào)警以及可視化展示等等，最大幅度呈現(xiàn)數(shù)據(jù)價(jià)值。

感謝各位的閱讀，以上就是“怎么快速排查發(fā)現(xiàn)redis的bigkey”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)怎么快速排查發(fā)現(xiàn)redis的bigkey這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！