一.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.安裝
下載地址：http://redis.googlecode.com/files/redis-2.0.4.tar.gz
2.0目前是最新穩定版
可以在linux下運行如下命令進行安裝
$ tar xzf redis-2.0.4.tar.gzmake完後 redis-2.0.4目錄下會出現編譯後的redis服務程序redis-server,還有用於測試的客戶端程序redis-cli
$ cd redis-2.0.4
$ make
下面啓動redis服務.
$./redis-server注意這種方式啓動redis 使用的是默認配置。也可以通過啓動參數告訴redis使用指定配置文件使用下面命令啓動.
$ ./redis-server redis.conf
redis.conf是一個默認的配置文件。我們可以根據需要使用自己的配置文件。啓動redis服務進程後，就可以使用測試客戶端程序redis-cli和redis服務交互了.
比如
$ ./redis-cli這裏演示了get和set命令操作簡單類型value的例子。foo是key ,bar是個string類型的value
redis> set foo bar
OK
redis> get foo
"bar"
沒linux的可以通過這個在線的來練習，當然在線版的很多管理相關的命令是不支持的。
http://try.redis-db.com/
3.java客戶端hello,world
客戶端jar包地址http://cloud.github.com/downloads/alphazero/jredis/jredis-1.0-rc2.jar 。版本目前有點老，支持到Redis 1.2.6。最新版2.0的還沒release
在eclipse中新建一個java項目，然後添加jredis包引用。下面是個hello,world程序
package jredisStudy;好了redis環境已經搭建好了。後面會寫寫redis的各種類型和類型相關的命令和一些具體的應用場景
import org.jredis.*;
import org.jredis.ri.alphazero.JRedisClient;
public class App {
public static void main(String[] args) {
try {
JRedis jr = new JRedisClient("192.168.56.55",6379); //redis服務地址和端口號
String key = "mKey";
jr.set(key, "hello,redis!");
String v = new String(jr.get(key));
String k2 = "count";
jr.incr(k2);
jr.incr(k2);
System.out.println(v);
System.out.println(new String(jr.get(k2)));
} catch (Exception e) {
// TODO: handle exception
}
}
}
from:http://www.cnblogs.com/xhan/archive/2011/02/01/1948751.html
二.redis 數據類型
本文介紹下redis支持的各種數據類型包括string,list ,set ,sorted set 和hash
1. keys
redis本質上一個key-value db，所以我們首先來看看他的key.首先key也是字符串類型，但是key中不能包括邊界字符
由於key不是binary safe的字符串，所以像"my key"和"mykey\n"這樣包含空格和換行的key是不允許的
順便說一下在redis內部並不限制使用binary字符，這是redis協議限制的。"\r\n"在協議格式中會作爲特殊字符。
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,下面給個例子
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 {buf是個char數組用於存貯實際的字符串內容。其實char和c#中的byte是等價的，都是一個字節
long len;
long free;
char buf[];
};
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)
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 hello3. list
OK
redis> append k ,world
(integer) 11
redis> get k
"hello,world"
substr key start end
redis> substr k 0 8
"hello,wor"
redis> get k
"hello,world"
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實現. 這個限制可以在配置文件中指定
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"
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
轉自:http://www.cnblogs.com/xhan/archive/2011/02/02/1948891.html
三.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（3）[BY pattern]
(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"
除了可以按集合元素自身值排序外，還可以將集合元素內容按照給定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"
(對排序結果有疑問可看最下面的FAQ)
(4)[GET pattern]
上面的例子都是返回的ml集合中的元素。我們也可以通過get選項去獲取指定pattern作爲新key對應的值。看個組合起來的例子
redis> sort ml by name* get name* alpha這 次返回的就不在是ml中的元素了，而是name12 name13 name23 name23對應的值。當然排序是按照name12 name13 name23 name23值並根據字母順序排的。另外get選項可以有多個。看例子（#特殊符號引用的是原始集合也就是ml）
1. "lala"
2. "nihao"
3. "shi"
4. "wo"
redis> sort ml by name* get name* get # alpha最後在還有一個引用hash類型字段的特殊字符->，下面是例子
1. "lala"
2. "23"
3. "nihao"
4. "11"
5. "shi"
6. "13"
7. "wo"
8. "12"
redis> hset user1 name hanjie很容易理解，注意當對應的user23不存在時候返回的是nil
(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)
(5) [LIMIT start count]
上面例子返回結果都是全部。limit選項可以限定返回結果的數量。例子
redis> sort ml get name* limit 1 2start下標是從0開始的，這裏的limit選項意思是從第二個元素開始獲取2個
1. "wo"
2. "shi"
(6)[STORE dstkey]
如果對集合經常按照固定的模式去排序，那麼把排序結果緩存起來會減少不少cpu開銷.使用store選項可以將排序內容保存到指定key中。保存的類型是list
redis> sort ml get name* limit 1 2 store cl這個例子我們將排序結果保存到了cl中
(integer) 2
redis> type cl
list
redis> lrange cl 0 -1
1. "wo"
2. "shi"
還有一個問題也比較嚴重。如果要sort的集合非常大的話排序就會消耗很長時間。由於redis單線程的，所以長時間的排序操作會阻塞其他client的 請求。解決辦法是通過主從複製機制將數據複製到多個slave上。然後我們只在slave上做排序操作。並進可能的對排序結果緩存。另外就是一個方案是就 是採用sorted set對需要按某個順序訪問的集合建立索引。
redis> sadd tom:friend:list 123 #tom的好友列表 裏面是好友的uid
1
redis> sadd tom:friend:list 456
1
redis> sadd tom:friend:list 789
1
redis> sadd tom:friend:list 101
1
redis> set uid:sort:123 1000 #uid對應的成績
OK
redis> set uid:sort:456 6000
OK
redis> set uid:sort:789 100
OK
redis> set uid:sort:101 5999
OK
redis> set uid:123 "{'uid':123,'name':'lucy'}" #增加uid對應好友信息
OK
redis> set uid:456 "{'uid':456,'name':'jack'}"
OK
redis> set uid:789 "{'uid':789,'name':'marry'}"
OK
redis> set uid:101 "{'uid':101,'name':'icej'}"
OK
redis> sort tom:friend:list by uid:sort:* get uid:* #從好友列表中獲得id與uid:sort字段匹配後排序,並根據排序後的順序，用key在uid表獲得信息
1. {'uid':789,'name':'marry'}
2. {'uid':123,'name':'lucy'}
3. {'uid':101,'name':'icej'}
4. {'uid':456,'name':'jack'}
redis> sort tom:friend:list by uid:sort:* get uid:* get uid:sort:*
1. {'uid':789,'name':'marry'}
2. 100
3. {'uid':123,'name':'lucy'}
4. 1000
5. {'uid':101,'name':'icej'}
6. 5999
7. {'uid':456,'name':'jack'}
8. 6000
if (alpha) {
if (sortby) vector[j].u.cmpobj = getDecodedObject(byval);
} else {
if (byval->encoding == REDIS_ENCODING_RAW) {
vector[j].u.score = strtod(byval->ptr,NULL);
} else if (byval->encoding == REDIS_ENCODING_INT) {
/* Don't need to decode the object if it's
* integer-encoded (the only encoding supported) so
* far. We can just cast it */
vector[j].u.score = (long)byval->ptr;
} else {
redisAssert(1 != 1);
}
}
參考:
四.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可以發現這次incr a incr b都沒被執行。discard命令其實就是清空事務的命令隊列並退出事務上下文。
OK
redis> incr a
QUEUED
redis> incr b
QUEUED
redis> discard
OK
redis> get a
"1"
redis> get b
"1"
雖說redis事務在本質上也相當於序列化隔離級別的了。但是由於事務上下文的命令只排隊並不立即執行，所以事務中的寫操作不能依賴事務中的讀操作結果。看下面例子
redis> multi發現問題了吧。假如我們想用事務實現incr操作怎麼辦？可以這樣做嗎？
OK
redis> get a
QUEUED
redis> get b
QUEUED
redis> exec
1. "1"
2. "1"
redis> get a結論很明顯這樣是不行的。這樣和 get a 然後直接set a是沒區別的。很明顯由於get a 和set a並不能保證兩個命令是連續執行的(get操作不在事務上下文中)。很可能有兩個client同時做這個操作。結果我們期望是加兩次a從原來的1變成3. 但是很有可能兩個client的get a，取到都是1，造成最終加兩次結果卻是2。主要問題我們沒有對共享資源a的訪問進行任何的同步
"1"
redis> multi
OK
redis> set a 2
QUEUED
redis> exec
1. OK
redis> get a，
"2"
也就是說redis沒提供任何的加鎖機制來同步對a的訪問。
還好redis 2.1後添加了watch命令，可以用來實現樂觀鎖。看個正確實現incr命令的例子,只是在前面加了watch a
redis> watch awatch 命令會監視給定的key,當exec時候如果監視的key從調用watch後發生過變化，則整個事務會失敗。也可以調用watch多次監視多個key.這 樣就可以對指定的key加樂觀鎖了。注意watch的key是對整個連接有效的，事務也一樣。如果連接斷開，監視和事務都會被自動清除。當然了 exec,discard,unwatch命令都會清除連接中的所有監視.
OK
redis> get a
"1"
redis> multi
OK
redis> set a 2
QUEUED
redis> exec
1. OK
redis> get a，
"2"
redis的事務實現是如此簡單，當然會存在一些問題。第一個問題是redis只能保證事務的每個命令連續執行，但是如果事務中的一個命令失敗了，並不回滾其他命令，比如使用的命令類型不匹配。
redis> set a 5可以看到雖然incr b失敗了，但是其他兩個命令還是執行了。
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
最 後一個十分罕見的問題是 當事務的執行過程中，如果redis意外的掛了。很遺憾只有部分命令執行了，後面的也就被丟棄了。當然如果我們使用的append-only file方式持久化，redis會用單個write操作寫入整個事務內容。即是是這種方式還是有可能只部分寫入了事務到磁盤。發生部分寫入事務的情況 下，redis重啓時會檢測到這種情況，然後失敗退出。可以使用redis-check-aof工具進行修復，修復會刪除部分寫入的事務內容。修復完後就 能夠重新啓動了。
from:http://www.cnblogs.com/xhan/archive/2011/02/04/1949151.html
五.redis pipeline
redis是一個cs模式的tcp server，使用和http類似的請求響應協議。一個client可以通過一個socket連接發起多個請求命令。每個請求命令發出後client通常 會阻塞並等待redis服務處理，redis處理完後請求命令後會將結果通過響應報文返回給client。基本的通信過程如下
Client: INCR X基 本上四個命令需要8個tcp報文才能完成。由於通信會有網絡延遲,假如從client和server之間的包傳輸時間需要0.125秒。那麼上面的四個命 令8個報文至少會需要1秒才能完成。這樣即使redis每秒能處理100個命令，而我們的client也只能一秒鐘發出四個命令。這顯示沒有充分利用 redis的處理能力。除了可以利用mget,mset 之類的單條命令處理多個key的命令外
Server: 1
Client: INCR X
Server: 2
Client: INCR
X
Server: 3
Client: INCR X
Server: 4
我們還可以利用pipeline的方式從client打包多條命令一起發出，不需要等待單條命令的響應返回，而redis服務端會處理完多條命令後會將多條命令的處理結果打包到一起返回給客戶端。通信過程如下
Client: INCR X假 設不會因爲tcp 報文過長而被拆分。可能兩個tcp報文就能完成四條命令,client可以將四個incr命令放到一個tcp報文一起發送，server則可以將四條命令 的處理結果放到一個tcp報文返回。通過pipeline方式當有大批量的操作時候。我們可以節省很多原來浪費在網絡延遲的時間。需要注意到是用 pipeline方式打包命令發送，redis必須在處理完所有命令前先緩存起所有命令的處理結果。打包的命令越多，緩存消耗內存也越多。所以並是不是打 包的命令越多越好。具體多少合適需要根據具體情況測試。下面是個jredis客戶端使用pipeline的測試
Client: INCR X
Client: INCR X
Client: INCR X
Server:
1
Server: 2
Server: 3
Server: 4
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.*;代碼就是簡單的從命令行讀取傳過來的訂閱命令，然後通過一個socket連接發送給redis server,然後進入while循環一直讀取redis server傳過來訂閱的消息。並打印到控制檯
import java.io.*;
public class PubSubTest
{
public static void main(String[] args)
{
String cmd =
args[0]+"\r\n";
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)
{
}
}
}
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.*3 再啓動一個redis-cli用來發布兩條消息
Reading messages... (press
Ctrl-c to quit)
1. "psubscribe"
2. "news.*"
3. (integer) 1
redis> publish news.share "share a link4.查看兩個訂閱client的輸出
http://www.google.com"
(integer) 2
redis> publish
news.blog "I post a blog"
(integer) 2
此時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行代碼）。在安全，認證，可靠性這方便都沒有太多支持。
from:http://www.cnblogs.com/xhan/archive/2011/02/06/1949473.html
七.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文件,這點和快照有點類似。
from:http://www.cnblogs.com/xhan/archive/2011/02/07/1949640.html
八.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的更詳細介紹可以參考下面鏈接
http://antirez.com/post/redis-virtual-memory-story.html
http://redis.io/topics/internals-vm
from:http://www.cnblogs.com/xhan/archive/2011/02/07/1949717.html
十. redis java client
redis主頁上列出的java 客戶端有JDBC-Redis JRedis Jedis三種,下面分別介紹三種客戶端的優缺點及其他相關的工具.
|
|
支持redis版本 | 性能 | 維護 | 推薦 |
| JDBC-Redis | not good | |||
| JRedis |
1.2.n release 2.0.0 尚未release版本 |
fast | ||
| Jedis | 2.0.0 release | fast | actively developed | 推薦 |
JDBC-Redis
JDBC-Redis is just a JDBC wrapper for JRedis database.
If you plan on using your code with different back-ends then JDBC is a good way to go. NOTE: It is not a complete JDBC implementation and the NOSQL will bleed through.
If you are going to stay with Redis then I would suggest using the API, which will give you more flexibility. Use a DAO layer pattern to encapsulate your DB Access and down the road that is all you will need to change.
Redis syntax is completely different from standard SQL so using JDBC doesn't help encapsulating different back-ends as you suggest: I would have to write new queries anyway... – muriloq Jun 16 '10 at 14:00
@muriloq - but the mechanical acquiring and releasing resources is standard. – Romain Hippeau
spring wrapper
Spring provides a wrapper around both implementations(Jredis Jedis) and they're providing serialization/deserialization, amongst other things:
Person p = new Person("Joe", "Trader", 33);
template.convertAndSet("trader:1", p);
Person samePerson = template.getAndConvert("trader:1", Person.class);
Assert.assertEquals(p, samePerson);
放棄spring wrapper
項目中本來打算使用spring wrapper,出於以下原因最終還是放棄,直接使用Jedis,等有時間在把:
1.spring wrapper的版本是1.0.0.M2，裏面有些bug (*)
2.對shard的支持沒有jedis好
3.依賴spring3.0(主要是spring3.0 core中的convert及serializer),我們目前大多項目還是採用spring2.5.6(主要)
4.經過多層封裝後性能還是會有損耗
spring nosql/cross-store
prototype implementation allowing entities to be stored in multiple types of data stores (i.e. JPA and Neo4j or JPA and Redis etc.)
JOhm
JOhm is a blazingly fast Object-Hash Mapping library for Java inspired by the awesome Ohm. The JOhm OHM is a modern-day avatar of the old ORM's like Hibernate with the difference being that we are not dealing with an RDBMS here but with a NoSQL rockstar.
homepage:https://github.com/xetorthio/johm
jedis pool的問題
在使用jedis pool時遇到了這個問題：It seems like server has closed the connection
原因分析：
1.redis server 關閉了此客戶端的連接:server端設置了maxidletime(默認是5分鐘），服務端會不斷循環檢測clinet的最後一次通信時間（lastinteraction），如果大於maxidletime，則關閉連接，並回收相關資源。client在向該連接中寫數據後就會由於server端已經關閉而出現 broken pipe的問題。
2.pool的設置錯誤:
<bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">
<property name="maxActive" value="20" />
<property name="maxIdle" value="10" />
<property name="maxWait" value="1000" />
</bean><!-- jedis shard信息配置 -->
<bean id="jedis.shardInfo" class="redis.clients.jedis.JedisShardInfo">
<constructor-arg index="0" value="*.*.*.*" />
<constructor-arg index="1" value="6379" />
</bean>
<!-- jedis shard pool配置 -->
<bean id="shardedJedisPool" class="redis.clients.jedis.ShardedJedisPool">
<constructor-arg index="0" ref="jedisPoolConfig" />
<constructor-arg index="1">
<list>
<ref bean="jedis.shardInfo" />
</list>
</constructor-arg>
</bean>
<bean id="jedisCommands" factory-bean="shardedJedisPool"
factory-method="getResource" />
上面的這種配法在spring初始化時獲取一次實例化jedisCommands，而後每次的redis的調用時並未從pool中獲取
解決方案：
設置
<!-- POOL配置 -->
<bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">
<property name="maxActive" value="20" />
<property name="maxIdle" value="10" />
<property name="maxWait" value="1000" />
<property name="testOnBorrow" value="true"/>
</bean>
<!-- jedis shard信息配置 -->
<bean id="jedis.shardInfo" class="redis.clients.jedis.JedisShardInfo">
<constructor-arg index="0" value="*.*.*.*" />
<constructor-arg index="1" value="6379" />
</bean>
<!-- jedis shard pool配置 -->
<bean id="shardedJedisPool" class="redis.clients.jedis.ShardedJedisPool">
<constructor-arg index="0" ref="jedisPoolConfig" />
<constructor-arg index="1">
<list>
<ref bean="jedis.shardInfo" />
</list>
</constructor-arg>
</bean>
參考:
http://stackoverflow.com/questions/3047010/best-redis-library-for-java
https://github.com/xetorthio/johm
