redis系統性學習一:緩存和redis相關基礎知識

redis其實用了很久了,只是一直侷限於基礎的使用,都是簡單的命令行操作,以及簡單的java集成和api調用。
對於這樣一個分佈式場景不可或缺的中間件,還是很有必要系統性的學習和理解一下的。

redis是什麼

提到redis,很多人可能都知道這是一個緩存,並且由於支持持久化存儲,也有人叫它緩存數據庫。
redis一般用作緩存,但是用作緩存的卻不止redis這一個,記得我剛入行的時候,用的緩存其實是memcached。
memcached和redis一樣,都是基於K:V和內存的,但是不同的是,memcached的value只支持String類型,而redis的value卻支持5種數據類型。同時,redis還支持本地方法,以及持久化存儲。
不論是更多的數據類型,還是本地方法,都使得redis的應用場景相較memcache更廣泛、更方便。

緩存的作用

緩存更多的意義應該能夠理解爲暫存,存的當然就是數據。
對於任何一個軟件系統來說,必須是有數據纔會有實際的意義,不論這個數據來源於數據採集、用戶輸入、靜態定義、初始化導入還是網絡傳輸。
不管是何種數據來源,大多數系統都會選擇存儲一定的數據,存儲方式通俗的講可能有數據庫、文件、內存、緩存,但是仔細想想會發現其實應該就是兩種。
數據庫的持久化存儲最終其實也是以文件的方式存儲,只不過數據庫存儲數據的文件和普通文本不一樣而已。
緩存其實也是基於內存的,只是通常所說的緩存基本都是基於一定中間件,例如memcached和redis,而拿java開發語言來說,如map、list、array這些容器,也能存儲數據,不過是一般直接稱作內存而已。
這兩種存儲,涉及到不同的硬件,一是硬盤,一是內存,兩種不同的硬件支持的存儲容量和存取速度不一樣,也就直接影響了兩種數據存取方式的差異。
內存更快,也就使得緩存在高性能的業務場景下必不可少了。

分佈式的理解

分佈式是個現在很火的概念,開頭也說了redis是分佈式場景下現在不可或缺的一箇中間件。
那麼分佈式到底是什麼呢,想了想,似乎不太容易一兩句話說清楚。
簡單的說,分佈式系統就是相對於傳統的單體應用,進行了一定的拆分,從而實現了多點處理或者多點部署,從架構層面加上了負載均衡。
傳統的單體應用,所有的功能都在一起,高度的耦合,架構可能如下:
在這裏插入圖片描述
這種架構維護起來非常簡單,對於java來說就是一個project,開發完了往tomcat等服務器裏一扔。
但是由於數據庫的操作總是涉及到磁盤的io,所以一旦用戶量和請求量多了,數據庫就成了系統的瓶頸,於是這種系統進一步發展爲數據庫集羣模式,如下圖:
在這裏插入圖片描述
那麼這種架構是否就算是分佈式了呢?在沒有一個絕對的定義下,我覺得應該某種程度來講就已經算了,只不過這是局部的分佈式。
這時候可能就有一個疑惑,分佈式和分部式,是不是一樣的東西,因爲乍一看起來,這就是數據庫加了節點部署,可能是主從集羣,可能是副本集,也可能是分片。
數據庫加節點,一定程度上解決了數據庫性能問題,但是這不是唯一的解決方案,另一個技術就是緩存。
本人從事軟件工作也才五六年而已,因此究竟是數據庫集羣先出現,還是緩存技術先出現,還真不是很確定,只知道從目前的的多數系統來說,數據層面可能都是數據庫集羣和緩存同時存在,於是整個系統可能進一步發展爲如下所示:
在這裏插入圖片描述

經過互聯網進一步發展,網絡用戶越來越多,硬件性能也越來越好,再加上緩存的加入,最終數據庫的瓶頸在各方面影響下,不再是瓶頸,而後臺系統本身的性能以及健壯性就成了問題。
在計算機中,一個應用是一個進程,由cpu管理,一個進程本身的資源和性能肯定是有限的,當各種功能模塊都在一個應用中時,性能和可用性都會互相影響,於是應用本身的多節點部署,再借助負載均衡,就演變成了新的架構模式:
在這裏插入圖片描述
這種架構,嚴格來講只能算是部署架構,是原本的單節點應用多節點部署,再使用硬件負載均衡F5或者軟件負載均衡nginx實現請求的路由轉發。
這種架構,看起來,從開發層面來講,沒有太大的區別。但實際上多節點的部署必然涉及到數據的共享,從某種程度而言,這時候用到的緩存如果是redis,可能就還會使用redis保證某些數據的一致性。
這種架構一定程度上解決了大量用戶和大量請求時處理不過來的問題,但是從開發和代碼維護等各方面考慮,系統各功能本身的耦合性依舊太高,於是系統本身再進一步拆分,從單體應用演變成模塊化的多點應用:
在這裏插入圖片描述
系統從單體按模塊拆分成不同的應用,這時候新的問題除了數據共享之外,不同應用間的交互也是問題,可以是單純的http,也可以是性能更好的rpc遠程過程調用,從我以往經歷的項目來看,都是存在的。
但是不論哪種,如果都是單純的開發自己實現,其實還是會顯得麻煩。於是進一步就出現了分佈式註冊中心,以及微服務這些架構,在我看來,其實就是更好的解決了應用模塊化拆分,和應用間信息交互。
單體應用拆分多點應用,各模塊多點部署,消息隊列及緩存等中間件進一步提升系統可用性,加上各種負載均衡的路由分發,以及最後的數據分析和日誌分析及運維管理,就組成了現在這種架構更加複雜的分佈式架構和分佈式系統。

併發和並行

說到分佈式,學習redis,一開始有兩個重要的概念,即併發和並行,這兩個詞是很有區別的。在上邊的架構演進圖中,其實也可以看到。
首先,有兩個客戶端,同時發起請求,其實這就是併發。那麼顧名思義,高併發其實就是非常多的客戶端在一段時間內發起大量的請求。
而並行,實際可以理解爲同樣的功能多點部署,同時運行,並行來處理同樣的請求。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章