一、redis環境搭建

1.簡介

redis是一個開源的key-value數據庫。它又經常被認為是一個數據結構服務器。因為它的value不僅包括基本的string類型還有list，set ，sorted set和hash類型。當然這些類型的元素也都是string類型。也就是說list，set這些集合類型也只能包含

string 類型。你可以在這些類型上做很多原子性的操作。比如對一個字符value追加字符串（APPEND命令）。加加或者減減一個數字字符串（INCR命令，當 然是按整數處理的）。可以對list類型進行push，或者pop元素操作（可以模擬棧和隊列）。對于set類型可以進行一些集合相關操作（intersection union difference）。memcache也有類似與++，--的命令。

不過memcache的value只包括string類型。遠沒有redis的value類型豐富。和memcahe一樣為了性能。redis的數據通常都是放到內存中的。當然redis可以每間隔一定時間將內存中數據寫入到磁盤以防止數據丟失。redis也支持主從復制機制（master-slave replication）。redis的其他特性包括簡單的事務支持和 發布訂閱（pub/sub）通道功能，而且redis配置管理非常簡單。還有各種語言版本的開源客戶端類庫。

2.安裝

3.0.7目前是最新穩定版

可以在linux下運行如下命令進行安裝

$ tar xg*** redis-3.0.7.tar.gz

$ cd redis-3.0.7

$ make

make完后 redis-3.0.7目錄下會出現編譯后的redis服務程序redis-server，還有用于測試的客戶端程序redis-cli

下面啟動redis服務。

$./redis-server

注意這種方式啟動redis 使用的是默認配置。也可以通過啟動參數告訴redis使用指定配置文件使用下面命令啟動。

$ 。/redis-server redis.conf

redis.conf是一個默認的配置文件。我們可以根據需要使用自己的配置文件。

啟動redis服務進程后，就可以使用測試客戶端程序redis-cli和redis服務交互了。

比如

$ 。/redis-cli

redis> set foo bar

OK

redis> get foo

“bar”

這里演示了get和set命令操作簡單類型value的例子。foo是key ，bar是個string類型的value

沒linux的可以通過這個在線的來練習，當然在線版的很多管理相關的命令是不支持的。

3.java客戶端hello，world

客戶端jar包為 jedis

import redis.clients.jedis.Jedis;

public class Test1 {

public static void main（String［］ args） {

// 連接本地的 Redis 服務

Jedis jedis = new Jedis（“169.254.173.100”）;

System.out.println（“Connection to server sucessfully”）;

// 查看服務是否運行

System.out.println（“Server is running： ” + jedis.ping（））;

String keys = “name”;

jedis.del（keys）;

String vaule = jedis.set（keys， “tanggao”）;

System.out.println（vaule）;

}

}

好了redis環境已經搭建好了。后面會寫寫redis的各種類型和類型相關的命令和一些具體的應用場景

二、 redis學習筆記之數據類型

本文介紹下redis支持的各種數據類型包括string，list ，set ，sorted set和hash

1. keys

redis本質上一個key-value db，所以我們首先來看看他的key.首先key也是字符串類型，但是key中不能包括邊界字符

由于key不是binary safe的字符串，所以像“my key”和“mykey ”這樣包含空格和換行的key是不允許的

順便說一下在redis內部并不限制使用binary字符，這是redis協議限制的。“ ”在協議格式中會作為特殊字符。

redis 1.2以后的協議中部分命令已經開始使用新的協議格式了（比如MSET）。總之目前還是把包含邊界字符當成非法的key吧，

免得被bug糾纏。

另外關于key的一個格式約定介紹下，object-type:id:field。比如user:1000:password，blog:xxidxx:title

還有key的長度最好不要太長。道理很明顯占內存啊，而且查找時候相對短key也更慢。不過也推薦過短的key，

比如u:1000:pwd，這樣的。顯然沒上面的user:1000:password可讀性好。

下面介紹下key相關的命令

exits key 測試指定key是否存在，返回1表示存在，0不存在

del key1 key2 。。。.keyN 刪除給定key，返回刪除key的數目，0表示給定key都不存在

type key 返回給定key的value類型。返回none 表示不存在key，string字符類型，list鏈表類型 set無序集合類型。。。

keys pattern 返回匹配指定模式的所有key，下面給個例子

redis> set test dsf

OK

redis> set tast dsaf

OK

redis> set tist adff

OK

redis> keys t*

1. “tist”

2. “tast”

3. “test”

redis> keys t［ia］st

1. “tist”

2. “tast”

redis> keys t？st

1. “tist”

2. “tast”

3. “test”

randomkey 返回從當前數據庫中隨機選擇的一個key，如果當前數據庫是空的，返回空串

rename oldkey newkey 原子的重命名一個key，如果newkey存在，將會被覆蓋，返回1表示成功，0失敗。可能是oldkey不存在或者和newkey相同

renamenx oldkey newkey 同上，但是如果newkey存在返回失敗

dbsize 返回當前數據庫的key數量

expire key seconds 為key指定過期時間，單位是秒。返回1成功，0表示key已經設置過過期時間或者不存在

ttl key 返回設置過過期時間的key的剩余過期秒數-1表示key不存在或者沒有設置過過期時間

select db-index 通過索引選擇數據庫，默認連接的數據庫所有是0，默認數據庫數是16個。返回1表示成功，0失敗

move key db-index 將key從當前數據庫移動到指定數據庫。返回1成功。0如果key不存在，或者已經在指定數據庫中

flushdb 刪除當前數據庫中所有key，此方法不會失敗。慎用

flushall 刪除所有數據庫中的所有key，此方法不會失敗。更加慎用

2. string 類型

string是redis最基本的類型，而且string類型是二進制安全的。意思是redis的string可以包含任何數據。比如jpg圖片或者序列化的對象

。從內部實現來看其實string可以看作byte數組，最大上限是1G字節。下面是string類型的定義。

struct sdshdr {

long len;

long free;

char buf［］;

};

buf是個char數組用于存貯實際的字符串內容。其實char和c#中的byte是等價的，都是一個字節

len是buf數組的長度，free是數組中剩余可用字節數。由此可以理解為什么string類型是二進制安全的了。因為它本質上就是個byte數組。

當然可以包含任何數據了。另外string類型可以被部分命令按int處理。比如incr等命令，下面詳細介紹。還有redis的其他類型像list，set，sorted set ，hash

它們包含的元素與都只能是string類型。

如果只用string類型，redis就可以被看作加上持久化特性的memcached.當然redis對string類型的操作比memcached多很多啊。如下：

set key value 設置key對應的值為string類型的value，返回1表示成功，0失敗

setnx key value 同上，如果key已經存在，返回0。nx 是not exist的意思

get key 獲取key對應的string值，如果key不存在返回nil

getset key value 原子的設置key的值，并返回key的舊值。如果key不存在返回nil

mget key1 key2 。。。 keyN 一次獲取多個key的值，如果對應key不存在，則對應返回nil。下面是個實驗，首先清空當前數據庫，然后

設置k1，k2.獲取時k3對應返回nil

redis> flushdb

OK

redis> dbsize

（integer） 0

redis> set k1 a

OK

redis> set k2 b

OK

redis> mget k1 k2 k3

1. “a”

2. “b”

3. （nil）

mset key1 value1 。。。 keyN valueN 一次設置多個key的值，成功返回1表示所有的值都設置了，失敗返回0表示沒有任何值被設置

msetnx key1 value1 。。。 keyN valueN 同上，但是不會覆蓋已經存在的key

incr key 對key的值做加加操作，并返回新的值。注意incr一個不是int的value會返回錯誤，incr一個不存在的key，則設置key為1

decr key 同上，但是做的是減減操作，decr一個不存在key，則設置key為-1

incrby key integer 同incr，加指定值 ，key不存在時候會設置key，并認為原來的value是0

decrby key integer 同decr，減指定值。decrby完全是為了可讀性，我們完全可以通過incrby一個負值來實現同樣效果，反之一樣。

append key value 給指定key的字符串值追加value，返回新字符串值的長度。下面給個例子

redis> set k hello

OK

redis> append k ，world

（integer） 11

redis> get k

“hello，world”

substr key start end 返回截取過的key的字符串值，注意并不修改key的值。下標是從0開始的，接著上面例子

redis> substr k 0 8

“hello，wor”

redis> get k

“hello，world”

3. list

redis的list類型其實就是一個每個子元素都是string類型的雙向鏈表。所以［lr］push和［lr］pop命令的算法時間復雜度都是O（1）

另外list會記錄鏈表的長度。所以llen操作也是O（1）。鏈表的最大長度是（2的32次方-1）。我們可以通過push，pop操作從鏈表的頭部或者尾部添加刪除元素。這使得list既可以用作棧，也可以用作隊列。有意思的是list的pop操作還有阻塞版本的。當我們［lr］pop一個list對象是，如果list是空，或者不存在，會立即返回nil。但是阻塞版本的b［lr］pop可以則可以阻塞，當然可以加超時時間，超時后也會返回nil。為什么要阻塞版本的pop呢，主要是為了避免輪詢。舉個簡單的例子如果我們用list來實現一個工作隊列。執行任務的thread可以調用阻塞版本的pop去

獲取任務這樣就可以避免輪詢去檢查是否有任務存在。當任務來時候工作線程可以立即返回，也可以避免輪詢帶來的延遲。ok下面介紹list相關命令

lpush key string 在key對應list的頭部添加字符串元素，返回1表示成功，0表示key存在且不是list類型

rpush key string 同上，在尾部添加llen key 返回key對應list的長度，key不存在返回0，如果key對應類型不是list返回錯誤

lrange key start end 返回指定區間內的元素，下標從0開始，負值表示從后面計算，-1表示倒數第一個元素 ，key不存在返回空列表

ltrim key start end 截取list，保留指定區間內元素，成功返回1，key不存在返回錯誤

lset key index value 設置list中指定下標的元素值，成功返回1，key或者下標不存在返回錯誤

lrem key count value 從key對應list中刪除count個和value相同的元素。count為0時候刪除全部

lpop key 從list的頭部刪除元素，并返回刪除元素。如果key對應list不存在或者是空返回nil，如果key對應值不是list返回錯誤

rpop 同上，但是從尾部刪除

blpop key1.。.keyN timeout 從左到右掃描返回對第一個非空list進行lpop操作并返回，比如blpop list1 list2 list3 0 ，如果list不存在

list2，list3都是非空則對list2做lpop并返回從list2中刪除的元素。如果所有的list都是空或不存在，則會阻塞timeout秒，timeout為0表示一直阻塞。

當阻塞時，如果有client對key1.。.keyN中的任意key進行push操作，則第一在這個key上被阻塞的client會立即返回。如果超時發生，則返回nil。有點像unix的select或者poll

brpop 同blpop，一個是從頭部刪除一個是從尾部刪除

rpoplpush srckey destkey 從srckey對應list的尾部移除元素并添加到destkey對應list的頭部，最后返回被移除的元素值，整個操作是原子的。如果srckey是空

或者不存在返回nil

4. set

redis的set是string類型的無序集合。set元素最大可以包含（2的32次方-1）個元素。set的是通過hash table實現的，所以添加，刪除，查找的復雜度都是O（1）。hash table會隨著添加或者刪除自動的調整大小。需要注意的是調整hash table大小時候需要同步（獲取寫鎖）會阻塞其他讀寫操作。可能不久后就會改用跳表（skip list）來實現

跳表已經在sorted set中使用了。關于set集合類型除了基本的添加刪除操作，其他有用的操作還包含集合的取并集（union），交集（intersection），

差集（difference）。通過這些操作可以很容易的實現sns中的好友推薦和blog的tag功能。下面詳細介紹set相關命令

sadd key member 添加一個string元素到，key對應的set集合中，成功返回1，如果元素以及在集合中返回0，key對應的set不存在返回錯誤

srem key member 從key對應set中移除給定元素，成功返回1，如果member在集合中不存在或者key不存在返回0，如果key對應的不是set類型的值返回錯誤

spop key 刪除并返回key對應set中隨機的一個元素，如果set是空或者key不存在返回nil

srandmember key 同spop，隨機取set中的一個元素，但是不刪除元素

smove srckey dstkey member 從srckey對應set中移除member并添加到dstkey對應set中，整個操作是原子的。成功返回1，如果member在srckey中不存在返回0，如果

key不是set類型返回錯誤

scard key 返回set的元素個數，如果set是空或者key不存在返回0

sismember key member 判斷member是否在set中，存在返回1，0表示不存在或者key不存在

sinter key1 key2.。.keyN 返回所有給定key的交集

sinterstore dstkey key1.。.keyN 同sinter，但是會同時將交集存到dstkey下

sunion key1 key2.。.keyN 返回所有給定key的并集

sunionstore dstkey key1.。.keyN 同sunion，并同時保存并集到dstkey下

sdiff key1 key2.。.keyN 返回所有給定key的差集

sdiffstore dstkey key1.。.keyN 同sdiff，并同時保存差集到dstkey下

smembers key 返回key對應set的所有元素，結果是無序的

5 sorted set

和set一樣sorted set也是string類型元素的集合，不同的是每個元素都會關聯一個double類型的score。sorted set的實現是skip list和hash table的混合體

當元素被添加到集合中時，一個元素到score的映射被添加到hash table中，所以給定一個元素獲取score的開銷是O（1），另一個score到元素的映射被添加到skip list

并按照score排序，所以就可以有序的獲取集合中的元素。添加，刪除操作開銷都是O（log（N））和skip list的開銷一致，redis的skip list實現用的是雙向鏈表，這樣就可以逆序從尾部取元素。sorted set最經常的使用方式應該是作為索引來使用。我們可以把要排序的字段作為score存儲，對象的id當元素存儲。下面是sorted set相關命令

zadd key score member 添加元素到集合，元素在集合中存在則更新對應score

zrem key member 刪除指定元素，1表示成功，如果元素不存在返回0

zincrby key incr member 增加對應member的score值，然后移動元素并保持skip list保持有序。返回更新后的score值

zrank key member 返回指定元素在集合中的排名（下標），集合中元素是按score從小到大排序的

zrevrank key member 同上，但是集合中元素是按score從大到小排序

zrange key start end 類似lrange操作從集合中去指定區間的元素。返回的是有序結果

zrevrange key start end 同上，返回結果是按score逆序的

zrangebyscore key min max 返回集合中score在給定區間的元素

zcount key min max 返回集合中score在給定區間的數量

zcard key 返回集合中元素個數

zscore key element 返回給定元素對應的score

zremrangebyrank key min max 刪除集合中排名在給定區間的元素

zremrangebyscore key min max 刪除集合中score在給定區間的元素

6. hash

redis hash是一個string類型的field和value的映射表。它的添加，刪除操作都是O（1）（平均）.hash特別適合用于存儲對象。相較于將對象的每個字段存成

單個string類型。將一個對象存儲在hash類型中會占用更少的內存，并且可以更方便的存取整個對象。省內存的原因是新建一個hash對象時開始是用zipmap（又稱為small hash）來存儲的。這個zipmap其實并不是hash table，但是zipmap相比正常的hash實現可以節省不少hash本身需要的一些元數據存儲開銷。盡管zipmap的添加，刪除，查找都是O（n），但是由于一般對象的field數量都不太多。所以使用zipmap也是很快的，也就是說添加刪除平均還是O（1）。如果field或者value的大小超出一定限制后，redis會在內部自動將zipmap替換成正常的hash實現。這個限制可以在配置文件中指定

hash-max-zipmap-entries 64 #配置字段最多64個

hash-max-zipmap-value 512 #配置value最大為512字節

下面介紹hash相關命令

hset key field value 設置hash field為指定值，如果key不存在，則先創建

hget key field 獲取指定的hash field

hmget key filed1.。..fieldN 獲取全部指定的hash filed

hmset key filed1 value1 。.. filedN valueN 同時設置hash的多個field

hincrby key field integer 將指定的hash filed 加上給定值

hexists key field 測試指定field是否存在

hdel key field 刪除指定的hash field

hlen key 返回指定hash的field數量

hkeys key 返回hash的所有field

hvals key 返回hash的所有value

hgetall 返回hash的所有filed和value

三、 redis學習筆記之排序

在了解完各種redis類型后，這次介紹下redis排序命令.redis支持對list，set和sorted set元素的排序。排序命令是sort完整的命令格式如下：

SORT key ［BY pattern］ ［LIMIT start count］ ［GET pattern］ ［ASC|DESC］ ［ALPHA］ ［STORE dstkey］

下面我們一一說明各種命令選項

（1）sort key

這個是最簡單的情況，沒有任何選項就是簡單的對集合自身元素排序并返回排序結果。下面給個例子

redis> lpush ml 12

（integer） 1

redis> lpush ml 11

（integer） 2

redis> lpush ml 23

（integer） 3

redis> lpush ml 13

（integer） 4

redis> sort ml

1. “11”

2. “12”

3. “13”

4. “23”

（2）［ASC|DESC］ ［ALPHA］

sort默認的排序方式（asc）是從小到大排的，當然也可以按照逆序或者按字符順序排。逆序可以加上desc選項，想按字母順序排可以加alpha選項，當然alpha可以和desc一起用。下面是個按字母順序排的例子

redis> lpush mylist baidu

（integer） 1

redis> lpush mylist hello

（integer） 2

redis> lpush mylist xhan

（integer） 3

redis> lpush mylist soso

（integer） 4

redis> sort mylist

1. “soso”

2. “xhan”

3. “hello”

4. “baidu”

redis> sort mylist alpha

1. “baidu”

2. “hello”

3. “soso”

4. “xhan”

redis> sort mylist desc alpha

1. “xhan”

2. “soso”

3. “hello”

4. “baidu”

（3）［BY pattern］

除了可以按集合元素自身值排序外，還可以將集合元素內容按照給定pattern組合成新的key，并按照新key中對應的內容進行排序。下面的例子接著使用第一個例子中的ml集合做演示：

redis> set name11 nihao

OK

redis> set name12 wo

OK

redis> set name13 shi

OK

redis> set name23 lala

OK

redis> sort ml by name*

1. “13”

2. “23”

3. “11”

4. “12”

*代表了ml中的元素值，所以這個排序是按照name12 name13 name23 name23這四個key對應值排序的，當然返回的還是排序后ml集合中的元素

（4）［GET pattern］

上面的例子都是返回的ml集合中的元素。我們也可以通過get選項去獲取指定pattern作為新key對應的值。看個組合起來的例子

redis> sort ml by name* get name* alpha

1. “lala”

2. “nihao”

3. “shi”

4. “wo”

這 次返回的就不在是ml中的元素了，而是name12 name13 name23 name23對應的值。當然排序是按照name12 name13 name23 name23值并根據字母順序排的。另外get選項可以有多個。看例子（#特殊符號引用的是原始集合也就是ml）

redis> sort ml by name* get name* get # alpha

1. “lala”

2. “23”

3. “nihao”

4. “11”

5. “shi”

6. “13”

7. “wo”

8. “12”

最后在還有一個引用hash類型字段的特殊字符->，下面是例子

redis> hset user1 name hanjie

（integer） 1

redis> hset user11 name hanjie

（integer） 1

redis> hset user12 name 86

（integer） 1

redis> hset user13 name lxl

（integer） 1

redis> sort ml get user*->name

1. “hanjie”

2. “86”

3. “lxl”

4. （nil）

很容易理解，注意當對應的user23不存在時候返回的是nil

（5） ［LIMIT start count］

上面例子返回結果都是全部。limit選項可以限定返回結果的數量。例子

redis> sort ml get name* limit 1 2

1. “wo”

2. “shi”

start下標是從0開始的，這里的limit選項意思是從第二個元素開始獲取2個

（6）［STORE dstkey］

如果對集合經常按照固定的模式去排序，那么把排序結果緩存起來會減少不少cpu開銷。使用store選項可以將排序內容保存到指定key中。保存的類型是list

redis> sort ml get name* limit 1 2 store cl

（integer） 2

redis> type cl

list

redis> lrange cl 0 -1

1. “wo”

2. “shi”

這個例子我們將排序結果保存到了cl中

功能介紹完后，再討論下關于排序的一些問題。如果我們有多個redis server的話，不同的key可能存在于不同的server上。比如name12 name13 name23 name23，很有可能分別在四個不同的server上存貯著。這種情況會對排序性能造成很大的影響。redis作者在他的blog上提到了這個問題的解 決辦法，就是通過key tag將需要排序的key都放到同一個server上 。由于具體決定哪個key存在哪個服務器上一般都是在client端hash的辦法來做的。我們可以通過只對key的部分進行hash.舉個例子假如我們 的client如果發現key中包含［］。那么只對key中［］包含的內容進行hash。我們將四個name相關的key，都這樣命名［name］12 ［name］13 ［name］23 ［name］23，于是client程序就會把他們都放到同一server上。不知道jredis實現了沒。

還有一個問題也比較嚴重。如果要sort的集合非常大的話排序就會消耗很長時間。由于redis單線程的，所以長時間的排序操作會阻塞其他client的 請求。解決辦法是通過主從復制機制將數據復制到多個slave上。%然后我們只在slave上做排序操作。并進可能的對排序結果緩存。另外就是一個方案是就 是采用sorted set對需要按某個順序訪問的集合建立索引。

四、 redis學習筆記之事務

redis對事務的支持目前還比較簡單。redis只能保證一個client發起的事務中的命令可以連續的執行，而中間不會插入其他client的命令。 由于redis是單線程來處理所有client的請求的所以做到這點是很容易的。一般情況下redis在接受到一個client發來的命令后會立即處理并 返回處理結果，但是當一個client在一個連接中發出multi命令有，這個連接會進入一個事務上下文，該連接后續的命令并不是立即執行，而是先放到一 個隊列中。當從此連接受到exec命令后，redis會順序的執行隊列中的所有命令。并將所有命令的運行結果打包到一起返回給client.然后此連接就 結束事務上下文。下面可以看一個例子

redis> multi

OK

redis> incr a

QUEUED

redis> incr b

QUEUED

redis> exec

1. （integer） 1

2. （integer） 1

從這個例子我們可以看到incr a ，incr b命令發出后并沒執行而是被放到了隊列中。調用exec后倆個命令被連續的執行，最后返回的是兩條命令執行后的結果

我們可以調用discard命令來取消一個事務。接著上面例子

redis> multi

OK

redis> incr a

QUEUED

redis> incr b

QUEUED

redis> discard

OK

redis> get a

“1”

redis> get b

“1”

可以發現這次incr a incr b都沒被執行。discard命令其實就是清空事務的命令隊列并退出事務上下文。

雖說redis事務在本質上也相當于序列化隔離級別的了。但是由于事務上下文的命令只排隊并不立即執行，所以事務中的寫操作不能依賴事務中的讀操作結果。看下面例子

redis> multi

OK

redis> get a

QUEUED

redis> get b

QUEUED

redis> exec

1. “1”

2. “1”

發現問題了吧。假如我們想用事務實現incr操作怎么辦？可以這樣做嗎？

redis> get a

“1”

redis> multi

OK

redis> set a 2

QUEUED

redis> exec

1. OK

redis> get a，

“2”

結 論很明顯這樣是不行的。這樣和 get a 然后直接set a是沒區別的。很明顯由于get a和set a并不能保證兩個命令是連續執行的（get操作不在事務上下文中）。很可能有兩個client同時做這個操作。結果我們期望是加兩次a從原來的1變成3.但是很有可能兩個client的get a，取到都是1，造成最終加兩次結果卻是2。主要問題我們沒有對共享資源a的訪問進行任何的同步

也就是說redis沒提供任何的加鎖機制來同步對a的訪問。

還好redis 2.1后添加了watch命令，可以用來實現樂觀鎖。看個正確實現incr命令的例子，只是在前面加了watch a

redis> watch a

OK

redis> get a

“1”

redis> multi

OK

redis> set a 2

QUEUED

redis> exec

1. OK

redis> get a，

“2”

watch 命令會監視給定的key，當exec時候如果監視的key從調用watch后發生過變化，則整個事務會失敗。也可以調用watch多次監視多個key.這 樣就可以對指定的key加樂觀鎖了。注意watch的key是對整個連接有效的，事務也一樣。如果連接斷開，監視和事務都會被自動清除。當然了exec，discard，unwatch命令都會清除連接中的所有監視。

redis的事務實現是如此簡單，當然會存在一些問題。第一個問題是redis只能保證事務的每個命令連續執行，但是如果事務中的一個命令失敗了，并不回滾其他命令，比如使用的命令類型不匹配。

redis> set a 5

OK

redis> lpush b 5

（integer） 1

redis> set c 5

OK

redis> multi

OK

redis> incr a

QUEUED

redis> incr b

QUEUED

redis> incr c

QUEUED

redis> exec

1. （integer） 6

2. （error） ERR Operation against a key holding the wrong kind of value

3. （integer） 6

可以看到雖然incr b失敗了，但是其他兩個命令還是執行了。

最 后一個十分罕見的問題是 當事務的執行過程中，如果redis意外的掛了。很遺憾只有部分命令執行了，后面的也就被丟棄了。當然如果我們使用的append-only file方式持久化，redis會用單個write操作寫入整個事務內容。即是是這種方式還是有可能只部分寫入了事務到磁盤。發生部分寫入事務的情況 下，redis重啟時會檢測到這種情況，然后失敗退出。可以使用redis-check-aof工具進行修復，修復會刪除部分寫入的事務內容。修復完后就 能夠重新啟動了。

五、 redis學習筆記之pipeline

redis是一個cs模式的tcp server，使用和http類似的請求響應協議。一個client可以通過一個socket連接發起多個請求命令。每個請求命令發出后client通常 會阻塞并等待redis服務處理，redis處理完后請求命令后會將結果通過響應報文返回給client。基本的通信過程如下

Client： INCR X

Server： 1

Client： INCR X

Server： 2

Client： INCR X

Server： 3

Client： INCR X

Server： 4

基 本上四個命令需要8個tcp報文才能完成。由于通信會有網絡延遲，假如從client和server之間的包傳輸時間需要0.125秒。那么上面的四個命 令8個報文至少會需要1秒才能完成。這樣即使redis每秒能處理100個命令，而我們的client也只能一秒鐘發出四個命令。這顯示沒有充分利用redis的處理能力。除了可以利用mget，mset之類的單條命令處理多個key的命令外

我們還可以利用pipeline的方式從client打包多條命令一起發出，不需要等待單條命令的響應返回，而redis服務端會處理完多條命令后會將多條命令的處理結果打包到一起返回給客戶端。通信過程如下

Client： INCR X

Client： INCR X

Client： INCR X

Client： INCR X

Server： 1

Server： 2

Server： 3

Server： 4

假 設不會因為tcp 報文過長而被拆分。可能兩個tcp報文就能完成四條命令，client可以將四個incr命令放到一個tcp報文一起發送，server則可以將四條命令 的處理結果放到一個tcp報文返回。通過pipeline方式當有大批量的操作時候。我們可以節省很多原來浪費在網絡延遲的時間。需要注意到是用pipeline方式打包命令發送，redis必須在處理完所有命令前先緩存起所有命令的處理結果。打包的命令越多，緩存消耗內存也越多。所以并是不是打 包的命令越多越好。具體多少合適需要根據具體情況測試。下面是個jredis客戶端使用pipeline的測試

package jredisStudy;

import org.jredis.JRedis;

import org.jredis.connector.ConnectionSpec;

import org.jredis.ri.alphazero.JRedisClient;

import org.jredis.ri.alphazero.JRedisPipelineService;

import org.jredis.ri.alphazero.connection.DefaultConnectionSpec;

public class PipeLineTest {

public static void main（String［］ args） {

long start = System.currentTimeMillis（）;

usePipeline（）;

long end = System.currentTimeMillis（）;

System.out.println（end-start）;

start = System.currentTimeMillis（）;

withoutPipeline（）;

end = System.currentTimeMillis（）;

System.out.println（end-start）;

}

private static void withoutPipeline（）

{

try {

JRedis jredis = new JRedisClient（“192.168.56.55”，6379）;

for（int i =0 ; i 《 100000 ; i++）

{

jredis.incr（“test2”）;

}

jredis.quit（）;

} catch （Exception e） {

}

}

private static void usePipeline（） {

try {

ConnectionSpec spec = DefaultConnectionSpec.newSpec（“192.168.56.55”， 6379， 0， null）;

JRedis jredis = new JRedisPipelineService（spec）;

for（int i =0 ; i 《 100000 ; i++）

{

jredis.incr（“test2”）;

}

jredis.quit（）;

} catch （Exception e） {

}

}

}

輸出

103408 //使用了pipeline

104598 //沒有使用

測試結果不是很明顯，這應該是跟我的測試環境有關。我是在自己win連接虛擬機的linux。網絡延遲比較小。所以pipeline

優勢不明顯。如果網絡延遲小的話，最好還是不用pipeline。除了增加復雜外，帶來的性能提升不明顯。

六、 redis學習筆記之發布訂閱

發布訂閱（pub/sub）是一種消息通信模式，主要的目的是解耦消息發布者和消息訂閱者之間的耦合，這點和設計模式中的觀察者模式比較相似。pub /sub不僅僅解決發布者和訂閱者直接代碼級別耦合也解決兩者在物理部署上的耦合。redis作為一個pub/sub server，在訂閱者和發布者之間起到了消息路由的功能。訂閱者可以通過subscribe和psubscribe命令向redis server訂閱自己感興趣的消息類型，redis將消息類型稱為通道（channel）。當發布者通過publish命令向redis server發送特定類型的消息時。訂閱該消息類型的全部client都會收到此消息。這里消息的傳遞是多對多的。一個client可以訂閱多個channel，也可以向多個channel發送消息。

下面做個實驗。這里使用兩個不同的client一個是redis自帶的redis-cli另一個是用java寫的簡單的client。代碼如下

import java.net.*;

import java.io.*;

public class PubSubTest {

public static void main（String［］ args） {

String cmd = args［0］+“ ”;

try {

Socket socket = new Socket（“192.168.56.55”，6379）;

InputStream in = socket.getInputStream（）;

OutputStream out = socket.getOutputStream（）;

out.write（cmd.getBytes（））; //發送訂閱命令

byte［］ buffer = new byte［1024］;

while （true） {

int readCount = in.read（buffer）;

System.out.write（buffer， 0， readCount）;

System.out.println（“--------------------------------------”）;

}

} catch （Exception e） {

}

}

}

代碼就是簡單的從命令行讀取傳過來的訂閱命令，然后通過一個socket連接發送給redis server，然后進入while循環一直讀取redis server傳過來訂閱的消息。并打印到控制臺

1 首先編譯并運行此java程序（我是win7下面運行的）

D：>javac PubSubTest.java

D：>java PubSubTest “subscribe news.share news.blog”

*3

$9

subscribe

$10

news.share

：1

*3

$9

subscribe

$9

news.blog

：2

--------------------------------------

2 啟動redis-cli

redis> psubscribe news.*

Reading messages.。. （press Ctrl-c to quit）

1. “psubscribe”

2. “news.*”

3. （integer） 1

3 再啟動一個redis-cli用來發布兩條消息

redis> publish news.share “share a link http://www.google.com”

（integer） 2

redis> publish news.blog “I post a blog”

（integer） 2

4.查看兩個訂閱client的輸出

此時java client打印如下內容

*3

$7

message

$10

news.share

$34

share a link http://www.google.com

--------------------------------------

*3

$7

message

$9

news.blog

$13

I post a blog

--------------------------------------

另一個redis-cli輸出如下

1. “pmessage”

2. “news.*”

3. “news.share”

4. “share a link http://www.google.com”

1. “pmessage”

2. “news.*”

3. “news.blog”

4. “I post a blog”

分析下

java client使用subscribe命令訂閱news.share和news.blog兩個通道，然后立即收到server返回的訂閱成功消息，可以看出redis的協議是文本類型的，這里不解釋具體協議內容了，可以參考http://redis.io/topics/protocol或者http://terrylee.me/blog/post/2011/01/26/redis-internal-part3.aspx。這個報文內容有兩部分，第一部分表示該socket連接上使用subscribe訂閱news.share成功后，此連接訂閱通道數為1，后一部分表示使用subscribe訂閱news.blog成功后，該連接訂 閱通道總數為2。

redis client使用psubscribe訂閱了一個使用通配符的通道（*表示任意字符串），此訂閱會收到所有與news.*匹配的通道消息。redis- cli打印到控制臺的訂閱成功消息表示使用psubscribe命令訂閱news.*成功后，連接訂閱通道總數為1。

當我們在一個client使用publish向news.share和news.blog通道發出兩個消息后。redis返回的（integer） 2表示有兩個連接收到了此消息。通過觀察兩個訂閱者的輸出可以驗證。具體格式不解釋了，都比較簡單。

看 完一個小例子后應該對pub/sub功能有了一個感性的認識。需要注意的是當一個連接通過subscribe或者psubscribe訂閱通道后就進入訂 閱模式。在這種模式除了再訂閱額外的通道或者用unsubscribe或者punsubscribe命令退出訂閱模式，就不能再發送其他命令。另外使用psubscribe命令訂閱多個通配符通道，如果一個消息匹配上了多個通道模式的話，會多次收到同一個消息。

jredis目前版本沒提供pub/sub支持，不過自己實現一個應該也挺簡單的。整個應用程序可以共享同一個連接。因為redis返回的消息報文中除了消息內容本身外還包括消息相關的通道信息，當收到消息后可以根據不同的通道信息去調用不同的callback來處理。

另外個人覺得redis的pub/sub還是有點太單薄（實現才用150行代碼）。在安全，認證，可靠性這方便都沒有太多支持。

七、 redis學習筆記之持久化

redis是一個支持持久化的內存數據庫，也就是說redis需要經常將內存中的數據同步到磁盤來保證持久化。redis支持兩種持久化方式，一種是Snapshotting（快照）也是默認方式，另一種是Append-only file（縮寫aof）的方式。下面分別介紹

Snapshotting

快照是默認的持久化方式。這種方式是就是將內存中數據以快照的方式寫入到二進制文件中，默認的文件名為dump.rdb。可以通過配置設置自動做快照持久 化的方式。我們可以配置redis在n秒內如果超過m個key被修改就自動做快照，下面是默認的快照保存配置

save 900 1 #900秒內如果超過1個key被修改，則發起快照保存

save 300 10 #300秒內容如超過10個key被修改，則發起快照保存

save 60 10000

下面介紹詳細的快照保存過程

1.redis調用fork，現在有了子進程和父進程。

2. 父進程繼續處理client請求，子進程負責將內存內容寫入到臨時文件。由于os的寫時復制機制（copy on write）父子進程會共享相同的物理頁面，當父進程處理寫請求時os會為父進程要修改的頁面創建副本，而不是寫共享的頁面。所以子進程的地址空間內的數 據是fork時刻整個數據庫的一個快照。

3.當子進程將快照寫入臨時文件完畢后，用臨時文件替換原來的快照文件，然后子進程退出。

client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主線程中保存快照的，由于redis是用一個主線程來處理所有client的請求，這種方式會阻塞所有client請求。所以不推薦使用。另一點需要注意的是，每次快照持久化都是將內存數據完整寫入到磁盤一次，并不 是增量的只同步臟數據。如果數據量大的話，而且寫操作比較多，必然會引起大量的磁盤io操作，可能會嚴重影響性能。

另外由于快照方式是在一定間隔時間做一次的，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改。如果應用要求不能丟失任何修改的話，可以采用aof持久化方式。下面介紹

Append-only file

aof 比快照方式有更好的持久化性，是由于在使用aof持久化方式時，redis會將每一個收到的寫命令都通過write函數追加到文件中（默認是appendonly.aof）。當redis重啟時會通過重新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。當然由于os會在內核中緩存write做的修改，所以可能不是立即寫到磁盤上。這樣aof方式的持久化也還是有可能會丟失部分修改。不過我們可以通過配置文件告訴redis我們想要 通過fsync函數強制os寫入到磁盤的時機。有三種方式如下（默認是：每秒fsync一次）

appendonly yes //啟用aof持久化方式

# appendfsync always //每次收到寫命令就立即強制寫入磁盤，最慢的，但是保證完全的持久化，不推薦使用

appendfsync everysec //每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，推薦

# appendfsync no //完全依賴os，性能最好，持久化沒保證

aof 的方式也同時帶來了另一個問題。持久化文件會變的越來越大。例如我們調用incr test命令100次，文件中必須保存全部的100條命令，其實有99條都是多余的。因為要恢復數據庫的狀態其實文件中保存一條set test 100就夠了。為了壓縮aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis將使用與快照類似的方式將內存中的數據 以命令的方式保存到臨時文件中，最后替換原來的文件。具體過程如下

1. redis調用fork，現在有父子兩個進程

2. 子進程根據內存中的數據庫快照，往臨時文件中寫入重建數據庫狀態的命令

3.父進程繼續處理client請求，除了把寫命令寫入到原來的aof文件中。同時把收到的寫命令緩存起來。這樣就能保證如果子進程重寫失敗的話并不會出問題。

4.當子進程把快照內容寫入已命令方式寫到臨時文件中后，子進程發信號通知父進程。然后父進程把緩存的寫命令也寫入到臨時文件。

5.現在父進程可以使用臨時文件替換老的aof文件，并重命名，后面收到的寫命令也開始往新的aof文件中追加。

需要注意到是重寫aof文件的操作，并沒有讀取舊的aof文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似。

八、 redis學習筆記之主從復制

redis主從復制配置和使用都非常簡單。通過主從復制可以允許多個slave server擁有和master server相同的數據庫副本。下面是關于redis主從復制的一些特點

1.master可以有多個slave

2.除了多個slave連到相同的master外，slave也可以連接其他slave形成圖狀結構

3.主從復制不會阻塞master。也就是說當一個或多個slave與master進行初次同步數據時，master可以繼續處理client發來的請求。相反slave在初次同步數據時則會阻塞不能處理client的請求。

4.主從復制可以用來提高系統的可伸縮性，我們可以用多個slave專門用于client的讀請求，比如sort操作可以使用slave來處理。也可以用來做簡單的數據冗余

5.可以在master禁用數據持久化，只需要注釋掉master配置文件中的所有save配置，然后只在slave上配置數據持久化。

下面介紹下主從復制的過程

當設置好slave服務器后，slave會建立和master的連接，然后發送sync命令。無論是第一次同步建立的連接還是連接斷開后的重新連 接，master都會啟動一個后臺進程，將數據庫快照保存到文件中，同時master主進程會開始收集新的寫命令并緩存起來。后臺進程完成寫文件 后，master就發送文件給slave，slave將文件保存到磁盤上，然后加載到內存恢復數據庫快照到slave上。接著master就會把緩存的命 令轉發給slave。而且后續master收到的寫命令都會通過開始建立的連接發送給slave。從master到slave的同步數據的命令和從client發送的命令使用相同的協議格式。當master和slave的連接斷開時slave可以自動重新建立連接。如果master同時收到多個slave發來的同步連接命令，只會使用啟動一個進程來寫數據庫鏡像，然后發送給所有slave。

配置slave服務器很簡單，只需要在配置文件中加入如下配置

slaveof 192.168.1.1 6379 #指定master的ip和端口

九、 redis學習筆記之虛擬內存

首先說明下redis的虛擬內存與os的虛擬內存不是一碼事，但是思路和目的都是相同的。就是暫時把不經常訪問的數據從內存交換到磁盤中，從而騰出寶貴的 內存空間用于其他需要訪問的數據。尤其是對于redis這樣的內存數據庫，內存總是不夠用的。除了可以將數據分割到多個redis server外。另外的能夠提高數據庫容量的辦法就是使用vm把那些不經常訪問的數據交換的磁盤上。如果我們的存儲的數據總是有少部分數據被經常訪問，大 部分數據很少被訪問，對于網站來說確實總是只有少量用戶經常活躍。當少量數據被經常訪問時，使用vm不但能提高單臺redis server數據庫的容量，而且也不會對性能造成太多影響。

redis沒有使用os提供的虛擬內存機制而是自己在用戶態實現了自己的虛擬內存機制，作者在自己的blog專門解釋了其中原因。http://antirez.com/post/redis-virtual-memory-story.html

主要的理由有兩點

1.os 的虛擬內存是已4k頁面為最小單位進行交換的。而redis的大多數對象都遠小于4k，所以一個os頁面上可能有多個redis對象。另外redis的集 合對象類型如list，set可能存在與多個os頁面上。最終可能造成只有10%key被經常訪問，但是所有os頁面都會被os認為是活躍的，這樣只有內 存真正耗盡時os才會交換頁面。

2.相比于os的交換方式。redis可以將被交換到磁盤的對象進行壓縮，保存到磁盤的對象可以去除指針和對象元數據信息。一般壓縮后的對象會比內存中的對象小10倍。這樣redis的vm會比os vm能少做很多io操作。

下面是vm相關配置

vm-enabled yes #開啟vm功能

vm-swap-file /tmp/redis.swap #交換出來的value保存的文件路徑/tmp/redis.swap

vm-max-memory 1000000 #redis使用的最大內存上限，超過上限后redis開始交換value到磁盤文件中。

vm-page-size 32 #每個頁面的大小32個字節

vm-pages 134217728 #最多使用在文件中使用多少頁面，交換文件的大小= vm-page-size * vm-pages

vm-max-threads 4 #用于執行value對象換入換出的工作線程數量。0表示不使用工作線程（后面介紹）

redis的vm在設計上為了保證key的查找速度，只會將value交換到swap文件中。所以如果是內存問題是由于太多value很小的key造成 的，那么vm并不能解決。和os一樣redis也是按頁面來交換對象的。redis規定同一個頁面只能保存一個對象。但是一個對象可以保存在多個頁面中。 在redis使用的內存沒超過vm-max-memory之前是不會交換任何value的。當超過最大內存限制后，redis會選擇較老的對象。如果兩個 對象一樣老會優先交換比較大的對象，精確的公式swappability = age*log（size_in_memory）。 對于vm-page-size的設置應該根據自己的應用將頁面的大小設置為可以容納大多數對象的大小。太大了會浪費磁盤空間，太小了會造成交換文件出現碎 片。對于交換文件中的每個頁面，redis會在內存中對應一個1bit值來記錄頁面的空閑狀態。所以像上面配置中頁面數量（vm-pages 134217728 ）會占用16M內存用來記錄頁面空閑狀態。vm-max-threads表示用做交換任務的線程數量。如果大于0推薦設為服務器的cpu core的數量。如果是0則交換過程在主線程進行。

參數配置討論完后，在來簡單介紹下vm是如何工作的，

當vm-max-threads設為0時（Blocking VM）

換出

主線程定期檢查發現內存超出最大上限后，會直接已阻塞的方式，將選中的對象保存到swap文件中，并釋放對象占用的內存，此過程會一直重復直到下面條件滿足

1.內存使用降到最大限制以下

2.swap文件滿了

3.幾乎全部的對象都被交換到磁盤了

換入

當有client請求value被換出的key時。主線程會以阻塞的方式從文件中加載對應的value對象，加載時此時會阻塞所以client。然后處理client的請求

當vm-max-threads大于0（Threaded VM）

換出

當主線程檢測到使用內存超過最大上限，會將選中的要交換的對象信息放到一個隊列中交由工作線程后臺處理，主線程會繼續處理client請求。

換入

如果有client請求的key被換出了，主線程先阻塞發出命令的client，然后將加載對象的信息放到一個隊列中，讓工作線程去加載。加載完畢后工作線程通知主線程。主線程再執行client的命令。這種方式只阻塞請求value被換出key的client

總的來說blocking vm的方式總的性能會好一些，因為不需要線程同步，創建線程和恢復被阻塞的client等開銷。但是也相應的犧牲了響應性。threaded vm的方式主線程不會阻塞在磁盤io上，所以響應性更好。如果我們的應用不太經常發生換入換出，而且也不太在意有點延遲的話則推薦使用blocking vm的方式。關于redis vm的更詳細介紹可以參考下面鏈接