Redis高級特性介紹及實例分析

本文將爲你們介紹Redis的一些高級特性以及結合一個具體的實際案例來對Redis進行設計分析。

Redis基礎類型回顧

String

Redis中最基本，也是最簡單的數據類型。注意，VALUE既能夠是簡單的String,也能夠是複雜的String，如JSON，在實際中經常利用fastjson將對象序列化後存儲到Redis中。另外注意mget批量獲取能夠提升效率。

Hash

Hash結構適用於存儲對象，相較於String，存儲佔用更少的內存。Hash結構可使你像在數據庫中Update一個屬性同樣只修改某一項屬性值，並且還能夠快速定位數據。好比，若是咱們把表User中的數據能夠這樣放置到Redis中：Hash存儲，KEY：User，Field:USERID，VALUE：user序列化後的string。

List

既能夠當作棧、又能夠當作隊列。實際上，能夠利用List的先進先出或者先進後出的特性維護一段列表，好比排行榜、實時列表等，甚至還能夠簡單的當作消息隊列來使用。

Set

Set是String類型的不重複無序集合。Set的特色在於，它提供了集合的一些運算，好比交集、並集、差集等。這些運算特性，很是方便的解決實際場景中的一些問題，如共同關注、共同粉絲等。

ZSet

ZSet就是SortedSet。實際中，不少排序場景均可以考慮ZSet來作。

Redis發展過程當中的三種模式：主從、哨兵、集羣

Redis的發展能夠從版本的變化看出來，從1.X的主從模式，到2.X的哨兵模式，再到今天3.X的集羣模式，能夠說這些都是Redis保證數據可靠性、高可用的思路。下面咱們來簡單實踐下。環境說明：這裏準備了4臺Centos Linux,裝有redis的3.0版本。

主從模式

Redis早期用於保證數據可靠性的一種簡單方式。具體來講，Master可用於寫、讀，而Slave通常只用於讀。

其實在配置上至關簡單，只須要在Slave節點配置下Master的IP、PORT、密碼便可。

192.168.99.122/123 redis.conf:

Master info

Slave info

注意：

一個Master能夠擁有多個Slave

主從複製不會阻塞住Master，在同步數據時Master能夠繼續處理client端請求

哨兵模式

對於主從複製模式而言，有個明顯的缺點：一旦主節點掛了，那麼redis服務將不可用。在2.X中，爲了確保可高用，因此發展出來哨兵模式。顧名思義，就是哨兵站崗，去監聽master心跳，若是master掛了，那麼將從slave中選舉出一個master來，從而實現了故障自動切換。

實質上，在Master-Slave模式基礎上，只須要在啓動一個哨兵服務進行監聽就能夠，這個哨兵服務能夠部署在Master/Slave上，也能夠部署到其餘機器上。固然，在實際中爲了不哨兵節點的單點性，也會配置多個哨兵服務。

哨兵節點192.168.99.124  sentinel.conf:

sentinel monitor mymaster 192.168.99.121 6379 1
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 2

咱們須要告訴哨兵服務：

監控的主節點的IP,PORT

若是master掛了，那麼選舉的時候，slave達到多少票就能夠成爲主節點

監控主節點的心跳頻率

主節點下有多少slave

集羣模式

Redis集羣模式是目前應用很是普遍的，Redis集羣模式的出現，也使得之前的一些Redis技術，好比分片、都不在適用了，同時數據的高可靠、數據分佈性、服務的高可用性進一步增強。關於Redis集羣將在下一篇博客中詳細介紹。

Redis的簡單事務

目前來看，Redis對事務的支持是比較簡單的，在實際應用中，咱們基本上是不會使用的。看一個實例，你就會明白。經過multi開啓事務，經過exec來提交事務。能夠看到，redis的事務目前是不支持一塊兒成功，一塊兒失敗這種基本要求的，即使在事務中有錯誤，亦不會回退，和MySQL的事務功能相距甚遠吧。

Redis持久化機制

Redis是一個支持持久化的內存數據庫，也就是說Redis須要常常將內存中的數據同步到硬盤來保證持久化，有2種方式實現。

RDB

RDB方式，也稱做快照snapshotting，將內存中的數據以快照的方式寫入到二進制文件dump.rdb中，這種方式也是redis的默認方式。能夠在redis.conf中設置保存的策略。一句話：redis在N秒內若是超過M個KEY發生修改則自動作快照保存。

AOF

AOF，即Append-Only File。要知道RDB的方式，是在必定的時間間隔作一次，若是redis意外down掉，這將意味着會丟失最後一次快照後的全部修改數據，這在生產環境將不太可能接受。AOF比RDB有着更好的持久化方式，經過AOF，redis會將每個收到的寫命令都經過write函數追加到命令中，當redis從新啓動時，會從新執行文件中保存的寫命令來重建數據內容。

redis.conf:

在實際應用中，爲了確保數據高可靠性，應該使用always策略。

發佈與訂閱消息

概念上比較簡單，若是你訂閱了頻道，那麼這個頻道上發佈的消息，你都會知道。實際中應用較多的是消息中間件（ActiveMQ,RocketMQ）的訂閱發佈模式（在之後的消息中間件專題再爲你們介紹）。

Redis案例設計分析

咱們先來看一個京東上進行商品搜索的圖：

假設一個相似的場景，有幾百萬，甚至幾千萬的商品數據，考慮下如何快速實現搜索查詢呢？固然，咱們不可能直接查詢MySQL，應該須要在MySQL上加一層，能夠考慮加一層Redis。

將MySQL中的數據加載至Redis中，給定條件，直接遍歷Hash數據進行查詢。若是就這樣簡單的設計的話，對於京東這樣的大流量平臺，天天有很是多的人進行商品搜索，並且每一個人搜索的條件還不同，根本沒法快速響應。

如上圖所示，咱們能夠這樣設計：

1. 咱們事先創建好一系列的SET，實際上這些Set都是各類分類的ProductID集合

2. 用戶的搜索條件，實際上就是各類SET進行交、並、補的運算而已

3. 要知道SET進行運算後的結果，就是ProductID集合，此時範圍已經有所縮小，比起直接遍歷所有商品數據要小很多

上這裏也能夠看出，Redis雖然用起來簡單，可是要綜合運用，並根據業務場景進行設計，仍是挺有意思的。到這裏就結束了，咱們下期Redis集羣再見！