當資料庫成為訪問瓶頸時的優化方案

2021-10-07 22:37:20 字數 1770 閱讀 5701

這篇文章只是記錄一下我們團隊開發過程中遇到的資料庫訪問慢時的解決思路,不一定能得到大家想要的答案,但我希望可以讓各位有所思考,有所討論。

上個月我們經理把我叫了過去,說我們的產品的某些頁面開啟速度太慢了,要等好幾秒。我十分驚訝,因為我把所有的功能都看過一遍的,沒有哪個功能效率這麼低下。我看了一下資料才明白,新客戶的資料是老客戶的數十倍,導致資料庫查詢時長翻了更多倍。

於是我找到技術中臺負責人,希望他們能提供一套資料庫快取訪問方案。當查詢資料時不優先查詢資料庫,而是查詢快取來提高查詢效率。得到的答覆是近期太忙,沒時間整這個。

由於技術中臺暫時沒有時間來做支撐,所以我們團隊只能暫時做乙個臨時快取方案。於是我讓我們團隊的人員自行把高頻查詢並且不太會變動的資料,如部門結構和使用者資訊等資料,在查詢的時候先從redis中讀取,redis中沒有的話再從資料庫中讀取並存入redis中。

這個流程看著沒什麼問題,但有非常重要的一點需要確認,就是如果資料庫中的資料修改了,怎麼去通知redis更新資料。換而言之,也就是如何保證快取資料和資料庫資料的一致性?

其實這個問題上到軟體,下到硬體工程師都會遇到,也都有不同的解決方案。因為我大學的專業是嵌入式系統,所以對於硬體的快取也有所耳聞。如cpu需要保證自身的多級快取記憶體間的資料一致性,以及快取和記憶體間的資料一致性等。而我們軟體因為查詢資料的**不同,所以對應的每級快取也不同。

多級快取或者多級儲存這個概念可能不是很好理解,大致意思是說我們需要的資料,我們第一時間去**找,那麼這個地方就叫做一級快取。如果一級快取沒找到,再去找的地方就被稱作二級快取,以此類推。那為什麼叫做快取?大致是為了突出乙個臨時儲存以及訪問速度快的特點吧,大約就是資料暫緩儲存區以及查詢緩衝區的乙個意思。

說回到我們的專案,我們將常訪問的資料從資料庫中複製到redis中乙份,每次訪問先從redis中讀取,讀不到再從資料庫中讀取。所以可以認為我們當前的一級快取是redis,二級快取是資料庫。當資料量沒有到非常龐大的時候,只要保證了快取一致性,用這套方案也不會有什麼問題。但如果從redis訪問的資料頻率過高,超過了redis所在伺服器的頻寬呢?

第乙個問題就是我最開始說的,資料一致性問題。第二個是剛提到的redis頻寬成為瓶頸的問題。如果將我遇到的這兩個問題更通用性地梳理一遍,那就是各級快取間的資料一致性保證方法和快取遇到瓶頸時如何去提公升。

我能想到的有兩種解決方案,第一種是定時重新整理,第二種是修改通知。如果對於允許有讀取到舊資料的場景,那麼定時重新整理肯定是比較好的方案,因為實現起來簡單。但是如果不希望讀到舊資料,那麼就需要在資料被修改的時候通知到上一級快取,讓上一級快取把舊資料刪了。當下一次需要用到資料的時候,上一級快取就會來重新獲取資料並儲存了。但是這種情況也有問題,如果不提前存到快取中會導致第一次訪問時過慢。如果提前存入快取會導致當上一級快取被清空時,大量請求資料會同時到達下一級快取那裡,造成擁塞。但這些也都是有對應的解決方案的。

還記得我們為什麼要引入快取麼?因為資料庫遇到了瓶頸。那引入的redis快取遇到瓶頸了怎麼辦呢?同樣的解決方案,引入更快速的快取。但別忘了,一定要***資料一致性的方案。redis這一級別的快取,可以認為是放在記憶體中的,難道我們要引入比記憶體更高效的cpu的快取記憶體麼?我們軟體也不具備這個權利啊。有一點我剛才有提到,redis瓶頸是因為頻寬的原因,因為redis是乙個用網線連線的「記憶體」。所以,我們可以使用的更高效的快取就是本地記憶體。於是,後期的優化方案可以改為一級快取為記憶體,二級快取為redis,**快取為資料庫。

如果是以前,我一定會按照我的想法全部自己寫一套快取框架。但是後來發現我在大學時期自己想出來的一些好的框架,都有對應的更好用的開源框架(對於這個之後我可以專門寫一篇部落格)。之後到底是我們團隊自己寫,還是用現有的開源的框架,已經不重要了。重要的是我在這次遇到的這個問題中收穫了自己的思考。

當資料庫發生災難時

當資料庫發生災難時 sql server 資料庫當發生災難時,需要立即檢查資料庫還留下什麼檔案,並且根據留下的檔案制定出恢復計畫 留下的檔案 無日誌檔案 日誌檔案受損 日誌檔案完整 無資料檔案 1 使用以前的資料備份恢復到最後乙個備份時 2 同 1 3 首先進行尾日誌備份 並結合以前的備份,可將資料...

資料庫的瓶頸

簡單的是說,所謂資料庫瓶頸 是指整個系統的執行效能不佳,而原因是由於對資料庫的訪問部分,因此說資料庫成為為整個應用的瓶頸。通常造成資料庫瓶頸的原因是 1 資料庫系統本身性不佳,例如你用桌面資料庫access 來做web應用的後台資料庫 顯然是不行的 2 資料庫結構設計不合理,導致不必要的 過多的資料...

資料庫訪問優化法則

從圖上可以看到基本上每種裝置都有兩個指標 延時 響應時間 表示硬體的突發處理能力 頻寬 吞吐量 代表硬體持續處理能力。從上圖可以看出,計算機系統硬體效能從高到代依次為 cpu cache l1 l2 l3 記憶體 ssd硬碟 網路 硬碟 根據資料庫知識,我們可以列出每種硬體主要的工作內容 cpu及記...