您好,登錄后才能下訂單哦!
這篇文章主要介紹了Redis單數(shù)據(jù)多源超高并發(fā)下的解決方法,具有一定借鑒價(jià)值,需要的朋友可以參考下。希望大家閱讀完這篇文章后大有收獲。下面讓小編帶著大家一起了解一下。
Redis 主要解決兩個(gè)問題:
當(dāng)遇到日活千萬,同時(shí)百萬在線的業(yè)務(wù)場(chǎng)景時(shí),前端訪問直接加載到后臺(tái)數(shù)據(jù)庫的話,可能順間壓垮底層數(shù)據(jù)庫,導(dǎo)致業(yè)務(wù)停擺。又或者隨著查詢條件變多,結(jié)合條件復(fù)雜化,查詢結(jié)果的響應(yīng)時(shí)間也無法得到保證,導(dǎo)致用戶體驗(yàn)下降,用戶流失。為了解決高并發(fā),低延遲的業(yè)務(wù)場(chǎng)景, Redis 應(yīng)運(yùn)而生。
下面我們來看兩個(gè)場(chǎng)景
這是一個(gè)線上找房的業(yè)務(wù)場(chǎng)景,超多的查詢條件導(dǎo)致后臺(tái)必然是一個(gè)復(fù)雜的查詢 SQL,這種場(chǎng)景下是否必須使用 Redis 呢?
答案是否定的,由于線上找房業(yè)務(wù)并發(fā)量低,客戶對(duì)于業(yè)務(wù)響應(yīng)時(shí)間要求也沒有那么苛刻,大部分的請(qǐng)求可以直接通過動(dòng)態(tài) SQL 臨時(shí)查詢。當(dāng)然為了提升用戶體驗(yàn),可以將一些熱點(diǎn)的查詢結(jié)果預(yù)緩存到 Redis 里提升用戶體驗(yàn)。
我們?cè)賮砜聪逻@個(gè)場(chǎng)景
視頻應(yīng)用的查片系統(tǒng),跟找房系統(tǒng)幾乎是一模一樣的業(yè)務(wù)場(chǎng)景,但是并發(fā)量要高幾個(gè)數(shù)量級(jí),這個(gè)場(chǎng)景就非常適合使用 Redis 作為緩存提升并發(fā)訪問量,降低響應(yīng)時(shí)間,滿足幾十萬甚至上百萬的并發(fā)訪問需求。由此可見決定是否使用 Redis 的根本要素就是并發(fā)量和延遲要求。
下面我們來看一下 Redis 是如何解決互聯(lián)網(wǎng)極端場(chǎng)景下的并發(fā)訪問需求的。
超高并發(fā)訪問下的緩存解決方案
這是一個(gè)典型的媒體類緩存架構(gòu)圖,發(fā)文系統(tǒng)不定期更新媒體庫,通過分布式緩存服務(wù)將各個(gè)最新文章同步到 Redis 緩存,前端應(yīng)用通過路由層找到相應(yīng)的數(shù)據(jù)源訪問。各個(gè)緩存服務(wù)數(shù)據(jù)不同步。當(dāng)發(fā)生熱點(diǎn)事件時(shí),路由層可能將不通地區(qū)的訪問路由到熱點(diǎn)數(shù)據(jù)所在的緩存服務(wù)器,帶來瞬間的流量暴漲,極端情況下可能導(dǎo)致服務(wù)器宕機(jī),業(yè)務(wù)受損。那么這種不定期突發(fā)流量的場(chǎng)景要如何解決呢?
這里有幾個(gè)思路:
將熱點(diǎn) Key 加前綴打散,實(shí)現(xiàn)熱數(shù)據(jù)復(fù)制
路由層追加本地緩存,通過多級(jí)緩存提升緩存能力
緩存層提供數(shù)據(jù)副本,提高并發(fā)訪問能力
第一種方案,可以有效打散熱數(shù)據(jù),但是熱點(diǎn)事件是不定期隨機(jī)發(fā)生,運(yùn)維壓力大,成本高,這只是個(gè)頭痛醫(yī)頭腳痛醫(yī)腳的方案。
第二種方案,可以通過追加本地緩存提升緩存能力,但是本地緩存設(shè)置多大,刷新頻率多高,業(yè)務(wù)是否能容忍臟讀,這些都是無法繞開的問題。
第三種方案,可以追加只讀副本來實(shí)現(xiàn)數(shù)據(jù)的復(fù)制,但是同樣也會(huì)帶來成本高企,主庫負(fù)載高等問題。
上面這個(gè)架構(gòu)圖是一個(gè)優(yōu)化的解決方案,通過主庫拉取多個(gè)只讀從庫的分支,對(duì)不同的請(qǐng)求源,劃分獨(dú)立的緩存服務(wù)。比如手機(jī)應(yīng)用就固定路由到APP數(shù)據(jù)資源組,WEB 訪問就路由到WEB 數(shù)據(jù)資源組等,并且每個(gè)資源組可以提供N個(gè)只讀副本,提高同源訪問下的并發(fā)訪問能力。這種架構(gòu)可以提升不同訪問源的資源隔離能力,提升多源訪問下業(yè)務(wù)的穩(wěn)定性和可用性。
這個(gè)方案的問題也比較明顯:
主庫讀寫性能差
只讀副本多,成本高
只讀鏈路過長,管理維護(hù)難,運(yùn)維成本高
我們的客戶里最夸張的用到過 1主40只讀的架構(gòu),來滿足類似的業(yè)務(wù)場(chǎng)景。
阿里云Redis是如何解決這種超高并發(fā)訪問的問題呢?
阿里云重磅推出Redis性能增強(qiáng)版本,通過提升網(wǎng)絡(luò)IO的并發(fā)處理能力,極大的提升了Redis單節(jié)點(diǎn)的讀寫性能,對(duì)比社區(qū)版本,性能提升3倍。由于保持單 Worker 的處理模式,100% 兼容 Redis 協(xié)議。上面的單數(shù)據(jù)百萬QPS 的訪問能力輕松達(dá)成。本文介紹的媒體類場(chǎng)景可以通過開通性能增強(qiáng)版1主5只讀實(shí)例實(shí)現(xiàn)單數(shù)據(jù)200w+ QPS,有效緩解突發(fā)熱點(diǎn)事件帶來的流量激增,超高并發(fā)訪問等行業(yè)痛點(diǎn)問題。相比較自建1主40只讀的社區(qū)版本,同樣性能標(biāo)準(zhǔn)的阿里云Redis性能增強(qiáng)版1主5只讀架構(gòu)更穩(wěn)定,管理更便捷,使用也更方便。
感謝你能夠認(rèn)真閱讀完這篇文章,希望小編分享Redis單數(shù)據(jù)多源超高并發(fā)下的解決方法內(nèi)容對(duì)大家有幫助,同時(shí)也希望大家多多支持億速云,關(guān)注億速云行業(yè)資訊頻道,遇到問題就找億速云,詳細(xì)的解決方法等著你來學(xué)習(xí)!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。