本文
- 前言
- 認識Redis
- 單機架構
- 淺談分布式系統
- 分布式是什么
- 數據庫分離和負載均衡
- 引入緩存
- 數據庫分庫分表
- 引入微服務
- 念補充
- 小結
- Redis特性介紹
- 持久化
- 支持集群
- 高可用
- 快
- Redis的應用場景
- 總結
前言
在當今這個數據驅動的時代,應用的性能和可擴展性已成為衡量其成功的關鍵指標。當傳統的單機架構面對日益增長的用戶量和數據洪流而顯得力不從心時,分布式系統便應運而生。然而,系統的分布式演進也帶來了新的挑戰:如何在多臺服務器之間高效、快速地共享和訪問數據?
這篇文章將帶您認識一個在分布式世界中扮演著至關重要角色的技術——Redis。我們將從最基礎的單機架構出發,一步步探索系統如何演進為復雜的分布式集群,并在這個過程中揭示Redis作為高性能內存數據庫和緩存中間件的核心價值。無論您是剛入門的開發者,還是希望深化對系統架構理解的工程師,本文都將為您提供一個清晰的路線圖,幫助您理解Redis為何能成為現代高性能應用不可或缺的基石。
認識Redis
在內存中進行數據存儲
但是我們定義變量不是在內存中進行存儲么,那么我們使用redis不是饒了個圈么?
redis是在分布式系統中,才能發揮作用
如果只是單機程序,直接通過變量存儲數據的方法是比使用redis更優的選擇
在分布式系統中定義變量肯定是不行的,因為進程是具有隔離性的,如果是分布式系統的話肯定是涉及到多個進程的,甚至說這多個進程是分布在不同的主機上,而你想共享別的進程的變量肯定是不行的
所以Redis是基于網絡,將自己內存中的變量分享給別的進程,甚至給別的主機中的進程進行使用
mysql現在最大的問題在于,訪問速度比較慢,數據在硬盤上
redis也可以作為數據庫,在內存上的,速度快
計算機訪問內存的速度比訪問硬盤的速度快
定性的角度,可以知道redis快很多,但是很難定量衡量,因為mysql和redis具體功能和使用場景都不同
redis和mysql相比,最大的劣勢,存儲空間是有限的,內存比較小
從功能和存儲空間的角度來說,還是mysql更勝一籌的
那么是否存在一個機制,讓存儲速度快,存儲空間大呢
典型的方案就是將mysql和redis結合起來進行使用
用redis作為mysql的cache,將我們經常訪問的數據使用redis進行存儲,全量數據還是放在mysql中進行存儲
代價就是系統的復雜程度大大提升了,如果數據發生成修改的話,還涉及到mysql和redis之間的同步問題
redis的初心,最初就是用來作為一個"消息中間件"的(消息隊列)
分布式系統下的生產消費模型
但是當前很少會使用redis作為消息中間件,因為界內有更多專業的消息中間件
單機架構
單機架構,只有一臺服務器,這個服務器負責所偶的工作
這里使用的服務器可以是mysql
mysql是一個客戶端服務器結構的陳旭
本體是mysql服務器(存儲和組織數據的部分)
絕大部分公司的產品都是這種單機架構
如果業務進一步增長了,用戶量和數據量都水漲船高了,一臺主機難以應付的時候,就需要引入更多的主機,引入更多的硬件資源
淺談分布式系統
分布式是什么
一臺主機的硬件資源是有上限的
硬件資源包括不限于下面幾種:CPU、內存、硬盤、網絡
服務器每次收到一個請求,都是需要消耗上述的一些資源的
如果同一時刻,處理的請求多了,此時就可能會導致某個硬件資源不夠用了
無論是哪個方面不夠用了,都可能會導致服務器處理請求的時間變長了,甚至于處理出錯
如果我們真的遇到這樣的服務器不夠的情況,如何進行處理呢
1、開源 增加更多的硬件資源(但是一個主機上能增加的硬件資源也是有限的)
2、節流(軟件上的優化)
一臺主機擴展到極限了,但是還是不夠,就只能引入多態主機了
一但引入多臺主機,咱們的系統就可以成為是“分布式系統”
引入分布式,這是萬不得已
系統的復雜程度會大大提高的
數據庫分離和負載均衡
應用服務器,里面可能會包含很多的業務邏輯,可能會吃CPU和內存
數據庫服務器,需要更大的硬盤空間,更快的訪問速度,可以配置更大硬盤的服務器
引入更多的應用服務器節點,應用服務器可能比較吃CPU和內存,如果把CPU和內存吃沒了,此時應用服務器就頂不住了,引入更多的應用服務器,就可以有效解決上述問題了
用戶的請求先到達負載均衡器/網關服務器
假設有1w個用戶請求,有2個應用服務器的話,此時按照負載均衡的方式,就可以讓每個應用服務器承擔5k的訪問量
這個就和多線程其實很相似的
負載均衡器,對于請求量的承擔能力,要遠超過于應用服務器的
負載均衡器是領導,分配工作
應用服務器,是組員,執行任務
也可能請求量大道負載均衡器也扛不住了
那么我們就得引入更多的負載均衡器
增加應用服務器,確實能夠處理更高的請求量
但是隨之存儲服務器,要承擔的請求量也就更多了
實際的應用場景中,讀的頻率比寫更高的
引入更多的從服務器
主服務器只有一個
同時從數據庫通過負載均衡的方式,讓應用服務器進行訪問
通過這樣降低單臺服務器的壓力
引入緩存
數據庫天然問題,相應速度是更慢的!!
把數據區分"冷熱",熱點數據放到緩存中~緩存的訪問速度往往比數據庫快很多了
在數據庫讀寫分離的基礎上,這里引入了緩存服務器,存放一小部分熱點數據(會頻繁被訪問的數據)
所以冷數據就是不會被頻繁訪問的數據
緩存要想快,就得付出代價
redis就是要作為緩存服務器
對應用服務器來說,絕大多數的請求都能從緩存服務器中找到答案,這就是我們的數據庫服務器承擔的壓力變小了,并且我們的緩存服務器讀取速度還快
緩存服務器幫助數據庫服務器負重前行了
要想得到一個效果,就要付出一定的代價
數據庫分庫分表
引入分布式系統不光要應對更高的請求量(并發量),同時能應對更大的數據量
可能會出現,一臺服務器已經存不下數據了,雖然一個服務器的存儲量可以到幾十個TB,即使如此也可能會存不下
一臺主機存不下,就得需要多臺主機了
針對數據庫進行進一步的拆分
分庫分表
本來是一個數據庫服務器,這個數據庫服務器上有多個數據庫(指的是邏輯上的數據集合,create database創建的那個東西)
現在就可以引入多個數據庫服務器,每個數據庫服務器存儲一個或者一部分數據庫
如果某個表特別大,大到一臺主機存不下,也可以針對表進行拆分
具體分庫分表如何時間,還是要結合實際的業務場景來展開
業務至關重要
引入微服務
微服務架構
之前的應用服務器,一個服務器程序里面做了很多的業務,這就可能會導致這一個服務器的代碼越來越復雜了,為了更方便于代碼的維護,就可以把這樣的一個復雜的服務器,拆分成更多的,功能更單一,更下的服務器,我們將這樣小的服務器成為微服務
服務器的種類和數量就增加了
最開始引入負載均衡解決的問題是請求量更高的問題
后面引入的分庫分表解決的是存儲空間不足的問題
那么微服務本質上解決的是“人”的問題
當應用服務器變復雜了,那么勢必就需要更多的人來維護了
當人多了,就需要配套的管理,把這些人組織好
因此就得劃分組織結構,分成多個組,每個組配備領導進行管理
分成多個組之后,就需要進行分工了
按照功能,拆分成多組微服務,這樣就有利于上述人員組織的結構的分配了
如果是小公司,就幾個開發,那么就沒必要搞微服務了
引入微服務,解決了人的問題,會有什么代價呢?
1、性能會下降(想保證性能不下降,只能引入更多的機器,更多的硬件資源)
拆出來更多的服務,多個功能之間更要依賴網絡通信,
網絡通信的速度很可能是比硬盤還慢的
2、系統復雜程度提高,可用性受到影響
服務器更多了,出現問題的概率更大了
這就需要一些列的手段保證系統的可用性
微服務的優勢:
1、解決了人的問題
2、使用微服務,可以更方便于功能的復用
3、可以給不同的服務去進行不同的部署
念補充
分布式,引入多個主機/服務器,協同配合完成一系列的工作
主從是分布式系統中一種比較經典的結構
多個服務器節點,一個是主,另一個是從,從節點的數據主要從主節點這里同步過來~~
中間件和業務無關的服務(功能更通用的服務)
- 數據庫
- 緩存
- 消息隊列
吞吐和并發是衡量系統的處理請求的能力,衡量性能的一種方式
小結
1、單機架構(應用程序+數據庫服務器)
2、數據庫和應用分離
應用程序和數據庫服務器分別放到不同主機上部署了
3、引入負載均衡:應用服務器=>集群
通過負載均衡器,把請求比較君均勻的分發給集群中的每個應用服務器
當整個系統中的某個主機掛了,其他主機仍然可以承擔服務,提高了整個系統的可用性
4、引入讀寫分離,數據庫主從結構
一個數據庫節點作為主節點,其他n個數據庫節點作為從節點
主節點負責寫數據,從節點負責讀數據
主節點需要把愛修改過的數據同步到從節點
5、引入緩存,冷熱數據分離
進一步提升了服務器針對請求的處理能力
二八原則
6、引入分庫分表,數據庫能夠進一步擴展存儲空間
7、引入微服務,從業務上進一步拆分應用服務器
從后業務功能的角度,把應用服務器,拆分成更多的功能單一,更簡單,更小的服務器
所謂的分布式系統,就是想辦法引入更多的硬件資源
Redis特性介紹
Redis是一個在內存中存儲數據的中間件,用于作為數據庫,用于作為數據緩存
在分布式系統中能夠大展拳腳
Redis的一些特定(優點)
Redis在內存中存儲數據
mysql主要是通過"表"的方式來存儲組織數據的“關系型數據庫”
Redis主要是通過“鍵值對”的方式來存儲數據的 非關系型數據庫
針對Redis的操作,可以直接通過簡單的交互式命令進行操作
也可以通過一些腳本的方式,批量執行一些操作
持久化
Redis 持久化
內存中的數據是易失的
Redis會把數據存儲在硬盤上
內存為主,硬盤為輔
硬盤相當于對內存的數據備份一下
如果Redis重啟了,就會在重啟時加載硬盤中的備份數據,使Redis的內存恢復到重啟前的狀態
支持集群
Redis 作為一個分布式系統的中間件,能夠支持集群是很關鍵的
這個水平拓展的意思即是“分庫分表”
一個Redis 能存儲的數據是有限的(內存空間有限)
引入多個主機,部署多個Redis
引入多個主機,部署多個Redis 節點,每個存儲數據的一部分
高可用
高可用=>冗余/備份
Redis自身也是支持主從結構的
從節點就相當于主節點的備份了
快
1、Redis數據存在內存中,就比訪問硬盤的數據庫,要快很多
2、Redis的核心功能都是比較簡單的邏輯—核心功能都是比較簡單的操作內存的數據結構
3、網絡角度上,Redis使用了IO多路復用的方式(epoll)—使用一個線程,管理很多個socket
4、Redis使用的是單線程模型,這樣的單線程模型,減少了不必要的線程之間的競爭開銷
多線程提高效率的前提是,CPU密集型的任務,使用多個線程可以充分的利用CPU多核資源
但是Redis得核心任務,主要就是操作內存的數據結構,不會吃很多的CPU
Redis的應用場景
- 實時的數據存儲,將Redis當做數據庫(通過鍵值對進行數據存儲)
大多數情況下,考慮到數據存儲,有限考慮的是“大”
但是仍然有一些場景,考慮的是“快”
- 作為緩存
2、將會話數據單獨拎出來,放到一組獨立的機器上存儲(Redis)
分布式系統來說,服務器和服務器之間,有時候也需要使用到生產者消費者模型的
解耦合
削峰填谷
Redis也是已提供了消息隊列的功能的
如果當前場景中,對于消息隊列的功能依賴的不是很多
并且又不想引入額外的依賴了,Redis可以作為一個選擇
Redis不能存儲大規模數據
總結
本文深入探討了Redis的背景、核心特性及其在現代分布式系統中的關鍵作用。核心要點總結如下:
Redis的核心定位:Redis是一個開源的、基于內存存儲的鍵值對(Key-Value)非關系型數據庫。它通過網絡為分布式系統中的多個進程提供高速的數據共享服務,其訪問速度遠超于基于硬盤的傳統數據庫(如MySQL)。
分布式系統的演進與Redis的價值:隨著業務量的增長,系統架構從簡單的單機模式,逐步演進為應用與數據庫分離、引入負載均衡、實現數據庫讀寫分離的復雜結構。在這一過程中,為了解決數據庫的訪問瓶頸,引入Redis作為緩存層成為關鍵一步。通過將頻繁訪問的“熱數據”放入Redis,可以極大減輕數據庫的壓力,并顯著提升應用的響應速度。
Redis的核心特性:
速度快:數據存儲在內存中,同時采用I/O多路復用和單線程模型,減少了不必要的上下文切換開銷。
持久化:支持將內存數據異步寫入硬盤,確保了數據在服務重啟后不會丟失。
高可用與可擴展:通過主從復制(Master-Slave)架構保障高可用性,并通過集群模式實現水平擴展,以應對海量數據的存儲需求。
豐富的數據結構:支持字符串、哈希、列表、集合、有序集合等多種數據類型,能靈活應對各種業務場景。
主要應用場景:
數據緩存:最核心的應用,作為MySQL等主數據庫的緩存,分離冷熱數據。
會話共享(Session Store):在分布式Web服務中,集中存儲用戶會話信息,解決負載均衡下的會話一致性問題。
實時數據存儲:適用于對速度要求極高的場景,如排行榜、計數器等。
消息隊列:可用于實現簡單的生產者-消費者模型,進行服務間的解耦和流量削峰。
總而言之,Redis憑借其卓越的性能和靈活性,已成為構建高性能、高并發和高可用性分布式系統的關鍵中間件。理解Redis不僅是掌握一個工具,更是深入理解現代應用架構演進思想的重要一環。