window平臺Redis安裝
下載地址: http://code.google.com/p/servicestack/wiki/RedisWindowsDownload
Redis文件夾有以下幾個文件
redis-server.exe:服務程序
redis-check-dump.exe:本地數據庫檢查
redis-check-aof.exe:更新日誌檢查
redis-benchmark.exe:性能測試,用以模擬同時由N個客戶端發送M個 SETs/GETs 查詢 (類似於 Apache 的ab 工具).
指定redis的配置文件,如沒有指定,則使用默認設置
解壓目錄:\>redis-server.exe redis.conf
redis-cli.exe:命令行客戶端,測試用
解壓目錄:\>redis-cli.exe -h 127.0.0.1 -p 6379
設置一個Key並獲取返回的值:
$ ./redis-cli set mykey somevalue
OK
$ ./redis-cli get mykey
Somevalue
如何添加值到list:
$ ./redis-cli lpush mylist firstvalue
OK
$ ./redis-cli lpush mylist secondvalue
OK
$ ./redis-cli lpush mylist thirdvalue
OK
$ ./redis-cli lrange mylist 0 -1
1. thirdvalue
2. secondvalue
3. firstvalue
$ ./redis-cli rpop mylist
firstvalue
$ ./redis-cli lrange mylist 0 -1
1. thirdvalue
2. secondvalue
redis-benchmark.exe:性能測試,用以模擬同時由N個客戶端發送M個 SETs/GETs 查詢 (類似於 Apache 的 ab 工具).
./redis-benchmark -n 100000 –c 50
====== SET ======
100007 requests completed in 0.88 seconds (譯者注:100004 查詢完成於 1.14 秒 )
50 parallel clients (譯者注:50個併發客戶端)
3 bytes payload (譯者注:3字節有效載荷)
keep alive: 1 (譯者注:保持1個連接)
58.50% <= 0 milliseconds(譯者注:毫秒)
99.17% <= 1 milliseconds
99.58% <= 2 milliseconds
99.85% <= 3 milliseconds
99.90% <= 6 milliseconds
100.00% <= 9 milliseconds
114293.71 requests per second(譯者注:每秒 114293.71 次查詢)
Windows下測試併發客戶端極限爲60
=============================================================
linux平臺Redis安裝:
wget http://code.google.com/p/redis/downloads/detail?name=redis-2.0.4.tar.gz
tar xvzf redis-2.0.4.tar.gz
cd redis-2.0.4
make
mkdir /home/redis
cp redis-server /home/redis
cp redis-benchmark /home/redis
cp redis-cli /home/redis
cp redis.conf /home/redis
cd /home/redis
啓動
./redis-server redis.conf
進入命令交互模式,兩種:
1: ./redis-cli
2: telnet 127.0.0.1 6379 (ip接端口)
=============================================================
配置文件參數說明:
1. Redis默認不是以守護進程的方式運行,可以通過該配置項修改,使用yes啓用守護進程
daemonize no
2. 當Redis以守護進程方式運行時,Redis默認會把pid寫入/var/run/redis.pid文件,可以通過pidfile指定
pidfile /var/run/redis.pid
3. 指定Redis監聽端口,默認端口爲6379,作者在自己的一篇博文中解釋了爲什麼選用6379作爲默認端口,因爲6379在手機按鍵上MERZ對應的號碼,而MERZ取自意大利歌女Alessia Merz的名字
port 6379
4. 綁定的主機地址
bind 127.0.0.1
5.當 客戶端閒置多長時間後關閉連接,如果指定爲0,表示關閉該功能
timeout 300
6. 指定日誌記錄級別,Redis總共支持四個級別:debug、verbose、notice、warning,默認爲verbose
loglevel verbose
7. 日誌記錄方式,默認爲標準輸出,如果配置Redis爲守護進程方式運行,而這裏又配置爲日誌記錄方式爲標準輸出,則日誌將會發送給/dev/null
logfile stdout
8. 設置數據庫的數量,默認數據庫爲0,可以使用SELECT <dbid>命令在連接上指定數據庫id
databases 16
9. 指定在多長時間內,有多少次更新操作,就將數據同步到數據文件,可以多個條件配合
save <seconds> <changes>
Redis默認配置文件中提供了三個條件:
save 900 1
save 300 10
save 60 10000
分別表示900秒(15分鐘)內有1個更改,300秒(5分鐘)內有10個更改以及60秒內有10000個更改。
10. 指定存儲至本地數據庫時是否壓縮數據,默認爲yes,Redis採用LZF壓縮,如果爲了節省CPU時間,可以關閉該選項,但會導致數據庫文件變的巨大
rdbcompression yes
11. 指定本地數據庫文件名,默認值爲dump.rdb
dbfilename dump.rdb
12. 指定本地數據庫存放目錄
dir ./
13. 設置當本機爲slav服務時,設置master服務的IP地址及端口,在Redis啓動時,它會自動從master進行數據同步
slaveof <masterip> <masterport>
14. 當master服務設置了密碼保護時,slav服務連接master的密碼
masterauth <master-password>
15. 設置Redis連接密碼,如果配置了連接密碼,客戶端在連接Redis時需要通過AUTH <password>命令提供密碼,默認關閉
requirepass foobared
16. 設置同一時間最大客戶端連接數,默認無限制,Redis可以同時打開的客戶端連接數爲Redis進程可以打開的最大文件描述符數,如果設置 maxclients 0,表示不作限制。當客戶端連接數到達限制時,Redis會關閉新的連接並向客戶端返回max number of clients reached錯誤信息
maxclients 128
17. 指定Redis最大內存限制,Redis在啓動時會把數據加載到內存中,達到最大內存後,Redis會先嚐試清除已到期或即將到期的Key,當此方法處理 後,仍然到達最大內存設置,將無法再進行寫入操作,但仍然可以進行讀取操作。Redis新的vm機制,會把Key存放內存,Value會存放在swap區
maxmemory <bytes>
18. 指定是否在每次更新操作後進行日誌記錄,Redis在默認情況下是異步的把數據寫入磁盤,如果不開啓,可能會在斷電時導致一段時間內的數據丟失。因爲 redis本身同步數據文件是按上面save條件來同步的,所以有的數據會在一段時間內只存在於內存中。默認爲no
appendonly no
19. 指定更新日誌文件名,默認爲appendonly.aof
appendfilename appendonly.aof
20. 指定更新日誌條件,共有3個可選值:
no:表示等操作系統進行數據緩存同步到磁盤(快)
always:表示每次更新操作後手動調用fsync()將數據寫到磁盤(慢,安全)
everysec:表示每秒同步一次(折衷,默認值)
appendfsync everysec
21. 指定是否啓用虛擬內存機制,默認值爲no,簡單的介紹一下,VM機制將數據分頁存放,由Redis將訪問量較少的頁即冷數據swap到磁盤上,訪問多的頁面由磁盤自動換出到內存中(在後面的文章我會仔細分析Redis的VM機制)
vm-enabled no
22. 虛擬內存文件路徑,默認值爲/tmp/redis.swap,不可多個Redis實例共享
vm-swap-file /tmp/redis.swap
23. 將所有大於vm-max-memory的數據存入虛擬內存,無論vm-max-memory設置多小,所有索引數據都是內存存儲的(Redis的索引數據 就是keys),也就是說,當vm-max-memory設置爲0的時候,其實是所有value都存在於磁盤。默認值爲0
vm-max-memory 0
24. Redis swap文件分成了很多的page,一個對象可以保存在多個page上面,但一個page上不能被多個對象共享,vm-page-size是要根據存儲的 數據大小來設定的,作者建議如果存儲很多小對象,page大小最好設置爲32或者64bytes;如果存儲很大大對象,則可以使用更大的page,如果不 確定,就使用默認值
vm-page-size 32
25. 設置swap文件中的page數量,由於頁表(一種表示頁面空閒或使用的bitmap)是在放在內存中的,,在磁盤上每8個pages將消耗1byte的內存。
vm-pages 134217728
26. 設置訪問swap文件的線程數,最好不要超過機器的核數,如果設置爲0,那麼所有對swap文件的操作都是串行的,可能會造成比較長時間的延遲。默認值爲4
vm-max-threads 4
27. 設置在向客戶端應答時,是否把較小的包合併爲一個包發送,默認爲開啓
glueoutputbuf yes
28. 指定在超過一定的數量或者最大的元素超過某一臨界值時,採用一種特殊的哈希算法
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
29. 指定是否激活重置哈希,默認爲開啓(後面在介紹Redis的哈希算法時具體介紹)
activerehashing yes
30. 指定包含其它的配置文件,可以在同一主機上多個Redis實例之間使用同一份配置文件,而同時各個實例又擁有自己的特定配置文件
include /path/to/local.conf
=============================================================
問題討論:
1. Redis官方文檔對VM的使用提出了一些建議:
當你的key很小而value很大時,使用VM的效果會比較好.因爲這樣節約的內存比較大.
當你的key不小時,可以考慮使用一些非常方法將很大的key變成很大的value,比如你可以考慮將key,value組合成一個新的value.
最好使用linux ext3 等對稀疏文件支持比較好的文件系統保存你的swap文件.
vm-max-threads這個參數,可以設置訪問swap文件的線程數,設置最好不要超過機器的核數.如果設置爲0,那麼所有對swap文件的操作都是串行的.可能會造成比較長時間的延遲,但是對數據完整性有很好的保證.
2. 關於Redis新的存儲模式diskstore(http://timyang.net/data/redis-diskstore),節選:
適合Web 2.0數據訪問最佳的方式就是完全基於內存,比如用Memcached或者Redis snapshot方式。但是更多的業務場景是數據規模會超過RAM容量,因此有幾種不同的設計模式。
VM方式: 將數據分頁存放,由應用(如Redis)或者操作系統(如Varnish)將訪問量較少的頁即冷數據swap到磁盤上,訪問多的頁面由磁盤自動換出到內存中。應用實現VM缺點是代碼邏輯複雜,如果業務上冷熱數據邊界並不分明,則換入換出代價太高,系統整體性能低。不少搶鮮的網友在微博上也反饋過使用VM種種不穩定情況。操作系統實現缺點在於主要OS的VM換入換出是基於Page概念,比如OS VM1個Page是4K, 4K中只要還有一個元素即使只有1個字節被訪問,這個頁也不會被SWAP,換入也同樣道理,讀到一個字節可能會換入4K無用的內存。而Redis自己實現則可以達到控制換入的粒度。另外訪問操作系統SWAP內存區域時block進程,也是導致Redis要自己實現VM原因之一。 磁盤方式:所有的數據讀寫訪問都是基於磁盤,由操作系統來只能的緩存訪問的數據。由於現代操作系統都非常聰明,會將頻繁訪問的數據加入到內存中,因此應用並不需要過多特殊邏輯。MongoDB就是這種設計方式。這種方式也有一些已知的缺點,比如操作MMap寫入磁盤由操作系統控制,操作系統先寫哪裏後寫哪裏應用並不知情,如果寫入過程中發生了crash則數據一致性會存在問題。這個也是MongoDB飽受爭議的單機Durability問題
硬盤存儲+cache方式:實際原理和mysql+memcache方式類似,只不過將兩者功能合二爲一到一個底層服務中,簡化了調用。
在上面幾種方式中,除去VM,antirez覺得MongoDB方式也不太適合,因此選擇了disktore方式來實現新的磁盤存儲,具體細節是
1) 讀操作,使用read through以及LRU方式。內存中不存在的數據從磁盤拉取並放入內存,內存中放不下的數據採用LRU淘汰。
2) 寫操作,採用另外spawn一個線程單獨處理,寫線程通常是異步的,當然也可以把cache-flush-delay配置設成0,Redis儘量保證即時寫入。但是在很多場合延遲寫會有更好的性能,比如一些計數器用Redis存儲,在短時間如果某個計數反覆被修改,Redis只需要將最終的結果寫入磁盤。這種做法作者叫per key persistence。由於寫入會按key合併,因此和snapshot還是有差異,disk store並不能保證時間一致性。由於寫操作是單線程,即使cache-flush-delay設成0,多個client同時寫則需要排隊等待,如果隊列容量超過cache-max-memory,Redis設計會進入等待狀態,造成調用方卡住。Google Group上有熱心網友迅速完成了壓力測試,當內存用完之後,set每秒處理速度從25k下降到10k再到後來幾乎卡住。雖然通過增加cache-flush-delay可以提高相同key重複寫入性能;通過增加cache-max-memory可以應對臨時峯值寫入。但是diskstore寫入瓶頸最終還是在IO。
3) rdb 和新 diskstore 格式關係
rdb是傳統Redis內存方式的存儲格式,diskstore是另外一種格式,那兩者關係如何?
1.通過BGSAVE可以隨時將diskstore格式另存爲rdb格式,而且rdb格式還用於Redis複製以及不同存儲方式之間的中間格式。
2.通過工具可以將rdb格式轉換成diskstore格式。