Redis實戰（七）Redis開發與運維

 Redis用途

1.緩存

  Redis提供了鍵值過時時間設置， 而且也提供了靈活控制最大內存和內存溢出後的淘汰策略。 能夠這麼說， 一個合理的緩存設計可以爲一個網站的穩定保駕護航。

2.排行榜系統

 Redis提供了列表和有序集合數據結構， 合理地使用這些數據結構能夠很方便地構建各類排行榜系統。

3.計數器應用

Redis適用於高併發的遞增、遞減功能

遞增指令：incr（默認從0開始）

遞減指令：decr（默認從0開始，遞減會出現負數，這點跟memcache不同,mc到0）

4.社交網絡

贊/踩、 粉絲、 共同好友/喜愛、推送、下拉刷新等是社交網站的必備功能，因爲社交網站訪問量一般比較大，並且傳統的關係型數據不太適合保存這種類型的數據，

Redis提供的數據結構能夠相對比較容易地實現這些功能。

5.消息隊列系統

Redis提供了發佈訂閱功能和阻塞隊列的功能，雖然和專業的消息隊列比還不夠足夠強大， 可是對於通常的消息隊列功能基本能夠知足。

6.共享Session

7.限速

可是爲了短信接口不被頻繁訪問， 會限制用戶每分鐘獲取驗證碼的頻率， 例如一分鐘不能超過5次。

一些網站限制一個IP地址不能在一秒鐘以內訪問超過n次也能夠採用相似的思路。

 API的理解和使用

Redis發展歷程中提供了move、 dump+restore、 migrate三組遷移鍵的方法。

Redis默認配置中是有16個數據庫，推薦使用0號數據庫？

假設databases=16， select0操做將切換到第一個數據庫， select15選擇最後一個數據庫， 可是0號數據庫和15號數據庫之間的數據沒有任何關聯， 甚至能夠存在相同的鍵。

Redis3.0中已經逐漸弱化這個功能， 例如Redis的分佈式實現Redis Cluster只容許使用0號數據庫， 只不過爲了向下兼容老版本的數據庫功能，該功能沒有徹底廢棄掉。

Redis是單線程的。 若是使用多個數據庫， 那麼這些數據庫仍然是使用一個CPU， 彼此之間仍是會受到影響的。

多數據庫的使用方式， 會讓調試和運維不一樣業務的數據庫變的困難，假若有一個慢查詢存在， 依然會影響其餘數據庫， 這樣會使得別的業務方定位問題很是的困難。

部分Redis的客戶端根本就不支持這種方式。 即便支持， 在開發的時候來回切換數字形式的數據庫， 很容易弄亂。

筆者建議若是要使用多個數據庫功能， 徹底能夠在一臺機器上部署多個Redis實例， 彼此用端口來作區分， 由於現代計算機或者服務器一般是有多個CPU的。

這樣既保證了業務之間不會受到影響，又合理地使用了CPU資源。

scan命令能夠解決keys命令可能帶來的阻塞問題， 同時Redis還提供了hscan、 sscan、 zscan漸進式地遍歷hash、 set、 zset。

小功能大用處

 

 

Redis提供了簡單的事務， 之因此說它簡單， 主要是由於它不支持事務中的回滾特性。

 

客戶端

 

 持久化

Redis提供了兩種持久化方式： RDB和AOF。

RDB持久化是把當前進程數據生成快照保存到硬盤的過程， 觸發RDB持久化過程分爲手動觸發和自動觸發。

手動觸發分別對應save和bgsave命令：save命令： 阻塞當前Redis服務器， 直到RDB過程完成爲止， 對於內存比較大的實例會形成長時間阻塞， 線上環境不建議使用。

bgsave命令： Redis進程執行fork操做建立子進程， RDB持久化過程由子進程負責， 完成後自動結束。 阻塞只發生在fork階段， 通常時間很短。

顯然bgsave命令是針對save阻塞問題作的優化。 所以Redis內部全部的涉及RDB的操做都採用bgsave的方式， 而save命令已經廢棄。

針對RDB不適合實時持久化的問題， Redis提供了AOF持久化方式來解決。

AOF（ append only file） 持久化： 以獨立日誌的方式記錄每次寫命令，重啓時再從新執行AOF文件中的命令達到恢復數據的目的。

AOF的主要做用是解決了數據持久化的實時性， 目前已是Redis持久化的主流方式。

開啓AOF功能須要設置配置： appendonly yes， 默認不開啓。

Redis單線程架構致使沒法充分利用CPU多核特性， 一般的作法是在一臺機器上部署多個Redis實例。

複製

拓撲

 

Redis的噩夢： 阻塞

 

內存

 

哨兵

 

集羣

 Redis Cluster是Redis的分佈式解決方案， 在3.0版本正式推出， 有效地解決了Redis分佈式方面的需求。 當遇到單機內存、 併發、 流量等瓶頸時， 能夠採用Cluster架構方案達到負載均衡的目的。

 

1.節點取餘分區

2.一致性哈希分區

3.虛擬槽分區

 

 

緩存設計

 

緩存穿透

緩存穿透是指查詢一個根本不存在的數據， 緩存層和存儲層都不會命中。（攻擊者利用大量不存在的驗證ID進行請求，致使了緩存穿透，引發後端數據庫壓力驟增而崩潰。）

有效地解決緩存穿透

    有不少種方法能夠有效地解決緩存穿透問題，最多見的則是採用布隆過濾器，將全部可能存在的數據哈希到一個足夠大的bitmap中，

  一個必定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。另外也有一個更爲簡單粗暴的方法（咱們採用的就是這種），

  若是一個查詢返回的數據爲空（不論是數 據不存在，仍是系統故障），咱們仍然把這個空結果進行緩存，但它的過時時間會很短，最長不超過五分鐘。

雪崩優化

Redis監控運維雲平臺CacheCloud

 

其餘

批量操做命令能夠有效提升開發效率

批量設置值

mset key value [key value ...]

批量獲取值

mget key [key ...]

redis怎樣更新值而不重置過時時間

TimeSpan spanTimeoutLeft = redisExpertCodesCacher.KeyTimeToLive(loginHelper.UserName);//得到key目前的剩餘過時時間
  bool b = redisExpertCodesCacher.SetAddExpertCode(loginHelper.UserName, q, spanTimeoutLeft);//使用Set存儲 是否須要判斷學者代碼是否存在？若是不存在則添加