溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“怎么快速排查發現redis的bigkey”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么快速排查發現redis的bigkey”吧！
redis——互聯網的寵兒
redis作為一款優秀的工業級內存型數據庫，自誕生后便逐漸成為互聯網的寵兒，支撐起了互聯網豐富多彩的功能和巨大的QPS（每秒查詢率），并和nginx一樣成為高性能的代名詞，比如微博上的每一條熱搜背后都有著redis默默守候。從某種意義上來說，redis的使用量也代表著一家互聯網公司的流量。
在馮諾伊曼計算體系中，內存是一種重要的存在。計算和存儲之間存在著一定的辯證關系，通過計算可以減少存儲，通過存儲可以減少一定量的消耗。因此，緩存的思想也成為系統性能減少計算量的一種重要優化手段。
我們看兩張對比圖。
這張是cpu、內存、磁盤的性能對比。內存的讀寫性能是磁盤的近一千倍，redis作為內存型存儲介質，對系統性能提升具有革命性的變化，經濟基礎決定上層建筑，所以經濟效益永遠是第一位的。
再看下各種存儲的價格。
支撐起redis高性能的另一個設計實現就是單線程的任務處理設計。
在面對一個巨大工作量時，為了盡快完成工作任務，通常都會選擇加人，把任務拆解成多份并行處理。這就是一個簡單的多線程并發處理的思想，多線程可以提高任務處理的吞吐量。
那么為什么redis卻反其道而行之，使用單線程的方式？這里的單線程是指Redis 的網絡 IO 和鍵值對讀寫是由一個線程來完成的，這也是 Redis 對外提供鍵值存儲服務的主要流程。
先來看下，如果使用多線程，在處理網絡IO時會存在哪些問題？線程是cpu調度的基本單位，cpu通過時鐘中斷，進行時間片的切換，對外表現出并行處理的效果，任務切換必然消耗資源。當開啟很多的線程，到一定量后，這些切換就會達到性能的瓶頸。
還有一個就是多線程下的資源共享問題，這也是并發編程的核心問題。并發環境下存在資源競爭，就需要對共享資源的臨界區進行加鎖處理，把并發處理轉化為串行化處理，redis的數據結構中，底層使用的hashMap索引數據結構，在多線程處理情況下，必然出現資源爭奪的問題，這即又變成一個串行同步化的處理過程。因此，我們在此否定了多線程。
請求端和服務端通過tcp三次握手后會建立網絡連接，請求數據從網卡被寫入到操作系統的內核緩沖區中，用戶程序執行read操作，會將數據從內核空間寫入到用戶程序執行的變量中，如果內核空間還未收到數據，這里就會發生阻塞等待。
這種處理方式我們顯然是不能夠接受的，為了解決這個技術問題，一種被叫做IO多路復用的技術被創造出來，在linux下一共有三種實現，select、poll、epoll,，簡單來說，該機制允許內核中同時存在多個監聽套接字和已連接套接字，再完成讀寫就緒，通知用戶態來執行。具體這里不做展開，有興趣的朋友可以網上搜下。
nodejs、nginx這些網關層的技術，都是單線程的設計，在處理網絡IO上，單線程要比多線程優異。但是單線程也有其致命的弱點，一旦處理中的某個請求任務處理過長，就會阻塞后邊的請求。這也是后文要展開的bigkey危害的主要原因。就像單行道上，某輛車出現了故障，就會出現堵車現象一個道理。
從上圖的redis底層數據存儲結構中，可以看到value具有多種數據結構的實現，因此，value大小在字符串類型，表現為字符串的長度；value為復合類型，則表現為元素的個數。
bigkey就是redis key/value體系中的大value問題。根據數據類型的劃分，bigkey體現在兩點：
存儲數據為string類型, value值長度過大；
value為復合類型，包含元素個數過多。
在redis中，一個字符串最大512MB，一個二級數據結構（例如hash、list、set、zset）可以存儲大約40億個(2^32-1)個元素，這是一個理論值，實際使用時，我們可以通過運維給到的數據來綜合衡量限制數，一般string類型控制在10KB以內，復合類型hash、 list,、set,和zset元素個數不超過5000個。
看到這里，我們對bigkey已經有一個初步的了解。接下來，我們針對bigkey的危害和產生原因一一進行介紹。
俗話說“一顆老鼠屎壞掉一鍋湯”，對于redis而言，bigkey就像是老鼠屎的存在。其危險性主要表現為以下四個方面：
1.內存空間不均勻
在集群模式中，由于bigkey的存在，會造成主機節點的內存不均勻，這樣會不利于集群對內存的統一管理，存在丟失數據的隱患。
2.超時阻塞
由于redis單線程的特性，操作bigkey通常比較耗時，也就意味著阻塞redis可能性越大，這樣會造成客戶端阻塞或者引起故障切換。慢查詢通常就會有它們的身影。
3.網絡擁塞
bigkey也就意味著每次獲取要產生的網絡流量較大。假設一個bigkey為1MB，客戶端每秒訪問量為1000，那么每秒產生1000MB的流量，對于普通的千兆網卡(按照字節算是128MB/s)的服務器來說簡直是滅頂之災。
4.阻塞刪除
有個bigkey，對它設置了過期時間，當它過期后會被刪除，如果使用Redis 4.0之前的版本，過期key是異步刪除，就會存在阻塞redis的可能性，而且這個過期刪除不會從慢查詢發現（因為這個刪除不是客戶端產生的，是內部循環事件）。
bigkey的產生主要是由于程序的設計不當所造成的，如以下幾種常見的業務場景
社交類：粉絲列表，如果某些明星或者大v不精心設計下，必是bigkey。
統計類：例如按天存儲某項功能或者網站的用戶集合，除非沒幾個人用，否則必是bigkey。
緩存類：將數據從數據庫load出來序列化放到redis里，這個方式經常常用，但有兩個地方需要注意：第一，是不是有必要把所有字段都緩存；第二，有沒有相關關聯的數據。
由此可見，在程序設計中，我們要對數據量的增長和邊界有一個基本性的評估，做好技術選型和技術架構。
先看一個思考題：
今天年初，石家莊陸續爆發新冠疫情，對于一個有著1000萬多人口的中大型城市，疫情防控面臨著巨大的壓力，怎么高效的發現病毒感染人群和接觸人群，成為疫情防控取勝的關鍵。政府做了以下幾方面工作，簡單概括為4點：
1. 禁止人員流通，居家隔離；
2.制定風險等級；
3.網格化管理；
4.核算檢測。
根據流行病醫學特點，出現癥狀必須主動上報。這種是主動上報，因為新冠疫情具有一定的潛伏期，很多無癥狀患者，因此就需要通過核算檢測的機制，主動地發現，這其實就體現了一種計算機處理掃描的思想。
發現、處理bigkey的思想和疫情防控的做法有些相似，常規做法也有四種。
1、redis客戶端工具
redis-cli提供了--bigkeys來查找bigkey，例如下面就是一次執行結果。
由于debug object key的執行效率很慢，會存在阻塞redis線程的可能。因此該種方案，對業務也會存在一定的損傷，在使用時，可將該執行程序運行到從節點之上。
3、RDB文件掃描
我們知道，redis有一種持久化的方案叫做RDB持久化，它是redis內存存儲數據的一個磁盤化快照，通過RDB工具對RDB文件進行掃描，可以查找出存在的bigkey。
在選擇這種方案時，首先需要做RDB文件持久化。RDB持久化是一種內存快照的形式，按照一定的頻次進行快照落盤，這種方案是一種理想化的選擇，不會影響redis主機的運行，但在對數據可靠性要求很高的場景，不會選擇RDB持久化方案，也因此它不具有普遍適用性。
4、DataFlux bigkey的掃描設計思想
前面幾種方案，要么由客戶端發現，要么需要進行全量數據掃描，掃描是很消耗計算資源的一種行為。類比疫情，就好比是某千萬人口的城市出現病例后，不分等級地對全員進行核酸檢測，這不但消耗巨大的物力、財力、人力，效率還十分低下，跟需要和時間賽跑的疫情防控背道而馳。
上文我們也分析了redis bigkey產生的原因，很多都是業務的設計不合理和評估不足所導致的。因此DataFlux產品在設計中，就讓datakit的redis采集器使用了一種自主配置潛在bigkey進行掃描發現的方案，支持固定key值和key pattern。在key pattern中，通過scan pattern 得到一定范圍的key，再通過length函數對每種類型的key（"HLEN""LLEN""SCARD""ZCARD""PFCOUNT""STRLEN"）取值，得到對應的key的length，上報DataFlux平臺進行監控存儲。
這種做法的好處就兩點：
一、由于是針對目標key得到length，而redis中各種數據類型的length值獲取都是O(1)時間復雜度。因此執行效率很高；
二、采集到的結果數據上報到DataFlux存儲平臺，在該平臺下，可以對指標數據做各種圖表展示，監控告警。
模擬初始隊列push 10個value
再push一定量的數據
在DataFlux平臺上，通過指標可對監控的key進行圖表展示、監控報警以及可視化展示等等，最大幅度呈現數據價值。
感謝各位的閱讀，以上就是“怎么快速排查發現redis的bigkey”的內容了，經過本文的學習后，相信大家對怎么快速排查發現redis的bigkey這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
