Redis 是完全開源免費的，遵守BSD協議，是一個高效能的key-value資料庫。Redis本質上是一個Key-Value型別的記憶體資料庫，很像memcached，整個資料庫統統載入在記憶體當中進行操作，定期通過非同步操作把資料庫資料flush到硬碟上進行儲存。因為是純記憶體操作，Redis的效能非常出色，每秒可以處理超過 10萬次讀寫操作，是已知效能最快的Key-Value DB。

Redis的出色之處不僅僅是效能，Redis最大的魅力是支援儲存多種資料結構，此外單個value的最大限制是1GB，不像 memcached只能儲存1MB的資料，因此Redis可以用來實現很多有用的功能，比方說用List來做FIFO雙向連結串列，實現一個輕量級的高性 能訊息佇列服務，用他的Set可以做高效能的tag系統

Redis的主要缺點是資料庫容量受到實體記憶體的限制，不能用作海量資料的高效能讀寫，因此Redis適合的場景主要侷限在較小資料量的高效能操作和運算上。

總結來說，使用Redis的好處如下：

• 速度快，因為資料存在記憶體中，類似於HashMap，HashMap的優勢就是查詢和操作的時間複雜度都是O(1)
• 支援豐富資料型別，支援string，list，set，sorted set，hash
• 支援事務，操作都是原子性，所謂的原子性就是對資料的更改要麼全部執行，要麼全部不執行
• 豐富的特性：可用於快取，訊息，按key設定過期時間，過期後將會自動刪除

一、Redis的使用

1.redis資料結構 – strings

set mystr "hello world!" //設定字串型別
get mystr //讀取字串型別

我們還可以通過字串型別進行數值操作：

127.0.0.1:6379> set mynum "2"
OK
127.0.0.1:6379> get mynum
"2"
127.0.0.1:6379> incr mynum
(integer) 3
127.0.0.1:6379> get mynum
"3"

在遇到數值操作時，redis會將字串型別轉換成數值。 由於INCR等指令本身就具有原子操作的特性，所以我們完全可以利用redis的INCR、INCRBY、DECR、DECRBY等指令來實現原子計數的效果，假如，在某種場景下有3個客戶端同時讀取了mynum的值（值為2），然後對其同時進行了加1的操作，那麼，最後mynum的值一定是5。不少網站都利用redis的這個特性來實現業務上的統計計數需求

2.redis資料結構 – lists

首先要明確一點，redis中的lists在底層實現上並不是陣列，而是連結串列，因此是增刪改快，定位較慢。 lists的常用操作包括LPUSH、RPUSH、LRANGE等。我們可以用LPUSH在lists的左側插入一個新元素，用RPUSH在lists的右側插入一個新元素，用LRANGE命令從lists中指定一個範圍來提取元素。

//新建一個list叫做mylist，並在列表頭部插入元素"1"
127.0.0.1:6379> lpush mylist "1" 
//返回當前mylist中的元素個數
(integer) 1 
//在mylist右側插入元素"2"
127.0.0.1:6379> rpush mylist "2" 
(integer) 2
//在mylist左側插入元素"0"
127.0.0.1:6379> lpush mylist "0" 
(integer) 3
//列出mylist中從編號0到編號1的元素
127.0.0.1:6379> lrange mylist 0 1 
1) "0"
2) "1"
//列出mylist中從編號0到倒數第一個元素
127.0.0.1:6379> lrange mylist 0 -1 
1) "0"
2) "1"
3) "2"

1.我們可以利用lists來實現一個訊息佇列，而且可以確保先後順序，不必像MySQL那樣還需要通過ORDER BY來進行排序。 2.利用LRANGE還可以很方便的實現分頁的功能。 3.在部落格系統中，每片博文的評論也可以存入一個單獨的list中。

3.redis資料結構 – 集合

redis的集合，是一種無序的集合，集合中的元素沒有先後順序。集合相關的操作也很豐富，如新增新元素、刪除已有元素、取交集、取並集、取差集等。

//向集合myset中加入一個新元素"one"
127.0.0.1:6379> sadd myset "one" 
(integer) 1
127.0.0.1:6379> sadd myset "two"
(integer) 1
//列出集合myset中的所有元素
127.0.0.1:6379> smembers myset 
1) "one"
2) "two"
//判斷元素1是否在集合myset中，返回1表示存在
127.0.0.1:6379> sismember myset "one" 
(integer) 1
//判斷元素3是否在集合myset中，返回0表示不存在
127.0.0.1:6379> sismember myset "three" 
(integer) 0
//新建一個新的集合yourset
127.0.0.1:6379> sadd yourset "1" 
(integer) 1
127.0.0.1:6379> sadd yourset "2"
(integer) 1
127.0.0.1:6379> smembers yourset
1) "1"
2) "2"
//對兩個集合求並集
127.0.0.1:6379> sunion myset yourset 
1) "1"
2) "one"
3) "2"
4) "two"

4.redis資料結構 – 雜湊

hashes存的是字串和字串值之間的對映，比如一個使用者要儲存其全名、姓氏、年齡等等，就很適合使用雜湊。

/建立雜湊，並賦值
127.0.0.1:6379> HMSET user:001 username antirez password P1pp0 age 34 
OK
//列出雜湊的內容
127.0.0.1:6379> HGETALL user:001 
1) "username"
2) "antirez"
3) "password"
4) "P1pp0"
5) "age"
6) "34"
//更改雜湊中的某一個值
127.0.0.1:6379> HSET user:001 password 12345 
(integer) 0
//再次列出雜湊的內容
127.0.0.1:6379> HGETALL user:001 
1) "username"
2) "antirez"
3) "password"
4) "12345"
5) "age"
6) "34"

二、Redis的考察

1.redis的併發競爭問題如何解決?

Redis為單程序單執行緒模式，採用佇列模式將併發訪問變為序列訪問。Redis本身沒有鎖的概念，Redis對於多個客戶端連線並不存在競爭，但是在Jedis客戶端對Redis進行併發訪問時會發生連線超時、資料轉換錯誤、阻塞、客戶端關閉連線等問題，這些問題均是由於客戶端連線混亂造成。對此有2種解決方法：

• 客戶端角度，為保證每個客戶端間正常有序與Redis進行通訊，對連線進行池化，同時對客戶端讀寫Redis操作採用內部鎖synchronized。
• 伺服器角度，利用setnx實現鎖。

注：對於第一種，需要應用程式自己處理資源的同步，可以使用的方法比較通俗，可以使用synchronized也可以使用lock；第二種需要用到Redis的setnx命令，但是需要注意一些問題。

2.redis持久化的方式

redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Append Only File）。

• RDB，簡而言之，就是在不同的時間點，將redis儲存的資料生成快照並存儲到磁碟等介質上；
• AOF，則是換了一個角度來實現持久化，那就是將redis執行過的所有寫指令記錄下來，在下次redis重新啟動時，只要把這些寫指令從前到後再重複執行一遍，就可以實現資料恢復了。

其實RDB和AOF兩種方式也可以同時使用，在這種情況下，如果redis重啟的話，則會優先採用AOF方式來進行資料恢復，這是因為AOF方式的資料恢復完整度更高。如果你沒有資料持久化的需求，也完全可以關閉RDB和AOF方式，這樣的話，redis將變成一個純記憶體資料庫，+持久化--就像memcache一樣。

3.redis常見效能問題和解決方案

• Master最好不要做任何持久化工作，如RDB記憶體快照和AOF日誌檔案
• 如果資料比較重要，某個Slave開啟AOF備份資料，策略設定為每秒同步一次
• 為了主從複製的速度和連線的穩定性，Master和Slave最好在同一個區域網內
• 儘量避免在壓力很大的主庫上增加從庫
• 主從複製不要用圖狀結構，用單向連結串列結構更為穩定，即：Master <- Slave1 <- Slave2 <- Slave3...。這樣的結構方便解決單點故障問題，實現Slave對Master的替換。如果Master掛了，可以立刻啟用Slave1做Master，其他不變。

4.redis的適用場景

會話快取（Session Cache） 最常用的一種使用Redis的情景是會話快取（session cache）。用Redis快取會話比其他儲存（如Memcached）的優勢在於：Redis提供持久化。當維護一個不是嚴格要求一致性的快取時，如果使用者的購物車資訊全部丟失，大部分人都會不高興的，現在，他們還會這樣嗎？ 幸運的是，隨著 Redis 這些年的改進，很容易找到怎麼恰當的使用Redis來快取會話的文件。甚至廣為人知的商業平臺Magento也提供Redis的外掛。

佇列 Reids在記憶體儲存引擎領域的一大優點是提供 list 和 set 操作，這使得Redis能作為一個很好的訊息佇列平臺來使用。Redis作為佇列使用的操作，就類似於本地程式語言（如Python）對 list 的 push/pop 操作。

如果你快速的在Google中搜索“Redis queues”，你馬上就能找到大量的開源專案，這些專案的目的就是利用Redis建立非常好的後端工具，以滿足各種佇列需求。例如，Celery有一個後臺就是使用Redis作為broker，你可以從這裡去檢視。

全頁快取（FPC） 除基本的會話token之外，Redis還提供很簡便的FPC平臺。回到一致性問題，即使重啟了Redis例項，因為有磁碟的持久化，使用者也不會看到頁面載入速度的下降，這是一個極大改進，類似PHP本地FPC。 再次以Magento為例，Magento提供一個外掛來使用Redis作為全頁快取後端。此外，對WordPress的使用者來說，Pantheon有一個非常好的外掛 wp-redis，這個外掛能幫助你以最快速度載入你曾瀏覽過的頁面。

排行榜/計數器 Redis在記憶體中對數字進行遞增或遞減的操作實現的非常好。集合（Set）和有序集合（Sorted Set）也使得我們在執行這些操作的時候變的非常簡單，Redis只是正好提供了這兩種資料結構。所以，我們要從排序集合中獲取到排名最靠前的10個使用者–我們稱之為“user_scores”，我們只需要像下面一樣執行即可： 當然，這是假定你是根據你使用者的分數做遞增的排序。如果你想返回使用者及使用者的分數，你需要這樣執行：ZRANGE user_scores 0 10 WITHSCORES，Agora Games就是一個很好的例子，用Ruby實現的，它的排行榜就是使用Redis來儲存資料的，你可以在這裡看到。

5.redis的高可用策略（單點故障避免策略）

高可用（High Availability），是當一臺伺服器停止服務後，對於業務及使用者毫無影響。 停止服務的原因可能由於網絡卡、路由器、機房、CPU負載過高、記憶體溢位、自然災害等不可預期的原因導致，在很多時候也稱單點問題。

主備方式 這種通常是一臺主機、一臺或多臺備機，在正常情況下主機對外提供服務，並把資料同步到備機，當主機宕機後，備機立刻開始服務。 Redis HA中使用比較多的是keepalived，它使主機備機對外提供同一個虛擬IP，客戶端通過虛擬IP進行資料操作，正常期間主機一直對外提供服務，宕機後VIP自動漂移到備機上。

優點是對客戶端毫無影響，仍然通過VIP操作。 缺點也很明顯，在絕大多數時間內備機是一直沒使用，被浪費著的。

主從方式 這種採取一主多從的辦法，主從之間進行資料同步。 當Master宕機後，通過選舉演算法(Paxos、Raft)從slave中選舉出新Master繼續對外提供服務，主機恢復後以slave的身份重新加入。 主從另一個目的是進行讀寫分離，這是當單機讀寫壓力過高的一種通用型解決方案。 其主機的角色只提供寫操作或少量的讀，把多餘讀請求通過負載均衡演算法分流到單個或多個slave伺服器上。

缺點是主機宕機後，Slave雖然被選舉成新Master了，但對外提供的IP服務地址卻發生變化了，意味著會影響到客戶端。 解決這種情況需要一些額外的工作，在當主機地址發生變化後及時通知到客戶端，客戶端收到新地址後，使用新地址繼續傳送新請求。

方案選擇 主備（keepalived）方案配置簡單、人力成本小，在資料量少、壓力小的情況下推薦使用。 如果資料量比較大，不希望過多浪費機器，還希望在宕機後，做一些自定義的措施，比如報警、記日誌、資料遷移等操作，推薦使用主從方式，因為和主從搭配的一般還有個管理監控中心。

6.redis的資料同步方式

無論是主備還是主從都牽扯到資料同步的問題，這也分2種情況：

• 同步方式：當主機收到客戶端寫操作後，以同步方式把資料同步到從機上，當從機也成功寫入後，主機才返回給客戶端成功，也稱資料強一致性。 很顯然這種方式效能會降低不少，當從機很多時，可以不用每臺都同步，主機同步某一臺從機後，從機再把資料分發同步到其他從機上，這樣提高主機效能分擔同步壓力。 在redis中是支援這楊配置的，一臺master，一臺slave，同時這臺salve又作為其他slave的master。
• 非同步方式：主機接收到寫操作後，直接返回成功，然後在後臺用非同步方式把資料同步到從機上。 這種同步效能比較好，但無法保證資料的完整性，比如在非同步同步過程中主機突然宕機了，也稱這種方式為資料弱一致性。

Redis主從同步採用的是非同步方式，因此會有少量丟資料的危險。還有種弱一致性的特例叫最終一致性，這塊詳細內容可參見CAP原理及一致性模型。

6.分散式與叢集

叢集時代 至少部署兩臺Redis伺服器構成一個小的叢集，主要有2個目的：

• 高可用性：在主機掛掉後，自動故障轉移，使前端服務對使用者無影響。
• 讀寫分離：將主機讀壓力分流到從機上。

可在客戶端元件上實現負載均衡，根據不同伺服器的執行情況，分擔不同比例的讀請求壓力。

Redis叢集

分散式 快取資料量不斷增加時，單機記憶體不夠使用，需要把資料切分不同部分，分佈到多臺伺服器上。 可在客戶端對資料進行分片，資料分片演算法詳見一致性Hash詳解、虛擬桶分片。

分散式叢集

大規模分散式叢集時代 當資料量持續增加時，應用可根據不同場景下的業務申請對應的分散式叢集。 這塊最關鍵的是快取治理這塊，其中最重要的部分是加入了代理服務。 應用通過代理訪問真實的Redis伺服器進行讀寫，這樣做的好處是：

避免越來越多的客戶端直接訪問Redis伺服器難以管理，而造成風險。 在代理這一層可以做對應的安全措施，比如限流、授權、分片。 避免客戶端越來越多的邏輯程式碼，不但臃腫升級還比較麻煩。 代理這層無狀態的，可任意擴充套件節點，對於客戶端來說，訪問代理跟訪問單機Redis一樣。

目前有公司使用的是客戶端元件和代理兩種方案並存，因為通過代理會影響一定的效能。 代理這塊對應的方案實現有Twitter的Twemproxy和豌豆莢的codis。

大規模分散式叢集

作者：YitaiCloud 連結：https://www.jianshu.com/p/7ef03afd01c6 來源：簡書 簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。