1.Redis

豐富的資料結構（Data Structures）

字串（String）

Redis字串能包含任意型別的資料;；

一個字串型別的值最多能儲存512M位元組的內容；

利用INCR命令簇（INCR,DECR,INCRBY）來把字串當作原子計數器使用；

使用APPEND命令在字串後新增內容。

列表（List）

Redis列表是簡單的字串列表，按照插入順序排序；

你可以新增一個元素到列表的頭部（左邊：LPUSH）或者尾部（右邊：RPUSH）；

一個列表最多可以包含232-1個元素（4294967295，每個表超過40億個元素）；

在社交網路中建立一個時間線模型，使用LPUSH

你可以同時使用LPUSH和LTRIM去建立一個永遠不會超過指定元素數目的列表並同時記住最後的N個元素；

列表可以用來當作訊息傳遞的基元（primitive），例如，眾所周知的用來建立後臺任務的Resque Ruby庫。

集合（Set）

Redis集合是一個無序的，不允許相同成員存在的字串合集（Uniq操作，獲取某段時間所有資料排重值）；

支援一些服務端的命令從現有的集合出發去進行集合運算，如合併（並集：union）,求交(交集：intersection)，差集,找出不同元素的操作（共同好友、二度好友）；

用集合跟蹤一個獨特的事。想要知道所有訪問某個部落格文章的獨立IP？只要每次都用SADD來處理一個頁面訪問。那麼你可以肯定重複的IP是不會插入的（ 利用唯一性，可以統計訪問網站的所有獨立IP）；

Redis集合能很好的表示關係。你可以建立一個tagging系統，然後用集合來代表單個tag。接下來你可以用SADD命令把所有擁有tag的物件的所有ID新增進集合，這樣來表示這個特定的tag。如果你想要同時有3個不同tag的所有物件的所有ID，那麼你需要使用SINTER。

使用SPOP或者SRANDMEMBER命令隨機地獲取元素。

雜湊（Hashes）

Redis Hashes是字串欄位和字串值之間的對映；

儘管Hashes主要用來表示物件，但它們也能夠儲存許多元素。

有序集合（Sorted Sets）

Redis有序集合和Redis集合類似，是不包含相同字串的合集；

每個有序集合的成員都關聯著一個評分，這個評分用於把有序集合中的成員按最低分到最高分排列（排行榜應用，取TOP N操作）；

使用有序集合，你可以非常快地（O(log(N))）完成新增，刪除和更新元素的操作；

元素是在插入時就排好序的，所以很快地通過評分(score)或者位次(position)獲得一個範圍的元素（需要精準設定過期時間的應用）；

輕易地訪問任何你需要的東西: 有序的元素，快速的存在性測試，快速訪問集合中間元素；

在一個巨型線上遊戲中建立一個排行榜，每當有新的記錄產生時，使用ZADD 來更新它。你可以用ZRANGE輕鬆地獲取排名靠前的使用者， 你也可以提供一個使用者名稱，然後用ZRANK獲取他在排行榜中的名次。 同時使用ZRANK和ZRANGE你可以獲得與指定使用者有相同分數的使用者名稱單。 所有這些操作都非常迅速；

有序集合通常用來索引儲存在Redis中的資料。 例如：如果你有很多的hash來表示使用者，那麼你可以使用一個有序集合，這個集合的年齡欄位用來當作評分，使用者ID當作值。用ZRANGEBYSCORE可以簡單快速地檢索到給定年齡段的所有使用者。

複製（Replication,Redis複製很簡單易用，它通過配置允許slave Redis Servers或者Master Servers的複製品） 一個Master可以有多個Slaves能通過介面其他slave的連結，除了可以接受同一個master下面slaves的連結以外，還可以接受同一個結構圖中的其他slaves的連結redis複製是在master段是非阻塞的，這就意味著master在同一個或多個slave端執行同步的時候還可以接受查詢複製在slave端也是非阻塞的，假設你在redis.conf中配置redis這個功能，當slave在執行的新的同步時，它仍可以用舊的資料資訊來提供查詢，否則，你可以配置當redis slaves去master失去聯絡是，slave會給傳送一個客戶端錯誤為了有多個slaves可以做只讀查詢，複製可以重複2次，甚至多次，具有可擴充套件性（例如：slaves對話與重複的排序操作，有多份資料冗餘就相對簡單了）他可以利用複製去避免在master端儲存資料，只要對master端redis.conf進行配置，就可以避免儲存（所有的儲存操作），然後通過slave的連結，來實時的儲存在slave端LRU過期處理（Eviction） EVAL 和 EVALSHA 命令是從 Redis 2.6.0 版本開始的，使用內建的 Lua 直譯器，可以對 Lua 指令碼進行求值Redis 使用單個 Lua 直譯器去執行所有指令碼，並且， Redis 也保證指令碼會以原子性(atomic)的方式執行： 當某個指令碼正在執行的時候，不會有其他指令碼或 Redis 命令被執行。 這和使用 MULTI / EXEC 包圍的事務很類似。 在其他別的客戶端看來，指令碼的效果(effect)要麼是不可見的(not visible)，要麼就是已完成的(already completed)LRU過期處理（Eviction）。

Redis允許為每一個key設定不同的過期時間，當它們到期時將自動從伺服器上刪除（EXPIRE）。

事務MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事務的基礎事務是一個單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端傳送來的命令請求所打斷事務中的命令要麼全部被執行，要麼全部都不執行，EXEC 命令負責觸發並執行事務中的所有命令 Redis 的 Transactions 提供的並不是嚴格的 ACID 的事務Transactions 還是提供了基本的命令打包執行的功能： 可以保證一連串的命令是順序在一起執行的，中間有會有其它客戶端命令插進來執行Redis 還提供了一個 Watch 功能，你可以對一個 key 進行 Watch，然後再執行 Transactions，在這過程中，如果這個 Watched 的值進行了修改，那麼這個 Transactions 會發現並拒絕執行資料持久化 RDB。

特點：

RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照儲存。

優點：

RDB是一個非常緊湊的檔案,它儲存了某個時間點得資料集,非常適用於資料集的備份；

RDB是一個緊湊的單一檔案,非常適用於災難恢復；

RDB在儲存RDB檔案時父程序唯一需要做的就是fork出一個子程序,接下來的工作全部由子程序來做，父程序不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的效能；

與AOF相比,在恢復大的資料集的時候，RDB方式會更快一些。

缺點：

如果你希望在redis意外停止工作（例如電源中斷）的情況下丟失的資料最少的話，那麼RDB不適合，Redis要完整的儲存整個資料集是一個比較繁重的工作。

RDB 需要經常fork子程序來儲存資料集到硬碟上,當資料集比較大的時候,fork的過程是非常耗時的,可能會導致Redis在一些毫秒級內不能響應客戶端的請求.如果資料集巨大並且CPU效能不是很好的情況下,這種情況會持續1秒,AOF也需要fork,但是你可以調節重寫日誌檔案的頻率來提高資料集的耐久度。

AOF

特點

AOF持久化方式記錄每次對伺服器寫的操作；

redis重啟的時候會優先載入AOF檔案來恢復原始的資料,因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整。

優點

使用AOF 會讓你的Redis更加耐久: 你可以使用不同的fsync策略：無fsync,每秒fsync,每次寫的時候fsync；

AOF檔案是一個只進行追加的日誌檔案,所以不需要寫入seek；

Redis 可以在 AOF 檔案體積變得過大時，自動地在後臺對AOF 進行重寫；

AOF 檔案有序地儲存了對資料庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式儲存， 因此 AOF 檔案的內容非常容易被人讀懂， 對檔案進行分析（parse）也很輕鬆。 匯出（export） AOF 檔案也非常簡單；

缺點

對於相同的資料集來說，AOF 檔案的體積通常要大於 RDB 檔案的體積；

根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB。

選擇

同時使用兩種持久化功能。

分散式 Redis Cluster （Redis 3版本）Keepalived

當Master掛了後，VIP漂移到Slave；Slave 上keepalived 通知redis 執行：slaveof no one,開始提供業務；

當Master起來後，VIP 地址不變，Master的keepalived 通知redis 執行slaveof slave IP host ，開始作為從同步資料；

依次類推。

Twemproxy

快、輕量級、減少後端Cache Server連線數、易配置、支援ketama、modula、random、常用hash 分片演算法；

對於客戶端而言，redis叢集是透明的，客戶端簡單，遍於動態擴容；

Proxy為單點、處理一致性hash時，叢集節點可用性檢測不存在腦裂問題；

高效能，CPU密集型，而redis節點叢集多CPU資源冗餘，可部署在redis節點叢集上，不需要額外裝置。

高可用（HA） Redis Sentinel（redis自帶的叢集管理工具 ）

監控（Monitoring）： Redis Sentinel實時監控主伺服器和從伺服器執行狀態；

提醒（Notification）：當被監控的某個 Redis 伺服器出現問題時， Redis Sentinel 可以向系統管理員傳送通知， 也可以通過API 向其他程式傳送通知；

自動故障轉移（Automatic failover）： 當一個主伺服器不能正常工作時，Redis Sentinel 可以將一個從伺服器升級為主伺服器， 並對其他從伺服器進行配置，讓它們使用新的主伺服器。當應用程式連線到 Redis 伺服器時， Redis Sentinel會告之新的主伺服器地址和埠。

單M-S結構

單M-S結構特點是在Master伺服器中配置Master Redis（Redis-1M）和Master Sentinel（Sentinel-1M）；

Slave伺服器中配置Slave Redis（Redis-1S）和Slave Sentinel（Sentinel-1S）；

其中 Master Redis可以提供讀寫服務，但是Slave Redis只能提供只讀服務。因此，在業務壓力比較大的情況下，可以選擇將只讀業務放在Slave Redis中進行。

雙M-S結構

雙M-S結構的特點是在每臺伺服器上配置一個Master Redis，同時部署一個Slave Redis。由兩個Redis Sentinel同時對4個Redis進行監控。兩個Master Redis可以同時對應用程式提供讀寫服務，即便其中一個伺服器出現故障，另一個伺服器也可以同時執行兩個Master Redis提供讀寫服務；

缺點是兩個Master redis之間無法實現資料共享，不適合存在大量使用者資料關聯的應用使用。

單M-S結構和雙M-S結構比較

單M-S結構適用於不同使用者資料存在關聯，但應用可以實現讀寫分離的業務模式。Master主要提供寫操作，Slave主要提供讀操作，充分利用硬體資源；

雙（多）M-S結構適用於使用者間不存在或者存在較少的資料關聯的業務模式，讀寫效率是單M-S的兩（多）倍，但要求故障時單臺伺服器能夠承擔兩個Mater Redis的資源需求；

釋出/訂閱（Pub/Sub）監控：Redis-Monitor 歷史redis執行查詢：CPU、記憶體、命中率、請求量、主從切換等實時監控曲線。

2.資料型別Redis使用場景

String

計數器應用

List

取最新N個數據的操作；

訊息佇列；

刪除與過濾；

實時分析正在發生的情況，用於資料統計與防止垃圾郵件（結合Set）；

Set Uniqe操作，獲取某段時間所有資料排重值實時系統，反垃圾系統共同好友、二度好友利用唯一性，可以統計訪問網站的所有獨立 IP好友推薦的時候，根據 tag 求交集，大於某個 threshold 就可以推薦Hashes。

儲存、讀取、修改使用者屬性；

Sorted Set 排行榜應用，取TOP N操作需要精準設定過期時間的應用（時間戳作為Score）帶有權重的元素，比如一個遊戲的使用者得分排行榜過期專案處理，按照時間排序。

3.Redis解決秒殺/搶紅包等高併發事務活動

秒殺開始前30分鐘把秒殺庫存從資料庫同步到Redis Sorted Set；

使用者秒殺庫存放入秒殺限制數長度的Sorted Set；

秒殺到指定秒殺數後，Sorted Set不在接受秒殺請求，並顯示返回標識；

秒殺活動完全結束後，同步Redis資料到資料庫，秒殺正式結束。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支援我們。