【技術補給站】第10期：分析內部運行機制，教你解決Redis性能問題

Redis是一種鍵值數據庫，有著時延低、性能好、數據結構豐富的特點，常用作緩存、排行榜、計數器、 消息隊列等，是電商秒殺、聊天系統等業務場景中的“熟客”。

讀懂Redis：緩存神器原來是這樣工作的

一個網站總有大量的數據是用戶共享的，如果每個用戶都去數據庫查詢，效率就太低了。所以有了新的解決方案：將用戶共享數據緩存到服務器的內存中。

舉個例子，應用程序們從MySQL查詢到的數據，會到Redis這里登記，后面再需要用的時候，就先查找Redis的緩存，無需返回到MySQL查找。一套流程下來，為MySQL減輕了不小的負擔，網絡服務的性能顯著提升。

Redis堪稱數據庫屆的萬金油，哪里需要往哪里搬，這也得益于它有著豐富的數據結構，以及強大的讀寫性能。

以數據結構為例，Redis和其他結構化存儲的重要區別便是，它不僅支持字符串，還支持不同類型的抽象數據結構，如列表、映射、集、排序集、HyperLogLogs、位圖、流和空間索引等。那么Redis是如何做到如此“萬能”的，它支持的這些數據結構又是如何從底層實現呢？《三次給你聊清楚Redis》之Redis是個啥 就從非關系型數據庫談起，詳細聊了聊這個問題，就像最簡單的字符串，Redis并未沿襲傳統c語言的慣例，而是單獨構建了一種簡單的動態字符串抽象類型，并充分利用SDS實現。

當我們對Redis的基本原理了然于胸后，再針對業務場景進行優化時，也能更合理地使用各種Redis命令。

Redis性能：禍福相依的內部運行機制

另一方面，Redis為了把內存中的數據持久到磁盤上，也提供了完善的持久化機制，主要包括2種：

RDB：產生一個數據快照文件

AOF：實時追加命令的日志文件

但是如果配置不合理，持久化會占用過多內存從而影響性能。舉個例子，如果AOF的刷盤時機設置為每次寫入都刷盤，由于每次寫命令都需要寫入文件并刷到磁盤中才會返回，當寫入量很大時，會增加磁盤IO的負擔，大大降低Redis的寫入性能。Redis 持久化是如何做的？一文聊聊 RDB和AOF對比分析 談到了這兩種持久化機制對Redis性能的影響，建議大家針對不同的業務場景選擇合適的持久化方式。

在討論Redis性能問題的時候，不得不提的一點是它的單線程結構，這里的單線程指的是執行命令 ，比如一條命令從客戶端到達服務端不會立刻被執行，而是會進入一個隊列中等待，每次只會有一條指令被選中執行。【Redis破障之路】：Redis單線程架構 詳細分析了單線程模型的Redis為什么性能如此之高，能達到每秒萬級別的處理能力，簡單透露兩點：純內存訪問、I/O多路復用技術，具體可以閱讀文章。而Redis的單線程架構，也意味著網絡問題會對它的性能產生一定的影響。

另外，當業務規模擴大，單個Redis服務無法承載的時候，我們常常會用分布式架構來提高Redis的性能，Redis主從復制以及哨兵的原理解讀 和 Redis Sentinel 源碼：Redis的高可用模型分析 都討論了主從模式下的關鍵功能：哨兵，通過對其源碼的理解，詳細說明了哨兵的代碼實現方式，并學會使用哨兵功能解決主節點的寫能力、存儲能力限制等等。

除此之外，諸如數據結構的復雜度、網絡帶寬、操作系統以及硬件本身都會對Redis的性能產生影響，它的性能問題幾乎涵蓋了 CPU、內存、網絡、磁盤的方方面面，再此不一一贅述。

綜上，我們分析了影響Redis性能的一些關鍵內部機制，比如它的緩存淘汰算法；它的持久化會占用過多內存從而影響性能；它的單線程架構等。通過了解Redis的這些內部實現原理，也能進一步幫助大家排查它的性能問題。

Redis調優：宕機怎么辦？收下這幾顆靈丹妙藥

下面，我們將給出一些應對Redis性能問題的解決方案。

以常見的緩存問題為例，通常情況下，Redis緩存層由于某種原因宕機后，所有的請求會涌向存儲層，短時間內的高并發請求可能會導致存儲層掛機，稱之為“Redis雪崩”。Redis緩存異常應對方案分析 有針對性的總結了Redis發生緩存穿透、雪崩、擊穿情況時，能夠有效應對的解決方案，比如不要給訪問頻繁的熱點數據設置過期時間，從而解決Redis實例沒有起到緩存層作用的問題。

另一個經常被詬病性能問題的是fork， fork是開源Redis的一個重要依賴，當 Redis 開啟了后臺 RDB 和 AOF rewrite 后，在執行時，它們都需要主進程創建出一個子進程進行數據的持久化，fork就是創建子進程的系統調用函數。

在華為云GaussDB(for Redis)服務團隊支撐某客戶業務上云的過程中 ，就發現了由fork引發的時延抖動問題，文章一場由fork引發的超時，讓我們重新探討了Redis的抖動問題 還原了當時的場景，探究了fork對性能的影響，包括業務抖動、內存率利用率降低和實例容量受限。比如，在電商大促、熱點事件等業務高峰時發生上述fork，會導致Redis阻塞，進而對業務造成雪崩的影響。

團隊通過修改日志、系統性排查整改代碼中的 fork調用，最后在新版本GaussDB(for Redis)中解決了該問題，并清零了內部的fork使用，與原生Redis相比，徹底解決了fork的性能隱患。

其實，考慮到業務場景越來越復雜，原生Redis出現性能瓶頸難以避免。這時候，最簡單粗暴的解決方法就是使用商業版本的Redis，一勞永逸解決可能存在的性能問題。

在 GaussDB(for Redis)與原生Redis集群的性能對比 中，就比較了華為云自研Redis和原生Redis集群在X86架構下的性能測試報告，結果表明GaussDB(for Redis)在性能、抗寫和存儲成本上的優勢明顯。

從相識到相惜：Redis與計算存儲分離四部曲 進一步從技術角度拆解分析了GaussDB(for Redis)如何在存算分離的架構下，實現強一致、秒擴容、超可用、低成本。以強一致為例，Redis遇到流量壓力進行主從切換時很容易發生數據不同步問題，GaussDB ( for Redis)就在存儲層（DFV層）去進行強一致的數據同步，而非計算層，這樣就避免了任何中間態下的數據的不一致，再也不用擔心宕機導致數據丟失。更多的技術細節揭秘，也可以閱讀這組專題高斯Redis揭秘系列文章，更全面的認識GaussDB ( for Redis)。

Redis的性能問題，涉及到的技術細節很多，本專題只是列出了一些較為典型的問題，希望讀者能夠通過上述提及的技術文章，對它有更深入的認識，學會從底層運行機制去思考Redis的性能調優。

最后

福利時間到，小編準備了3個小問題，參與互動的小伙伴有機會獲得由華為云社區提供的開發者大禮包，任選其一回答即可。

問題1：例舉1個會讓Redis變慢的現象和原因。

問題2：簡單說說你用過的Redis性能調優方案。

問題3：如何避免Redis集群異步復制可能帶來的數據丟失，強一致性實現方法有哪些？

歡迎大家踴躍參加。

技術補給站

聚焦熱門的細分技術領域，帶來系統且專業的干貨解讀，從而為開發者提供新技術知識的補給，助力技術能力更上一層樓。

往期回顧

【第1期】 中臺規劃：重磅發布！《IT 2.0時代，華為全場景驅動下中臺規劃實戰全集》

【第2期】數倉調優：數倉性能調優必讀：從系統級到SQL級，帶你進階為性能調優高手

【第3期】依賴圖繪制：學習大數據治理，手把手教你從零開始畫DAG作業依賴圖

【第4期】音視頻：音視頻爆火的背后，藏著哪些技術奧秘？華為云視頻云專家為你深度解讀

【第5期】云原生：從架構和實踐，剖析KubeEdge+Volcano技術硬實力

【第6期】LiteOS實操：帶你步步深入LiteOS，掌握物聯網開發秘笈

【第7期】 API應用：20個超實用API應用案例，開啟API進階之路（內附資料下載）

【第8期】 HiLens開發：用好ModelArts+HiLens，輕松上手端云協同AI開發

【第9期】 從Angular、React到Vue，探秘三大主流前端框架

Redis 云數據庫 GaussDB(for Redis) 數據庫 緩存

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。