本文主要給大家分享一下 Redis 在單數據多源超高并發訪問下的解決思路和方案。

前言

Redis 主要解決兩個問題：

當遇到日活千萬，同時百萬在線的業務場景時，前端訪問直接加載到后臺數據庫的話，可能順間壓垮底層數據庫，導致業務停擺。又或者隨著查詢條件變多，結合條件復雜化，查詢結果的響應時間也無法得到保證，導致用戶體驗下降，用戶流失。為了解決高并發，低延遲的業務場景， Redis 應運而生。

下面我們來看兩個場景

這是一個線上找房的業務場景，超多的查詢條件導致后臺必然是一個復雜的查詢 SQL，這種場景下是否必須使用 Redis 呢？

答案是否定的，由于線上找房業務并發量低，客戶對于業務響應時間要求也沒有那么苛刻，大部分的請求可以直接通過動態 SQL 臨時查詢。當然為了提升用戶體驗，可以將一些熱點的查詢結果預緩存到 Redis 里提升用戶體驗。

我們再來看下這個場景

視頻應用的查片系統，跟找房系統幾乎是一模一樣的業務場景，但是并發量要高幾個數量級，這個場景就非常適合使用 Redis 作為緩存提升并發訪問量，降低響應時間，滿足幾十萬甚至上百萬的并發訪問需求。由此可見決定是否使用 Redis 的根本要素就是并發量和延遲要求。

下面我們來看一下 Redis 是如何解決互聯網極端場景下的并發訪問需求的。

超高并發訪問下的緩存解決方案

這是一個典型的媒體類緩存架構圖，發文系統不定期更新媒體庫，通過分布式緩存服務將各個最新文章同步到 Redis 緩存，前端應用通過路由層找到相應的數據源訪問。各個緩存服務數據不同步。當發生熱點事件時，路由層可能將不通地區的訪問路由到熱點數據所在的緩存服務器，帶來瞬間的流量暴漲，極端情況下可能導致服務器宕機，業務受損。那么這種不定期突發流量的場景要如何解決呢？

這里有幾個思路：

將熱點 Key 加前綴打散，實現熱數據復制

路由層追加本地緩存，通過多級緩存提升緩存能力

緩存層提供數據副本，提高并發訪問能力

第一種方案，可以有效打散熱數據，但是熱點事件是不定期隨機發生，運維壓力大，成本高，這只是個頭痛醫頭腳痛醫腳的方案。

第二種方案，可以通過追加本地緩存提升緩存能力，但是本地緩存設置多大，刷新頻率多高，業務是否能容忍臟讀，這些都是無法繞開的問題。

第三種方案，可以追加只讀副本來實現數據的復制，但是同樣也會帶來成本高企，主庫負載高等問題。

上面這個架構圖是一個優化的解決方案，通過主庫拉取多個只讀從庫的分支，對不同的請求源，劃分獨立的緩存服務。比如手機應用就固定路由到APP數據資源組，WEB 訪問就路由到WEB 數據資源組等，并且每個資源組可以提供N個只讀副本，提高同源訪問下的并發訪問能力。這種架構可以提升不同訪問源的資源隔離能力，提升多源訪問下業務的穩定性和可用性。

這個方案的問題也比較明顯：

主庫讀寫性能差

只讀副本多，成本高

只讀鏈路過長，管理維護難，運維成本高

我們的客戶里最夸張的用到過 1主40只讀的架構，來滿足類似的業務場景。

阿里云Redis是如何解決這種超高并發訪問的問題呢？

阿里云重磅推出Redis性能增強版本，通過提升網絡IO的并發處理能力，極大的提升了Redis單節點的讀寫性能，對比社區版本，性能提升3倍。由于保持單 Worker 的處理模式，100% 兼容 Redis 協議。上面的單數據百萬QPS 的訪問能力輕松達成。本文介紹的媒體類場景可以通過開通性能增強版1主5只讀實例實現單數據200w+ QPS，有效緩解突發熱點事件帶來的流量激增，超高并發訪問等行業痛點問題。相比較自建1主40只讀的社區版本，同樣性能標準的阿里云Redis性能增強版1主5只讀架構更穩定，管理更便捷，使用也更方便。

以上就是Redis 單數據多源超高并發下的解決方案的詳細內容，更多請關注 其它相關文章！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。