Redis 學習筆記一

redis是什麼

redis是一個開源的、使用C語言編寫的、支援網路互動的、可基於記憶體也可持久化的Key-Value資料庫。

redis的官網地址，非常好記，是redis.io。（特意查了一下，網域名稱尾碼io屬於國家網域名稱，是british Indian Ocean territory，即英屬印度洋地區）目前，Vmware在資助著redis項目的開發和維護。

Redis 是完全開源免費的，遵守BSD協議，是一個高效能的key-value資料庫。

Redis 與其他 key - value 緩衝產品有以下三個特點：

1.Redis支援資料的持久化，可以將記憶體中的資料保持在磁碟中，重啟的時候可以再次載入進行使用。

2.Redis不僅僅支援簡單的key-value類型的資料，同時還提供list，set，zset，hash等資料結構的儲存。

3.Redis支援資料的備份，即master-slave模式的資料備份。

redis 優勢

1.效能極高– Redis能讀的速度是110000次/s,寫的速度是81000次/s 。

2.豐富的資料類型– Redis支援二進位案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 資料類型操作。

3.原子– Redis的所有操作都是原子性的，同時Redis還支援對幾個操作全並後的原子性執行。

4.豐富的特性– Redis還支援 publish/subscribe, 通知, key 到期等等特性。

 

Redis能做的事情很多，這裡有一篇是Redis作者談redis的應用情境，個人覺得很贊，對redis的認知更深刻。地址：http://blog.csdn.net/dizzthxl/article/details/8498875

redis與其他key-value儲存的不同

Redis有著更為複雜的資料結構並且提供對他們的原子性操作，這是一個不同於其他資料庫的進化路徑。Redis的資料類型都是基於基本資料結構的同時對程式員透明，無需進行額外的抽象。

Redis運行在記憶體中但是可以持久化到磁碟，所以在對不同資料集進行高速讀寫時需要權衡記憶體，應為資料量不能大於硬體記憶體。在記憶體資料庫方面的另一個優點是，相比在磁碟上相同的複雜的資料結構，在記憶體中操作起來非常簡單，這樣Redis可以做很多內部複雜性很強的事情。同時，在磁碟格式方面他們是緊湊的以追加的方式產生的，因為他們並不需要進行隨機訪問。

下載Redis

http://www.cnblogs.com/edisonfeng/p/3571870.html

Redis持久化機制

1.定時快照方式(snapshot)：

該持久化方式實際是在Redis內部一個定時器事件，每隔固定時間去檢查當前資料發生的改變次數與時間是否滿足配置的持久化觸發的條件，如果滿足則通過作業系統fork調用來建立出一個子進程，這個子進程預設會與父進程共用相同的地址空間，這時就可以通過子進程來遍曆整個記憶體來進行儲存操作，而主進程則仍然可以提供服務，當有寫入時由作業系統按照記憶體頁(page)為單位來進行copy-on-write保證父子進程之間不會互相影響。

該持久化的主要缺點是定時快照只是代表一段時間內的記憶體映像，所以系統重啟會丟失上次快照與重啟之間所有的資料。

 

2. 基於語句追加方式(aof)：

aof方式實際類似mysql的基於語句的binlog方式，即每條會使Redis記憶體資料發生改變的命令都會追加到一個log檔案中，也就是說這個log檔案就是Redis的持久化資料。

aof的方式的主要缺點是追加log檔案可能導致體積過大，當系統重啟恢複資料時如果是aof的方式則載入資料會非常慢，幾十G的資料可能需要幾小 時才能載入完，當然這個耗時並不是因為磁碟檔案讀取速度慢，而是由於讀取的所有命令都要在記憶體中執行一遍。另外由於每條命令都要寫log,所以使用aof 的方式，Redis的讀寫效能也會有所下降。

 

3.虛擬記憶體方式：

虛擬記憶體方式是Redis來進行使用者空間的資料換入換出的一個策略，此種方式在實現的效果上比較差，主要問題是代碼複雜，重啟慢，複製慢等等.

 

4.diskstore方式：

diskstore方式是作者放棄了虛擬記憶體方式後選擇的一種新的實現方式，也就是傳統的B-tree的方式，目前仍在實驗階段，後續是否可用我們可以拭目以待。

 

5.持久化機制的選擇

  當業務不需要資料持久化時，當然關閉所有的持久化方式可以獲得最佳的效能以及最大記憶體的使用量；如果需要使用持久化，根據是否可以容忍重啟丟失部分資料在快照方式與語句追加方式之間選擇其一，不要使用虛擬記憶體以及diskstore方式。目前來說，個人覺得選擇aof的方式是最佳的選擇。

難以取捨的持久化機制主要是快照和aof方式。相比於aof快照的特點是速度快，恢複的速度也快。但是宕機的時候丟失的資料相對多一點。

當aof和快照同時開啟的時候，資料恢複時會首先使用 aof的檔案來恢複，恢複失敗的時候再去考慮快照。

  redis 分區

分區是分割資料到多個Redis執行個體的處理過程，因此每個執行個體只儲存key的一個子集。

 

1）.分區的優勢

通過利用多台電腦記憶體的和值，允許我們構造更大的資料庫。

通過多核和多台電腦，允許我們擴充計算能力；通過多台電腦和網路介面卡，允許我們擴充網路頻寬。

2)。分區的不足

redis的一些特性在分區方面表現的不是很好：

涉及多個key的操作通常是不被支援的。舉例來說，當兩個set映射到不同的redis執行個體上時，你就不能對這兩個set執行交集操作。

涉及多個key的redis事務不能使用。

當使用分區時，資料處理較為複雜，比如你需要處理多個rdb/aof檔案，並且從多個執行個體和主機備份持久化檔案。

增加或刪除容量也比較複雜。redis叢集大多數支援在運行時增加、刪除節點的透明資料平衡的能力，但是類似於用戶端分區、代理等其他系統則不支援這項特性。然而，一種叫做presharding的技術對此是有協助的。

 

3）。分區類型

Redis 有兩種類型分區。假設有4個Redis執行個體 R0，R1，R2，R3，和類似user:1，user:2這樣的表示使用者的多個key，對既定的key有多種不同方式來選擇這個key存放在哪個執行個體中。也就是說，有不同的系統來映射某個key到某個Redis服務。

1.定界分割

最簡單的分區方式是定界分割，就是映射一定範圍的對象到特定的Redis執行個體。比如，ID從0到10000的使用者會儲存到執行個體R0，ID從10001到 20000的使用者會儲存到R1，以此類推。這種方式是可行的，並且在實際中使用，不足就是要有一個區間範圍到執行個體的映射表。這個表要被管理，同時還需要各種對象的映射表，通常對Redis來說並非是好的方法。

2.雜湊分割

另外一種分區方法是hash分區。這對任何key都適用，也無需是object_name:這種形式，像這樣：用一個hash函數將key轉換為一個數字，比如使用crc32 hash函數。對key foobar執行crc32(foobar)會輸出類似93024922的整數。 對這個整數模數，將其轉化為0-3之間的數字，就可以將這個整數映射到4個Redis執行個體中的一個了。93024922 % 4 = 2，就是說key foobar應該被存到R2執行個體中。注意：模數操作是取除的餘數，通常在多種程式設計語言中用%操作符實現。

Java 與Redis ———— 個人使用Jedis，首選。