【進階】深刻redis，而後正確使用它

redis緩存類型

1. 緩存覆蓋

當你的mysql數據庫掛掉了或者你手動關閉了connect，你的網站絕大多數網頁頁面仍然能刷出來。

2. 激活緩存

查詢的時候,發現緩存沒有了(失效了),那麼此次就從mysql中查詢,再寫入redis緩存.下次來的時候,就走緩存,不走數據庫。

3. 熱點緩存

哈希值目前存在,但有效期只剩下1分鐘了(生命週期共10分鐘),此時,又有一次訪問時,再把時間刷新一下,又變成10分鐘。

相關常識

1.redis可能存在失敗的地方就是redis服務器掛了或物理滿了、調用虛擬內存的時候.

2.redis通常都會作相應的管理,如清空緩存、重建全部緩存、清除某一個模塊的緩存.

3.redis作緩存就是爲了避免走數據庫,提升響應速度.是兩個獨立的系統,關了redis,網站同樣能跑,關了mysql,網站同樣正常訪問.

4.list佔用內存比較少,能夠不用設置過時時間.但hash佔用內存大,必須設置過時時間.

緩存邏輯

生命週期

Redis中可使用expire命令設置一個鍵的生存時間，到時間後redis會自動刪除它。

expire 設置生存時間（單位/秒）

expire key seconds(秒)

persist 取消生存時間

persist key

應用場景

限時的優惠活動信息
網站數據緩存（對於一些須要定時更新的數據，例如：積分排行榜）
手機驗證碼
限制網站訪客訪問頻率（例如：1分鐘最多訪問10次）

事務（transaction）

原理

先將屬於一個事務的命令發送給redis進行緩存，最後再讓redis依次執行這些命令。

命令

DISCARD

取消事務，放棄執行事務塊內的全部命令。

EXEC

執行全部事務塊內的命令。

MULTI

標記一個事務塊的開始。

UNWATCH

取消 WATCH 命令對全部 key 的監視。

WATCH key [key ...]

監視一個(或多個) key ，若是在事務執行以前這個(或這些) key 被其餘命令所改動，那麼事務將被打斷。

實踐

使用事務時可能會趕上如下兩種錯誤

1.事務在執行EXEC 以前，入隊的命令可能會出錯。好比說，命令可能會產生語法錯誤（參數數量錯誤，參數名錯誤，等等），或者其餘更嚴重的錯誤，好比內存不足

（若是服務器使用 maxmemory 設置了最大內存限制的話）。

2.命令可能在EXEC 調用以後失敗。舉個例子，事務中的命令可能處理了錯誤類型的鍵，好比將列表命令用在了字符串鍵上面，諸如此類。

第一種錯誤的狀況

服務器端
在 Redis 2.6.5 之前，Redis 只執行事務中那些入隊成功的命令，而忽略那些入隊失敗的命令。

不過，從 Redis 2.6.5 開始，服務器會對命令入隊失敗的狀況進行記錄，並在客戶端調用EXEC 命令時，拒絕執行並自動放棄這個事務。

客戶端

客戶端之前的作法是檢查命令入隊所得的返回值：若是命令入隊時返回 QUEUED ，那麼入隊成功；不然，就是入隊失敗。若是有命令在入隊時失敗，
那麼大部分客戶端都會中止並取消這個事務。

第二種錯誤的狀況

至於那些在EXEC 命令執行以後所產生的錯誤，並無對它們進行特別處理：即便事務中有某個/某些命令在執行時產生了錯誤，事務中的其餘命令仍然會繼續執行。

這種作法可能會讓你以爲有點奇怪，如下是這種作法的優勢:
1.Redis 命令只會由於錯誤的語法而失敗（而且這些問題不能在入隊時發現），或是命令用在了錯誤類型的鍵上面：這也就是說，從實用性的角度來講，

失敗的命令是由編程錯誤形成的，而這些錯誤應該在開發的過程當中被發現，而不該該出如今生產環境中。

2.由於不須要對回滾進行支持，因此 Redis 的內部能夠保持簡單且快速。
鑑於沒有任何機制能避免程序員本身形成的錯誤，而且這類錯誤一般不會在生產環境中出現，因此 Redis 選擇了更簡單、更快速的無回滾方式來處理事務。

3.DISCARD 命令時，事務會被放棄，事務隊列會被清空，而且客戶端會從事務狀態中退出。

4.WATCH 命令能夠爲 Redis 事務提供 check-and-set （CAS）行爲
被WATCH 的鍵會被監視，並會發覺這些鍵是否被改動過了。若是有至少一個被監視的鍵在EXEC 執行以前被修改了，那麼整個事務都會被取消。

若是在WATCH 執行以後，EXEC 執行以前，有其餘客戶端修改了 mykey 的值，那麼當前客戶端的事務就會失敗。程序須要作的，就是不斷重試這個操做，直到沒有發生碰撞爲止。這種形式的鎖被稱做樂觀鎖，它是一種很是強大的鎖機制。而且由於大多數狀況下，不一樣的客戶端會訪問不一樣的鍵，碰撞的狀況通常都不多，因此一般並不須要進行重試。