本文將為大家介紹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、密碼即可。
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數據進行查詢。如果就這樣簡單的設計的話，對於京東這樣的大流量平臺，每天有非常多的人進行商品搜索，而且每個人搜索的條件還不一樣，根本無法快速響應。
如上圖所示，我們可以這樣設計：
我們事先建立好一系列的SET，實際上這些Set都是各種分類的ProductID集合
用戶的搜索條件，實際上就是各種SET進行交、並、補的運算而已
要知道SET進行運算後的結果，就是ProductID集合，此時範圍已經有所縮小，比起直接遍歷全部商品數據要小不少
上這裡也可以看出，Redis雖然用起來簡單，但是要綜合運用，並根據業務場景進行設計，還是挺有意思的。
鏈接：https://www.jianshu.com/p/af7043e6c8f9
來源：簡書
想了解大型企業的數據庫運維之道？來看看 GOPS 全球運維大會 2018 · 上海站
網易數據庫運維專家將在 GOPS 2018 · 上海站為大家帶來數據庫運維自動化與AIOps探索的精彩議題，還不快來看看？
閱讀更多 高效運維 的文章
