本文將為大家介紹Redis的一些高級特性以及結合一個具體的實際案例來對Redis進行設計分析群发。
Redis基礎類型回顧
String
Redis中最基本蒙袍，也是最簡單的數(shù)據(jù)類型镊靴。注意豁翎，VALUE既可以是簡單的String,也可以是復雜的String吱窝，如JSON锁蠕，在實際中常常利用fastjson將對象序列化后存儲到Redis中惑艇。另外注意mget批量獲取可以提高效率蒿辙。
Hash
Hash結構適用于存儲對象，相較于String滨巴，存儲占用更少的內存思灌。Hash結構可以使你像在數(shù)據(jù)庫中Update一個屬性一樣只修改某一項屬性值，而且還可以快速定位數(shù)據(jù)恭取。比如习瑰，如果我們把表User中的數(shù)據(jù)可以這樣放置到Redis中：Hash存儲，KEY：User秽荤，F(xiàn)ield:USERID甜奄，VALUE：user序列化后的string。
List
既可以當做棧窃款、又可以當做隊列课兄。實際上，可以利用List的先進先出或者先進后出的特性維護一段列表晨继，比如排行榜烟阐、實時列表等，甚至還可以簡單的當做消息隊列來使用。
Set
Set是String類型的不重復無序集合蜒茄。Set的特點在于唉擂，它提供了集合的一些運算，比如交集檀葛、并集玩祟、差集等。這些運算特性屿聋，非常方便的解決實際場景中的一些問題空扎，如共同關注、共同粉絲等润讥。
ZSet
ZSet就是SortedSet转锈。實際中，很多排序場景都可以考慮ZSet來做楚殿。
Redis發(fā)展過程中的三種模式：主從撮慨、哨兵、集群
Redis的發(fā)展可以從版本的變化看出來脆粥，從1.X的主從模式砌溺，到2.X的哨兵模式，再到今天3.X的集群模式冠绢，可以說這些都是Redis保證數(shù)據(jù)可靠性、高可用的思路常潮。下面我們來簡單實踐下弟胀。環(huán)境說明：這里準備了4臺Centos Linux,裝有redis的3.0版本。
主從模式
Redis早期用于保證數(shù)據(jù)可靠性的一種簡單方式喊式。具體來說孵户，Master可用于寫、讀岔留，而Slave一般只用于讀夏哭。
其實在配置上相當簡單，只需要在Slave節(jié)點配置下Master的IP献联、PORT竖配、密碼即可。
Master info
Slave info
一個Master可以擁有多個Slave
主從復制不會阻塞住Master里逆，在同步數(shù)據(jù)時Master可以繼續(xù)處理client端請求
哨兵模式
對于主從復制模式而言进胯，有個明顯的缺點：一旦主節(jié)點掛了，那么redis服務將不可用原押。在2.X中胁镐，為了確保可高用，所以發(fā)展出來哨兵模式盯漂。顧名思義颇玷，就是哨兵站崗，去監(jiān)聽master心跳就缆，如果master掛了帖渠，那么將從slave中選舉出一個master來，從而實現(xiàn)了故障自動切換违崇。
實質上阿弃，在Master-Slave模式基礎上，只需要在啟動一個哨兵服務進行監(jiān)聽就可以羞延，這個哨兵服務可以部署在Master/Slave上渣淳，也可以部署到其他機器上。當然伴箩，在實際中為了避免哨兵節(jié)點的單點性入愧，也會配置多個哨兵服務。
哨兵節(jié)點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
我們需要告訴哨兵服務：
監(jiān)控的主節(jié)點的IP,PORT
如果master掛了嗤谚，那么選舉的時候棺蛛，slave達到多少票就可以成為主節(jié)點
監(jiān)控主節(jié)點的心跳頻率
主節(jié)點下有多少slave
集群模式
Redis集群模式是目前應用非常廣泛的，Redis集群模式的出現(xiàn)巩步，也使得以前的一些Redis技術旁赊，比如分片、都不在適用了椅野，同時數(shù)據(jù)的高可靠终畅、數(shù)據(jù)分布性、服務的高可用性進一步加強竟闪。關于Redis集群將在下一篇博客中詳細介紹离福。
Redis的簡單事務
目前來看，Redis對事務的支持是比較簡單的炼蛤，在實際應用中妖爷，我們基本上是不會使用的±砼螅看一個實例絮识，你就會明白。通過multi開啟事務嗽上，通過exec來提交事務笋除。可以看到炸裆，redis的事務目前是不支持一起成功垃它，一起失敗這種基本要求的，即便在事務中有錯誤，亦不會回退国拇，和MySQL的事務功能相距甚遠吧洛史。
Redis持久化機制
Redis是一個支持持久化的內存數(shù)據(jù)庫，也就是說Redis需要經(jīng)常將內存中的數(shù)據(jù)同步到硬盤來保證持久化酱吝，有2種方式實現(xiàn)也殖。
RDB
RDB方式，也稱作快照snapshotting务热，將內存中的數(shù)據(jù)以快照的方式寫入到二進制文件dump.rdb中忆嗜，這種方式也是redis的默認方式∑槠瘢可以在redis.conf中設置保存的策略捆毫。一句話：redis在N秒內如果超過M個KEY發(fā)生修改則自動做快照保存。
AOF
AOF冲甘，即Append-Only File绩卤。要知道RDB的方式，是在一定的時間間隔做一次江醇，如果redis意外down掉濒憋，這將意味著會丟失最后一次快照后的所有修改數(shù)據(jù)，這在生產(chǎn)環(huán)境將不太可能接受陶夜。AOF比RDB有著更好的持久化方式凛驮，通過AOF，redis會將每一個收到的寫命令都通過write函數(shù)追加到命令中条辟，當redis重新啟動時黔夭，會重新執(zhí)行文件中保存的寫命令來重建數(shù)據(jù)內容。
redis.conf:
在實際應用中捂贿，為了確保數(shù)據(jù)高可靠性纠修，應該使用always策略胳嘲。
發(fā)布與訂閱消息
概念上比較簡單厂僧，如果你訂閱了頻道，那么這個頻道上發(fā)布的消息了牛，你都會知道颜屠。實際中應用較多的是消息中間件（ActiveMQ,RocketMQ）的訂閱發(fā)布模式（在以后的消息中間件專題再為大家介紹）。
Redis案例設計分析
我們先來看一個京東上進行商品搜索的圖.
假設一個類似的場景鹰祸，有幾百萬甫窟，甚至幾千萬的商品數(shù)據(jù)广鳍，考慮下如何快速實現(xiàn)搜索查詢呢互例？當然，我們不可能直接查詢MySQL娱两，應該需要在MySQL上加一層，可以考慮加一層Redis浇衬。
將MySQL中的數(shù)據(jù)加載至Redis中懒构，給定條件，直接遍歷Hash數(shù)據(jù)進行查詢耘擂。如果就這樣簡單的設計的話胆剧，對于京東這樣的大流量平臺，每天有非常多的人進行商品搜索醉冤，而且每個人搜索的條件還不一樣秩霍，根本無法快速響應。
如上圖所示蚁阳，我們可以這樣設計：
我們事先建立好一系列的SET铃绒，實際上這些Set都是各種分類的ProductID集合
用戶的搜索條件，實際上就是各種SET進行交韵吨、并匿垄、補的運算而已
要知道SET進行運算后的結果，就是ProductID集合归粉，此時范圍已經(jīng)有所縮小椿疗，比起直接遍歷全部商品數(shù)據(jù)要小不少
上這里也可以看出，Redis雖然用起來簡單糠悼，但是要綜合運用届榄，并根據(jù)業(yè)務場景進行設計，還是挺有意思的倔喂。到這里就結束了铝条，我們下期Redis集群再見！
