1.事務操作
watch key1 key2//監視key1,key2是否變化
unwtach [key1 key2//取消監視
multi//開啓事務
command
command
...
discard/exec//取消或者提交
注意:如果命令格式有誤,exec會報錯
如果命令格式不錯,只是邏輯錯,exec不執行正確的命令---需要程序員去負責
2.消息的發佈與訂閱
subscribe<------頻道----------publishsubscribe news --訂閱新聞頻道
publish news 內容--發佈新聞內容
適宜做在線聊天,消息推送
SUBSCRIBE channel [channel ...]
訂閱給定的一個或多個頻道的信息。
UNSUBSCRIBE [channel [channel ...]]
指示客戶端退訂給定的頻道。
如果沒有頻道被指定，也即是，一個無參數的 UNSUBSCRIBE 調用被執行，
那麼客戶端使用 SUBSCRIBE 命令訂閱的所有頻道都會被退訂
PUNSUBSCRIBE [pattern [pattern ...]]
指示客戶端退訂所有給定模式。
psubscreibe [pattern [pattern ...]]
//可以指定模式 比如 psubscribe new*等
redis的持久化有兩種方式：1.快照 2.aof
持久化的方式
持久化: 即把數據存儲於斷電後不會丟失的設備中,通常是硬盤.
常見的持久化方式:
主從:通過從服務器保存和持久化,如mongoDB的replication sets配置
日誌:操作生成相關日誌,並通過日誌來恢復數據
couchDB對於數據內容,不修改,只追加,則文件本身就是日誌,不會丟失數據.
redis----RDB快照持久化
rdb的工作原理:
每隔N分鐘或N次寫操作後,
從內存dump數據形成rdb文件,
壓縮
放在備份目錄
redis---參數配置
save 900 1 #刷新快照到硬盤中，必須滿足兩者要求才會觸發，即900秒之後至少1個關鍵字發生變化。
save 300 10 #必須是300秒之後至少10個關鍵字發生變化。
save 60 10000 #必須是60秒之後至少10000個關鍵字發生變化。
stop-writes-on-bgsave-error yes #後臺存儲錯誤停止寫。（主要保持數據的一致性，數據不一致將會導致很嚴重的後果，這個參數主要用於後臺備份進程出錯時,主進程停不停止寫入?）
rdbcompression yes #使用LZF壓縮rdb文件。(可以減小rdb文件的大小)
rdbchecksum yes #存儲和加載rdb文件時校驗。（加校驗保持數據的完整性，當redis重啓導入rdb文件時會做校驗）
dbfilename dump.rdb #設置rdb文件名。
dir ./ #設置工作目錄，rdb文件會寫入該目錄。
rdb的最大缺點是容易丟失數據，如：
在2個保存點之間,斷電,
將會丟失1-N分鐘的數據
但優點也很明顯
出於對持久化的更精細要求,redis增添了aof方式 append only file
1:每個命令重寫一次aof?
2:某key操作100次,產生100行記錄,aof文件會很大,怎麼解決?
aof日誌持久化
appendonly no #是否僅要日誌，是否打開 aof日誌功能
appendfsync no # 系統緩衝,統一寫,速度快，寫入工作交給操作系統,由操作系統判斷緩衝區大小,統一寫入到aof. 同步頻率低,速度快,
appendfsync always # 系統不緩衝,直接寫,慢,丟失數據少，每1個命令,都立即同步到aof. 安全,速度慢
appendfsync everysec #折衷,每秒寫1次
no-appendfsync-on-rewrite no #重寫aof時同步最新數據，正在導出rdb快照的過程中,要不要停止同步aof
auto-AOF-rewrite-percentage 100 當前aof文件是上次重寫是大N%時重寫，aof文件大小比起上次重寫時的大小,增長率100%時,重寫
auto-AOF-rewrite-min-size 64mb aof重寫至少要達到的大小，aof文件,至少超過64M時,重寫
在dump rdb過程中,aof如果停止同步,會不會丟失?
答: 不會,所有的操作緩存在內存的隊列裏, dump完成後,統一操作.
注: aof重寫是指什麼?
答: aof重寫是指把內存中的數據,逆化成命令,寫入到.aof日誌裏.
以解決 aof日誌過大的問題.
問: 如果rdb文件,和aof文件都存在,優先用誰來恢復數據?
答: aof
問: 2種是否可以同時用?
答: 可以,而且推薦這麼做
問: 恢復時rdb和aof哪個恢復的快
答: rdb快,因爲其是數據的內存映射,直接載入到內存,而aof是命令,需要逐條執行
redis 服務器端命令
redis 127.0.0.1:6380> time ,顯示服務器時間 , 時間戳(秒), 微秒數
1) "1375270361"
2) "504511"
redis 127.0.0.1:6380> dbsize // 當前數據庫的key的數量
(integer) 2
redis 127.0.0.1:6380> select 2
OK
redis 127.0.0.1:6380[2]> dbsize
(integer) 0
redis 127.0.0.1:6380[2]>
BGREWRITEAOF 後臺進程重寫AOF
BGSAVE 後臺保存rdb快照
SAVE 保存rdb快照
LASTSAVE 上次保存時間
Slaveof master-Host port , 把當前實例設爲master的slave
Flushall 清空所有庫所有鍵
Flushdb 清空當前庫所有鍵
Showdown [save/nosave]
注: 如果不小心運行了flushall, 立即 shutdown nosave ,關閉服務器
然後 手工編輯aof文件, 去掉文件中的 “flushall ”相關行, 然後開啓服務器,就可以導入回原來數據.
如果,flushall之後,系統恰好bgrewriteaof了,那麼aof就清空了,數據丟失.
Slowlog 顯示慢查詢
注:多慢才叫慢?
答: 由slowlog-log-slower-than 10000 ,來指定,(單位是微秒)
服務器儲存多少條慢查詢的記錄?
答: 由 slowlog-max-len 128 ,來做限制
Info [Replication/CPU/Memory..]
查看redis服務器的信息
Config get 配置項
Config set 配置項 值 (特殊的選項,不允許用此命令設置,如slave-of, 需要用單獨的slaveof命令來設置)
Redis運維時需要注意的參數
1: 內存
Memory
used_memory:859192 數據結構的空間
used_memory_rss:7634944 實佔空間
mem_fragmentation_ratio:8.89 前2者的比例,1.N爲佳,如果此值過大,說明redis的內存的碎片化嚴重,可以導出再導入一次.
2: 主從複製
Replication
role:slave
master_host:192.168.1.128
master_port:6379
master_link_status:up
3:持久化
Persistence
rdb_changes_since_last_save:0
rdb_last_save_time:1375224063
4: fork耗時
#Status
latest_fork_usec:936 上次導出rdb快照,持久化花費微秒
注意: 如果某實例有10G內容,導出需要2分鐘,
每分鐘寫入10000次,導致不斷的rdb導出,磁盤始處於高IO狀態.
5: 慢日誌
config get/set slowlog-log-slower-than
CONFIG get/SET slowlog-max-len
slowlog get N 獲取慢日誌
運行時更改master-slave
修改一臺slave(設爲A)爲new master
1)命令該服務不做其他redis服務的slave
命令: slaveof no one
2)修改其readonly爲yes
其他的slave再指向new master A
1)命令該服務爲new master A的slave
命令格式 slaveof IP port
集羣的作用
1: 主從備份 防止主機宕機
2: 讀寫分離,分擔master的任務
3: 任務分離,如從服分別分擔備份工作與計算工作
master master-slave1-slave2
| \
slave1 slave2
這是兩種主從模式
第一種：當master宕機後由slave1接管，然後修改slave2指向slave1
第2種方式的好處:
master宕機後,
可以直接切換到slave1
Sentinel不斷與master通信,獲取master的slave信息.
監聽master與slave的狀態
如果某slave失效,直接通知master去除該slave.
如果master失效,,是按照slave優先級(可配置), 選取1個slave做 new master
,把其他slave--> new master
疑問: sentinel與master通信,如果某次因爲master IO操作頻繁,導致超時,
此時,認爲master失效,很武斷.
解決: sentnel允許多個實例看守1個master, 當N臺(N可設置)sentinel都認爲master失效,才正式失效.
Sentinel選項配置
port 26379 # 端口
sentinel monitor mymaster 127.0.0.1 6379 2 ,
給主機起的名字(不重即可),
當2個sentinel實例都認爲master失效時,正式失效
sentinel down-after-milliseconds mymaster 30000 多少毫秒後連接不到master認爲斷開
sentinel can-failover mymaster yes #是否允許sentinel修改slave->master. 如爲no,則只能監控,無權修改./
sentinel parallel-syncs mymaster 1 , 一次性修改幾個slave指向新的new master.
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh ,# 在重新配置new master,new slave過程,可以觸發的腳本
注意：當一個master啓動後會自動同步slave,先dump rdb,在緩衝aof,一次同步最好不要多個來避免master io飆升！
缺陷:每次salave斷開後,(無論是主動斷開,還是網絡故障)
再連接master
都要master全部dump出來rdb,再aof,即同步的過程都要重新執行1遍.
所以要記住---多臺slave不要一下都啓動起來,否則master可能IO劇增
具體例子：
sentinel monitor def_master 127.0.0.1 6379 2
sentinel auth-pass def_master 012_345^678-90
##master被當前sentinel實例認定爲“失效”的間隔時間
##如果當前sentinel與master直接的通訊中，在指定時間內沒有響應或者響應錯誤代碼，那麼
##當前sentinel就認爲master失效(SDOWN，“主觀”失效)
##<mastername> <millseconds>
##默認爲30秒
sentinel down-after-milliseconds def_master 30000
##當前sentinel實例是否允許實施“failover”(故障轉移)
##no表示當前sentinel爲“觀察者”(只參與"投票".不參與實施failover)，
##全局中至少有一個爲yes
sentinel can-failover def_master yes
##sentinel notification-script mymaster /var/redis/notify.sh