Redis從入門到精通：初級篇

原文連接：http://www.cnblogs.com/xrq730/p/8890896.html，轉載請註明出處，謝謝

 

Redis從入門到精通：初級篇

平時陸陸續續看了很多Redis的文章了，工做中也一直在用Redis，感受是時候對過往Redis的所學進行一次系統性的總結。《Redis從入門到精通》系列會分爲初級、中級、高級三篇，從淺入深講解Redis相關知識點。

在本文中，咱們將看到如下內容：

• Redis簡介
• Redis安裝、啓動
• Redis登陸受權
• Redis配置文件redis.conf中參數詳細的一個解讀
• Redis性能測試

這些內容無關具體用法，做爲一些初級的知識，系統地先認識一下Redis。

 

Redis簡介

Redis是一款開源的使用ANSI C語言編寫、遵照BSD協議、支持網絡、可基於內存也可持久化的日誌型、Key-Value高性能數據庫。Redis與其餘Key-Value緩存產品相比有如下三個特色：

• 支持數據持久化，能夠將內存中的數據保存在磁盤中，重啓可再次加載使用
• 支持簡單的Key-Value類型的數據，同時還提供List、Set、Zset、Hash等數據結構的存儲
• 支持數據的備份，即Master-Slave模式的數據備份

同時，咱們再看下Redis有什麼優點：

• 讀速度爲110000次/s，寫速度爲81000次/s，性能極高
• 具備豐富的數據類型，這個上面已經提過了
• Redis全部操做都是原子的，意思是要麼成功執行要麼失敗徹底不執行，多個操做也支持事務
• 豐富的特性，好比Redis支持publish/subscribe、notify、key過時等

 

Redis安裝、啓動

此次寫Redis系列的文章，LZ特地去阿里雲上買了一個月的服務器，操做系統是Linux，由於Redis項目自己不正式支持Windows系統。不過微軟開放技術小組開發和維護了Windows版本的Redis，下載地址爲https://github.com/MicrosoftArchive/redis/releases，感興趣的能夠本身去試下，LZ在本身筆記本上安裝啓動過，沒有問題，但就不細說了。

下面說一下在Linux系統上安裝並啓動Redis的步驟（個人Redis安裝在/data/component/redis目錄下，每一步使用的命令標紅加粗）：

• 進入目錄，cd /data/component/redis
• 下載Redis，wget http://download.redis.io/releases/redis-3.2.11.tar.gz，能夠看到LZ使用的Redis版本是3.2.11，在LZ寫這篇文章的時候，Redis最新版本爲4.0.9，地址爲http://download.redis.io/releases/redis-4.0.9.tar.gz，感興趣的朋友也能夠用這個版本
• 解壓下載下來的tar包，tar -zxvf redis-3.2.11.tar.gz，解壓完畢的文件夾名稱爲redis-3.2.11
• 進入redis-3.2.11，cd redis-3.2.11
• 因爲咱們下載下來的是源文件，所以使用make命令對源文件進行一個構建，構建完畢咱們會發現src目錄下多出了redis-benchmark、redis-check-aof、redis-check-rdb、redis-cli、redis-sentinel、redis-server幾個可執行文件，這幾個可執行文件後面會說到
• 因爲上述幾個命令在/data/component/redis/redis-3.2.11/src目錄下，爲了更方便地使用這幾個命令而不須要指定全路徑，配置一下環境變量。這裏我是以非root用戶進行登陸的，所以配置用戶變量，先執行cd命令回到初始目錄，再vi ./.bash_profile，在path這一行加入PATH=$PATH:$HOME/.local/bin:$HOME/bin:/data/component/redis/redis-3.2.11/src，使用:wq保存並退出
• 使環境變量生效，執行source ./.bash_profile
• 使用redis-server便可啓動redis，redis-server /data/component/redis/redis-3.2.11/redis.conf

不過這個時候咱們的啓動稍微有點問題，不是後臺啓動的，即ctrl+c以後Redis就停了：

爲了解決這個問題，咱們須要修改一下redis.conf，將Redis設置爲以守護進程的方式進行啓動，打開redis.conf，找到daemonize，將其設置爲yes便可：

這個時候先關閉一下再啓動，Redis就在後臺自動運行了，關閉Redis有兩種方式：

• redis-cli shutdown，這是種安全關閉redis的方式，但這種寫法只適用於沒有配置密碼的場景，比較不安全，配置密碼下一部分會講
• kill -9 pid，這種方式就是強制關閉，可能會形成數據未保存

重啓後，咱們可使用ps -ef | grep redis，netstat -ant | grep 6379命令來驗證Redis已經啓動。

 

Redis登陸受權

上面咱們安裝了Redis，但這種方式是很是不安全的，由於沒有密碼，這樣任何鏈接上Redis服務器的用戶均可以對Redis執行操做，因此這一部分咱們來說一下給Redis設置密碼。

打開redis.conf，找到"requirepass"部分，打開本來關閉的註釋，替換一下本身想要的密碼便可：

重啓Redis，受權登陸有兩種作法：

• 鏈接的時候直接指定密碼，redis-cli -h 127.0.0.1 -p 6379 -a 123456
  
• 鏈接後受權，redis-cli -h 127.0.0.1 -p 6379，auth 123456

在配置了密碼的狀況下，沒有進行受權，那麼對Redis發送的命令，將返回"(error) NOAUTH Authentication required."。

 

Redis配置文件redis.conf

上面兩小節，設置使用守護線程啓動、設置密碼，都須要修改redis.conf，說明redis.conf是Redis核心的配置文件，本小節咱們來看一下redis.conf中一些經常使用配置：

配置	做用	默認
bind	當配置了bind以後： 只有bind指定的ip能夠直接訪問Redis,這樣能夠避免將Redis服務暴露於危險的網絡環境中，防止一些不安全的人隨隨便便經過遠程訪問Redis 若是bind選項爲空或0.0.0.0的話，那會接受全部來自於可用網絡接口的鏈接	127.0.0.1
protected-mode	protected-mode是Redis3.2以後的新特性，用於增強Redis的安全管理，當知足如下兩種狀況時，protected-mode起做用： bind未設置，即接收全部來自網絡的鏈接 密碼未設置 當知足以上兩種狀況且protected-mode=yes的時候，訪問Redis將報錯，即密碼未設置的狀況下，無密碼訪問Redis只能經過安裝Redis的本機進行訪問	yes
port	Redis訪問端口，因爲Redis是單線程模型，所以單機開多個Redis進程的時候會修改端口，否則通常使用你們比較熟悉的6379端口就能夠了	6379
tcp-backlog	半鏈接隊列的大小，對半鏈接隊列不熟的能夠看我之前的文章TCP：三次握手、四次握手、backlog及其餘	511
timeout	指定在一個client空閒多少秒以後就關閉它，0表示無論	0
tcp-keepalive	設置tcp協議的keepalive，從Redis的註釋來看，這個參數有兩個做用： 發現死的鏈接 從中間網絡設備的角度看鏈接是否存活	300
daemonize	這個前面說過了，指定Redis是否以守護進程的方式啓動	no
supervised	這個參數表示能夠經過upstart和systemd管理Redis守護進程，這個具體和操做系統相關，資料也不是不少，就暫時無論了	no
pidfile	當Redis以守護進程的方式運行的時候,Redis默認會把pid寫到pidfile指定的文件中	/var/run/redis_6379.pid
loglevel	指定Redis的日誌級別，Redis自己的日誌級別有notice、verbose、notice、warning四種，按照文檔的說法，這四種日誌級別的區別是： debug，很是多信息，適合開發/測試 verbose，不少不多有用的信息（直譯，讀着拗口，從上下文理解應該是有用信息很少的意思），但並不像debug級別這麼混亂 notice，適度的verbose級別的輸出，極可能是生產環境中想要的 warning，只記錄很是重要/致命的信息	notice
logfile	配置log文件地址,默認打印在命令行終端的窗口上	""
databases	設置Redis數據庫的數量，默認使用0號DB	16
save	把Redis數據保存到磁盤上，這個是在RDB的時候用的，介紹RDB的時候專門說這個	save 900 1 save 300 10 save 60 10000
stop-writes-on-bgsave-error	當啓用了RDB且最後一次後臺保存數據失敗，Redis是否中止接收數據。 這會讓用戶意識到數據沒有正確持久化到磁盤上，不然沒有人會注意到災難（disaster）發生了。 若是Redis重啓了，那麼又能夠從新開始接收數據了	yes
rdbcompression	是否在RBD的時候使用LZF壓縮字符串，若是但願省點CPU，那就設爲no，不過no的話數據集可能就比較大	yes
rdbchecksum	是否校驗RDB文件，在RDB文件中有一個checksum專門用於校驗	yes
dbfilename	dump的文件位置	dump.rdb
dir	Redis工做目錄	./
slaveof	主從複製，使用slaveof讓一個節點稱爲某個節點的副本，這個只須要在副本上配置	關閉
masterauth	若是主機使用了requirepass配置進行密碼保護，使用這個配置告訴副本鏈接的時候須要鑑權	關閉
slave-serve-stale-data	當一個Slave與Master失去聯繫或者複製正在進行中，Slave可能會有兩種表現： 若是爲yes，Slave仍然會應答客戶端請求，但返回的數據多是過期的或者數據多是空的 若是爲no，在執行除了INFO、SLAVEOF兩個命令以外，都會應答"SYNC with master in progres"錯誤	yes
slave-read-only	配置Redis的Slave實例是否接受寫操做，即Slave是否爲只讀Redis	yes
slave-priority	從站優先級是能夠從redis的INFO命令輸出中查到的一個整數。當主站不能正常工做時，redis sentinel使用它來選擇一個從站並將它提高爲主站。  低優先級的從站被認爲更適合於提高，所以若是有三個從站優先級分別是10， 100， 25，sentinel會選擇優先級爲10的從站，由於它的優先級最低。  然而優先級值爲0的從站不能執行主站的角色，所以優先級爲0的從站永遠不會被redis sentinel提高。	100
requirepass	設置客戶端認證密碼	關閉
rename-command	命令重命名，對於一些危險命令例如： flushdb（清空數據庫） flushall（清空全部記錄） config（客戶端鏈接後可配置服務器） keys（客戶端鏈接後可查看全部存在的鍵）                    做爲服務端redis-server，經常須要禁用以上命令來使得服務器更加安全，禁用的具體作法是是： rename-command FLUSHALL "" 也能夠保留命令可是不能輕易使用，重命名這個命令便可： rename-command FLUSHALL abcdefg 這樣，重啓服務器後則須要使用新命令來執行操做，不然服務器會報錯unknown command	關閉
maxclients	設置同時鏈接的最大客戶端數量，一旦達到了限制，Redis會關閉全部的新鏈接併發送一個"max number of clients reached"的錯誤	關閉，默認10000
maxmemory	不要使用超過指定數量的內存，一旦達到了，Redis會嘗試使用驅逐策略來移除鍵	關閉
maxmemory-policy	當達到了maxmemory以後Redis如何移除數據，有如下的一些策略： volatile-lru，使用LRU算法，移除範圍爲設置了失效時間的 allkeys-lru，根據LRU算法，移除範圍爲全部的 volatile-random，使用隨機算法，移除範圍爲設置了失效時間的 allkeys-random，使用隨機算法，移除範圍爲全部的 volatile-ttl，移除最近過時的數據 noeviction，不過時，當寫操做的時候返回錯誤 注意，當寫操做且Redis發現沒有合適的數據能夠移除的時候，將會報錯	關閉，noeviction
appendonly	是否開啓AOF，關於AOF後面再說	no
appendfilename	AOF文件名稱	appendonly.aof
appendfsync	操做系統實際寫數據到磁盤的頻率，有如下幾個選項： always，每次有寫操做都進行同步，慢，可是最安全 everysec，對寫操做進行累積，每秒同步一次，是一種折衷方案 no，當操做系統flush緩存的時候同步，性能更好可是會有數據丟失的風險 當不肯定是使用哪一種的時候，官方推薦使用everysec，它是速度與數據安全之間的一種折衷方案	everysec
no-appendfsync-on-rewrite	aof持久化機制有一個致命的問題，隨着時間推移，aof文件會膨脹，當server重啓時嚴重影響數據庫還原時間，所以系統須要按期重寫aof文件。 重寫aof的機制爲bgrewriteaof（另一種被廢棄了，就不說了），即在一個子進程中重寫從而不阻塞主進程對其餘命令的處理，可是這依然有個問題。 bgrewriteaof和主進程寫aof，都會操做磁盤，而bgrewriteaof每每涉及大量磁盤操做，這樣就會讓主進程寫aof文件阻塞。 針對上述問題，可使用此時可使用no-appendfsync-on-rewrite參數作一個選擇： no，最安全，不丟失數據，可是須要忍受阻塞 yes，數據寫入緩衝區，不形成阻塞，可是若是此時redis掛掉就會丟失數據，在Linux操做系統默認設置下，最壞場景下會丟失30秒數據	no
auto-aof-rewrite-percentage	本次aof文件超過上次aof文件該值的百分比時，纔會觸發rewrite	100
auto-aof-rewrite-min-size	aof文件最小值，只有到達這個值纔會觸發rewrite，即rewrite由auto-aof-rewrite-percentage+auto-aof-rewrite-min-size共同保證	64mb
aof-load-truncated	redis在以aof方式恢復數據時，對最後一條可能出問題的指令的處理方式：  yes，log並繼續 no，直接恢復失敗	yes
slowlog-log-slower-than	Redis慢查詢的最低條件，單位微妙，即查詢時間>這個值的會被記錄	10000
slowlog-max-len	Redis存儲的慢查詢最大條數，超過該值以後會將最先的slowlog剔除	128
lua-time-limit	一個lua腳本執行的最大時間，單位爲ms	5000
cluster-enabled	正常來講Redis實例是沒法稱爲集羣的一部分的，只有以集羣方式啓動的節點才能夠。爲了讓Redis以集羣方式啓動，就須要此參數。	關閉
cluster-config-file	每一個集羣節點應該有本身的配置文件，這個文件是不該該手動修改的，它只能被Redis節點建立且更新，每一個Redis集羣節點須要不一樣的集羣配置文件	關閉，nodes-6379.conf
cluster-node-timeout	集羣中一個節點向其餘節點發送ping命令時，必須收到回執的毫秒數	關閉，15000
cluster-slave-validity-factor	若是該項設置爲0，無論Slave節點和Master節點間失聯多久都會一直嘗試failover。 好比timeout爲5，該值爲10，那麼Master與Slave之間失聯50秒，Slave不會去failover它的Master	關閉，10
cluster-migration-barrier	當一個Master擁有多少個好的Slave時就要割讓一個Slave出來。 例如設置爲2，表示當一個Master擁有2個可用的Slave時，它的一個Slave會嘗試遷移	關閉，1
cluster-require-full-coverage	有節點宕機致使16384個Slot所有被覆蓋，整個集羣是否中止服務，這個值必定要改成no	關閉，yes

以上把redis.conf裏面幾乎全部的配置都寫了一遍（除了ADVANCED CONFIG部分），感受其餘博客不多有看到比我這個還全的了^_^，給你們做爲參考吧。

 

Redis性能測試

以前說過Redis在make以後有一個redis-benchmark，這個就是Redis提供用於作性能測試的，它能夠用來模擬N個客戶端同時發出M個請求。首先看一下redis-benchmark自帶的一些參數：

參數	做用	默認值
-h	服務器名稱	127.0.0.1
-p	服務器端口	6379
-s	服務器Socket	無
-c	並行鏈接數	50
-n	請求書	10000
-d	SET/GET值的字節大小	2
-k	1表示keep alive，0表示重連	1
-r	SET/GET/INC使用隨機Key而不是常量，在形式上key樣子爲mykey_ran:000000012456 -r的值決定了value的最大值	無
-p	使用管道請求	1，即不使用管道
-q	安靜模式，只顯示query/sec值	無
--csv	使用csv格式輸出	無
-l	循環，無限運行測試	無
-t	只運行使用逗號分割的命令的測試	無
-I	空閒模式，只打開N個空閒線程而且等待	無

拋開配置只談性能的都是耍流氓，說一下我買的阿里雲服務器的配置：

• 單核CPU，CPU類型爲Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
• 內存4G
• 帶寬1M
• 操做系統爲Centos7

首先咱們運行最簡單的redis-benchmark -q，運行結果爲：

打印了每一個命令的QPS，看到基本都在讀寫速度基本都在100000次/s以上。

接着換一個命令進行測試，由於實際場景中咱們的Key和Value必定是很是豐富的，不多是單一的Key和單一的Value，所以接着去的測試使用-r模擬value到100000且將運行次數提升到1000000次，具體命令爲redis-benchmark -q -r 100000 -n 1000000，運行結果爲：

看到整個讀寫效率基本都在110000次/s以上，證實了讀寫的高效率。

簡單對於Redis的性能測試就到這兒，這個測試結果看起來很美，可是實際應用卻徹底不是，主要體如今如下幾點：

• 網絡與帶寬，這是現實中最主要的影響因素，上面的測試仍是太過於低級，現實使用中Redis裏面存一個用戶信息、訂單信息，幾KB的大小，100000qps根本不可能你們能夠算算須要多大的帶寬，粗粗算一下超過1個G吧，不少線上服務的帶寬根本達不到1G/s，因此Redis的吞吐量最早會被網絡帶寬限制住
• Redis因爲是單線程模型，所以CPU性能很是重要，尤爲是大緩存的快速CPU，我這裏的CPU上面寫過了，Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz整體仍是能夠的
• 客戶端鏈接數，上面使用了默認的鏈接數50，實際上10W、20W甚至100W+呢？不過得益於epoll模型，整個降低的能夠接受，下面有一張鏈接數和qps的關係，我也是網上找來的
• RDB和AOF可能會對Redis形成的阻塞並未考慮進去
• 儘量使用大內存，避免SWAP

不管如何，總而言之，Redis整個性能是很是不錯的，我的認爲若是要選一款存儲系統，那麼Redis應當是首選。