上文《詳細講解redis數據結構(內存模型)以及經常使用命令》介紹了redis的數據類型以及經常使用命令,本文咱們來學習下redis的一些高級特性。html
redis安裝好後,默認狀況下登錄客戶端和使用命令操做時不須要密碼的。某些狀況下,爲了安全起見,咱們能夠設置在客戶端鏈接後進行任何操做以前都要進行密碼驗證。修改redis.conf進行配置。redis
[root@localhost ~]# vi /usr/local/redis/etc/redis.conf數據庫
#######################SECURITY ##############################緩存
......安全
# Warning: since Redis is pretty fast an outside user can try up to服務器
# 150k passwords per second against a good box. This means that you should數據結構
# use a very strong password otherwise it will be very easy to break.多線程
#app
# requirepass foobared異步
requirepass redis129
# Command renaming.
如上,找到# requirepass foobared這一行,在下面添加「requirepass 密碼」一行設置密碼。設置好密碼後,有兩種方式受權客戶端進行操做。
(1)登陸時使用-a參數指定客戶端密碼,以下
[root@localhost ~]# /usr/local/redis/bin/redis-cli -h 192.168.2.129 -p 6379 -a redis129
192.168.2.129:6379> keys *
1) "myzset"
192.168.2.129:6379>
(2)登陸客戶端後使用auth命令進行受權,以下
[root@localhost ~]# /usr/local/redis/bin/redis-cli -h 192.168.2.129 -p 6379
192.168.2.129:6379> keys *
(error) NOAUTH Authentication required.
192.168.2.129:6379> auth redis129
OK
192.168.2.129:6379> keys *
1) "myzset"
192.168.2.129:6379>
主從複製,即主服務器與從服務器之間數據備份的問題。Redis 支持簡單且易用的主從複製(master-slave replication)功能, 該功能可讓從服務器(slave server)成爲主服務器(master server)的精確複製品。
(1)一個主服務器能夠有多個從服務器。
(2)不只主服務器能夠有從服務器, 從服務器也能夠有本身的從服務器。
(3)Redis 支持異步複製和部分複製(這兩個特性從Redis 2.8開始),主從複製過程不會阻塞主服務器和從服務器。
(4)主從複製功能能夠提高系統的伸縮性和功能,如讓多個從服務器處理只讀命令,使用複製功能來讓主服務器免於頻繁的執行持久化操做。
下面咱們用一個圖來說解redis主從複製的過程。
Redis主從複製過程示意圖
從上面的示意圖能夠看出,主服務器與從服務器創建鏈接以後,Redis主從複製過程主要有下面幾步:
(1)從服務器都將向主服務器發送一個 SYNC 命令。
(2)主服務器接到 SYNC 命令後開啓一個後臺子進程並開始執行 BGSAVE,並在保存操做執行期間, 將全部新執行的寫入命令都保存到一個緩衝區裏面。
(3)當 BGSAVE 執行完畢後, 主服務器將執行保存操做所得的 .rdb 文件發送給從服務器, 從服務器接收這個 .rdb 文件, 並將文件中的數據載入到內存中。
(4)主服務器會以 Redis 命令協議的格式, 將寫命令緩衝區中積累的全部內容都發送給從服務器。
redis配置一個從服務器很是簡單, 只要在從服務器的配置文件redis.conf中增長主服務器的IP地址和端口號就能夠,若是主服務器設置了客戶端密碼,還須要在從服務器中配置主服務器的密碼,以下
##########################REPLICATION ###############################
# Master-Slave replication. Use slaveof to make a Redis instance a copy of
# another Redis server. A few things to understand ASAP about Redis replication.
#
......
# slaveof <masterip> <masterport>
slaveof 192.168.2.129 6379
# If the master is password protected (using the "requirepass" configuration
# directive below) it is possible to tell the slave to authenticate before
# starting the replication synchronization process, otherwise the master will
# refuse the slave request.
#
# masterauth <master-password>
masterauth redis129
Redis 的事務支持相對簡單,MULTI 、 EXEC 、 DISCARD 和 WATCH 這四個命令是 Redis 事務的基礎。
l MULTI 開啓一個事務。當客戶端發出了MULTI 命令時,客戶端和服務端的鏈接就進入了一個事務上下文的狀態。MULTI 執行以後, 客戶端能夠繼續向服務器發送任意多條命令, 這些命令不會當即被執行, 而是被放到一個隊列中, 當 EXEC 命令被調用時, 全部隊列中的命令纔會被執行。
l EXEC 順序執行事務隊列中的命令。
192.168.2.129:6379> multi
OK
192.168.2.129:6379> set name "zhangsan"
QUEUED
192.168.2.129:6379> set age 20
QUEUED
192.168.2.129:6379> exec
1) OK
2) OK
192.168.2.129:6379> keys *
1) "age"
2) "name"
192.168.2.129:6379>
l DISCARD 取消事務。當執行 DISCARD 命令時, 事務會被放棄, 事務隊列會被清空, 而且客戶端會從事務狀態中退出。
192.168.2.129:6379> multi
OK
192.168.2.129:6379> set name2 "lisi"
QUEUED
192.168.2.129:6379> set age 22
QUEUED
192.168.2.129:6379> discard
OK
192.168.2.129:6379> exec
(error) ERR EXEC without MULTI
192.168.2.129:6379>
l WATCH 對key值進行鎖操做。 在 WATCH 執行以後, EXEC 執行以前, 有其餘客戶端修改了 key 的值, 那麼當前客戶端的事務就會失敗。以下:
Client1開啓watch name並在事務中修改name,可是沒有執行exec
192.168.2.129:6379> get name
"huangliu"
192.168.2.129:6379> watch name
OK
192.168.2.129:6379> multi
OK
192.168.2.129:6379> set name lisi
QUEUED
Client2 修改name
192.168.2.129:6379> get name
"huangliu"
192.168.2.129:6379> set name "wangwu"
OK
192.168.2.129:6379> get name
"wangwu"
192.168.2.129:6379>
Client1執行exec
192.168.2.129:6379> exec
(nil)
192.168.2.129:6379>
可見,因爲被watch的name已經被Client2 修改,因此Client1的事務執行失敗,程序須要作的, 就是不斷重試這個操做, 直到沒有發生碰撞(Crash)爲止。對key進行加鎖監視的機制相似Java多線程中的鎖(synchronized中的監視器對象),被稱做樂觀鎖。樂觀是一種很是強大的鎖機制,後面咱們會進一步學習redis的分佈式鎖。
前面咱們已經說過,既能夠把redis理解爲緩存技術,也能夠理解爲數據庫,由於redis支持將內存中的數據週期性的寫入磁盤或者把操做追加到記錄文件中,這個過程稱爲redis的持久化。redis支持兩種方式的持久化,一種是快照方式(snapshotting),也稱RDB方式;兩一種是追加文件方式(append-only file),也稱AOF方式。RDB方式是redis默認的持久化方式。
RDB方式是將內存中的數據的快照以二進制的方式寫入名字爲 dump.rdb的文件中。咱們對 Redis 進行設置, 讓它根據設置週期性自動保存數據集。修改redis.conf文件,以下
######################### SNAPSHOTTING ################################
#
# Save the DB on disk:
......
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
#
# Note: you can disable saving completely by commenting out all "save" lines.
#
# It is also possible to remove all the previously configured save
# points by adding a save directive with a single empty string argument
# like in the following example:
#
# save ""
#900秒內若是有超過1個key被修改則發起保存快照
save 900 1
#300秒內若是有超過10個key被修改則發起保存快照
save 300 10
#60秒內若是有超過1000個key被修改則發起保存快照
save 60 10000
dump.rdb文件默認生成在%REDIS_HOME%etc目錄下(如/usr/local/redis/etc/),能夠修改redis.conf文件中的dir指定dump.rdb的保存路徑
# The filename where to dump the DB
dbfilename dump.rdb
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./
RDB方式是週期性的持久化數據, 若是未到持久化時間點,Redis 由於某些緣由而形成故障停機, 那麼服務器將丟失最近寫入、且仍未保存到快照中的那些數據。因此從redis 1.1開始引入了AOF方式,AOF 持久化記錄服務器執行的全部寫操做命令,並在服務器啓動時,經過從新執行這些命令來還原數據集。 AOF 文件中的命令所有以 Redis 協議的格式來保存,新命令會被追加到文件的末尾。
AOF方式仍然有丟失數據的可能,由於收到寫命令後可能並不會立刻將寫命令寫入磁盤,所以咱們能夠修改redis.conf,配置redis調用write函數寫入命令到文件中的時機。以下
#######################APPEND ONLY MODE #############################
......
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.
#啓用AOF方式
appendonly yes
#每次有新命令追加到 AOF 文件時就執行一次 fsync :很是慢,也很是安全
#每秒 fsync 一次:足夠快(和使用 RDB 持久化差很少),而且在故障時只會丟失 1 秒鐘的數據
appendfsync everysec
#從不 fsync :將數據交給操做系統來處理。更快,也更不安全的選擇
appendfsync no
從上面三種AOF持久化時機來看,爲了保證不丟失數據,appendfsync always是最安全的。
Redis的發佈以及訂閱有點相似於聊天,是一種消息通訊模式。在這個模式中,發送者(發送信息的客戶端)不是將信息直接發送給特定的接收者(接收信息的客戶端), 而是將信息發送給頻道(channel), 而後由頻道將信息轉發給全部對這個頻道感興趣的訂閱者。SUBSCRIBE 、 UNSUBSCRIBE 和 PUBLISH 三個命令實現了消息的發佈與訂閱。以下
Client1發佈頻道mychannel與消息
192.168.2.129:6379> publish mychannel "message from channel1"
(integer) 1
192.168.2.129:6379>
Client2 訂閱頻道mychannel並接受Client1經過頻道發過來的消息
192.168.2.129:6379> subscribe mychannel
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "mychannel"
3) (integer) 1
1) "message"
2) "mychannel"
3) "message from channel1"
至此,redis的客戶端安全性設置、主從複製、事務與鎖、持久化機制以及發佈與訂閱消息主要內容介紹完畢。下一篇咱們將繼續學習redis的集羣。
參考文檔
http://redis.io/documentation
http://redisdoc.com/