redis

正文開始 上一篇文章中咱們已經學習了一些緩存基本的策略,那接下來我們要來理解一下一個重要的主題 : 如果緩存失效的情況,與可能會發生什麼事情呢 ? 基本上緩存失效後的結果,會很慘,尤其是你當初建立緩存時,就是已經為了讀取接近性能臨異值而建立的情況,當緩存一失效,你的資料庫也會瞬間爆掉,然後用戶就不愈悅,你就完了。 圖 1 : 緩存失效圖 而在實務上,緩存失效大至可以分為以下幾類,也就是咱們接下來每個章節 : 緩存失效情況 - 緩存穿透 緩存失效情況 - 緩存雪崩 緩存失效情況 - 緩存服務炸了 緩存失效情況 - 緩存穿透 這個的主要情境如下 : 查詢一個不存在的資料,由於沒命中緩存,因此會一直往 DB 穿,如下圖 2 所示。 圖 2 : 緩存穿透 通常這種情況有可能是前端出了錯,導致一直送不存在的資料,又或是人為刻意,就是要有人想打爆你整個系統。 解法 1 : 硬處理 這種方法就是,當用戶使用 a key 去 redis 找發現沒有 cache,然後再去 db 抓,也發現沒有,然後就將『 這個 a key 是空值 』也寫入到緩存中 ( 可以給它設個到期時間 ),如下程式碼範例。 這樣後面有人在使用這個 key 去打,會在 cache 這被防下來,然後將算後來真的有寫入 a key 時,咱們緩存寫入流程也是會將它處理 ( 詳見前篇文章 )。
正文開始 上一篇咱們基本上已經理解緩存服務 redis 的基本概念後,接下來咱們要進入正題 : 緩存策略 相信不少人應該會覺得這很簡單,不就是將熱資料丟到緩存,然後用戶先優先去緩存取得,沒有則去資料庫拿去嗎 ? 用腦袋想很簡單沒錯,但是難處就在於 : 你要如何確保資料一致性呢 ? 有沒有覺得這名詞很耳熟呢 ? 你只要記好,只要是多個服務,只要是共用資料的,那就一定會碰到它。 什麼樣類型資料適合緩存呢 ? 緩存讀流程 緩存寫策略與難題 緩存寫策略的難題總結 什麼樣類型資料適合緩存呢 ? 在建立緩存時,我們需要先來決定一件重要的事情。 什麼樣的資料需要存放到緩存中呢 ? 基本上適合緩存資料的特點有以下幾點 : 這個資料是常常被使用到的。 這個資料是不常被更新的。 且中如果符合上述兩個情況的那就可以算在『 適合建立緩存的資料 』選項中。 緩存讀流程 讀的基本流程如下 : (1) 用戶往應用服務發送請求。 (2) 應用服務至緩存服務看看是否有緩存。 (3A) 有,則回傳。 (3B) 無,則前往資料庫服務取得資料。 (4) 並將資料回寫入緩存服務。 基本上這種讀的流程比較沒有太大問題與爭論。 圖 1 : 緩存讀取流程 緩存寫策略與難題 緩存策略最大坑在這 比較大的問題在於『 寫 』這裡,因為不同的寫入方式會產生不同的問題,而且這沒有 100% 的完美解,只能有較優但還是有缺點的解。接下來我們來一個一個慢慢看。
正文開始 前面幾篇文章咱們已經學習完了資料層性能相關的知識,而接下來這篇文章,咱們要來學習,如何進一步的讓系統可以做更多的事情。 資料庫單機性能優化到最後,仍然還是逃不過性能的貧頸,但這並不是說單機優化沒有意義,因為單機如果沒有將它優化好,而直接開機器來增加性能,那只能說是拿錢堆起來的性能,而且可能會出問題。 那要如何在增加性能呢 ? 這時通常會使用以下的策略 : 緩存 也就是說架構會變的如上圖 1 所示,在 mysql 前面會多增加一個緩存服務,這個服務我們通常會選擇用 redis。當資料在緩存服務有時直接回傳,沒有則去資料庫服務取得。 圖 1 : 加入緩存服務圖 在開始緩存策略前,咱們要先來研究一下基本的緩存服務『 redis 』。 本篇文章分為以下幾個章節 : Redis 的架構 Redis 的一致性難題處理 Redis 性能使用的要點 Redis 的架構 首先咱們簡單的介紹一下 redis 是啥 ? 簡單的說它算是一種資料庫,redis 是將所有的資料存在『 記憶體 』中,而 mysql 則是將主要資料存在『 硬碟中 』。 它適合當緩存服務的重點就在於儲『 記憶體 』。 而它適合當緩存服務的重點就在於這裡,它將資料儲放在記憶體,因此操作速度非常的快,咱們來簡單複習一下儲硬碟和記憶體取資料的差異,如下圖 2 所示,mysql 讀取資料,基本上要運行 3 次的拷貝,而 redis 則只需要 1 次 ( 每條線就是一次拷貝 )。 圖 2 : redis vs mysql 讀取資料比較