Redis 單資料多源超高並發下的解決方案

Redis 是目前最受歡迎的KV快取資料庫，它簡單易用，安全穩定，在網路產業有著非常廣泛的應用。

本文主要跟大家分享 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 單資料多源超高並發下的解決方案的詳細內容。更多資訊請關注PHP中文網其他相關文章！