Redis 知識 整理

• 簡介
  • 安裝
  • 啓動
  • 注意事項
• 使用命令
  • 通用命令
  • 數據結構
    • 字符串(string)
    • 哈希(hash)
    • 隊列(list)
    • 集合(set)
    • 有序集合(zset)
    • 位圖(bitcount)
  • 事務
  • 訂閱與發佈
• 配置
  • Units(單位)
  • INCLUDES(模塊)
  • GENERAL(經常使用項)
  • SNAPSHOTING(RDB相關)
  • REPLICATION(主從複製)
  • SECURITY(安全)
  • LIMITS(限制策略)
  • APPEND ONLY MODE(AOF相關)
  • LUA SCRIPTING(Lua腳本)
  • REDIS CLUSTER(集羣)
  • SLOW LOG(慢查詢日誌)
  • LATENCY MONITOR(延遲監控)
  • EVENT NOTIFICATION(事件訂閱)
  • ADVANCED CONFIG(高級配置)
  • VIRTUAL MEMORY(虛擬內存)
• 場景分析
  • 設置密碼
  • 遠程鏈接
  • 持久化
    • RDB
    • AOF
  • 主從複製
  • 集羣
  • 訂閱發佈
    • 普通訂閱
    • 模式訂閱

簡介

redis全稱remote dictionary server(遠程字典服務器）
redis是NoSQL（No Only SQL，非關係型數據庫）的一種，NoSQL是以Key-Value的形式存儲數據。當前主流的分佈式緩存技術有redis,memcached,ssdb,mongodb等。
既能夠把redis理解爲理解爲緩存技術，由於它的數據都是緩存在內從中的；
也能夠理解爲數據庫，由於redis能夠週期性的將數據寫入磁盤或者把操做追加到記錄文件中。
而我我的更傾向理解爲緩存技術，由於當今互聯網應用業務複雜、高併發、大數據的特性，正是各類緩存技術引入最終目的

問:redis這貨憑什麼能取代memcached?
1.支持的value類型相對於memcached更多。
2.支持持久化
　redis數據存儲在內存，會週期性地寫入到磁盤。memcached則不會

問:自己程序的數據就是存儲在內存裏，爲何用redis？
1.自身程序裏的數據不能序列化
2.自身數據的讀取不是原子性
　由於redis是單進程單線程，之因此很快是由於底層用了io多路複用（epoll）
3.利於不一樣語言的後端程序間通信

安裝

 通常來講，開發者只須要本機使用包管理工具(apt,brew)下載便可。
但若想使用編譯源碼安裝這一方式，點擊這裏

啓動 

- 配置後臺啓動

daemonize no ---- >daemonize yes
bind 127.0.0.1 ---> bind 0.0.0.0 

- 啓動redis服務端

redis-server /usr/local/etc/redis.conf

- 驗證服務端是否啓動成功

ps -ef | grep redis
netstat -tunpl | grep 6379

- 客戶端鏈接

/usr/local/redis/bin/redis-cli -h 192.168.2.128 -p 6379

# /usr/local/redis/bin/redis-cli -h 192.168.2.129 -p 6379 -a 12345

 

- 中止redis服務端

/usr/local/redis/bin/redis-cli shutdown
#或者
pkill redis-server

注意事項

 

使用命令

命令手冊

通用命令

select 1 # 切換到數據庫1,範圍是0~15。redis只能有16個db，不一樣mysql（mysql的database能夠有無數個）
help set # 查看set到幫助信息
save # 手動持久化
flushdb # 清空當前庫
flushall #16個庫的數據全刪了
dbsize # 看看有多少個值
info # 各個庫的鍵值狀況

keys * # 查看全部鍵，這是運維禁忌
keys z*，keys k？ # 通配符匹配

exists key1 # 判斷key1是否存在
move key1 2 # 將key1從當前數據庫移動到2號數據庫
expire key1 60 # 將key1設置爲60秒後過時
ttl key1 # 查看key1還有多少秒過時
type key1 # 看看key1是什麼類型
del key1 #刪掉
rename k1 k2 # 更名

數據結構

相關原理

字符串(string)

string類型是二進制安全的，意思是能夠包含任何數據，好比jpg圖片或者序列化的對象。字符串value最可能是512M

增
set k1 ‘ddd’ ex 3 # 設置3秒以後過時
setex k1 3 'ddd' # 同上，set with expire
set k1 'ddd' NX # 和字典的setdefault效果同樣
setnx k1 ddd # 同上，set if not exist
set love ‘ddd' XX # 只有love這個key存在時這條命令才生效
getset k1 fuck # 先get再set

mset apple 12000 xiaomi 2000 oppo 3300 # 批量設置，{'apple':12000,'xiaomi':2000,'oppo':3300}
msetnx apple 12000 xiaomi 2000 # 只要有一個鍵存在，全體跪
 查
get k1 
strlen k1 # 返回k1字符串的長度，注意是字節長度（漢字是三個字節）
 切片
getrange k1 0 -1 #切片
setrange k1 0 xxxxx # 這個注意，0表明設置字符的位置，多餘的字符會覆蓋掉後續已經存在的字符
 數字加減
incr count # count爲數字類型的字符串變量，count++
decr count # count--
incrby count 20 # count+=20
decyby count 20 # count-=20

哈希(hash)

value是一個小字典，經常使用於存儲一個對象的詳細信息。例如存儲用戶的具體信息等
若嵌套的話，API方法會幫你將列表，字典轉化爲字符串，不管遞歸到多深也不怕

增
hset info a 1 # {'info'：{'a':1}}
hmset info a 1 b 2 # {'info'：{'a':1,'b':2}},其實hset就能夠批量設置
hsetnx info a 1 # set if not exist
 查
hgetall info # 獲取hash的鍵值對元組
hkeys info # 取出全部鍵
hvals info # 取出全部值

hget info a  # {'info'：{'a':1,'b':2}},取value裏面a鍵對應的值
hmget info a b # 批量取
 刪
hdel info a # 刪除info裏面的a
 數字操做
hincrby info age 2 # 將age對應的value加2
hincrbyfloat info price 2.5 將price對應的value加2.5 通配符匹配指定key 
hscan info 0 match e* # 0表明全局匹配

隊列(list)

value是一個列表,底層實際上是雙向鏈表，有lpush，rpush
性能的話，因爲是鏈表，頭尾性能高，中間插入性能低

增
lpush li a b c # {'li':['a','b','c']}
rpush li a # right push
rpoplpush 源列表 目的列表 # 將源列表的右邊的(rpop)彈出的值，lpush進新的列表
 刪
lpop # 左邊彈出
rpop # 右邊彈出
lrem li 2 3 # 刪除2個'3'
 查
lindex li 1 # 取出li[1]
llen li # 長度
 改
lset li 0 ff # li[0]='ff'
linsert li before/after a aa # 在元素a以前(以後)插入aa，注意，這裏用的不是索引值而是元素 切片
lrange li 0 -1 # 範圍取值
ltrim key1 0 3 # 截取索引位置0～3多範圍的值賦值給key1
 數字操做
hincrby info age 2 # 將age對應的value加2
hincrbyfloat info price 2.5 將price對應的value加2.5 通配符匹配指定key 
hscan info 0 match e* # 0表明全局匹配

 

集合(set)

value是一個set

增
sadd s 1 2 2 3 3 4 # {'s':{'1','2','3','4'}}
smove s1 s2 val_of_s1 # 將s1中的val的val_of_s1移動到s2
 查
smembers s # 取出s的全部值
scard s1 # 得到s1集合裏面元素個數
sismember s1 2 # 判斷2是否爲s1的元素
 刪
srem s1 fuck # 刪除s1中的fuck
srandmember s1 2 # 隨機從s1刪除2個元素
spop key # 隨機刪除一個元素
 集合操做
sdiff s1 s2 #差集 ，即s1-s2 ，s1有的，s2沒有
sinter s1 s2 #交集 
sunion s1 s2 #並集

有序集合(zset)

有序集合，按照指定的權重進行排序

增
zadd s1 60 v1 80 v2 100 v3 #數字是權重（計算機術語中score表明的是權重）
 查
zcard s1 #返回val的數目
zcount s1 60 80 #統計權重60到80之間的數目
zrank s1 v3 #返回v3的下標,注意是相似數組的順序
zrevrank s1 v3 # 逆序返回v3的下標
zscore s1 v3 #返回v3的權重值

zrange s1 0 -1  withscores # 顯示權重
zrange s1 0 -1 # 只顯示值，不顯示權重。注意:0，-1是下標範圍。不是像mysql limit同樣的參數
zrevrange s1 0 -1 # 只顯示值，不顯示權重。注意:0，-1是下標範圍。

zrevrangebyscore s1 90 20 # 逆向顯示權重範圍的，注意參數1要大於參數2
zrangebyscore s1 60 80 # 顯示指定權重範圍的
zrangebyscore s1 (60 (80 # '('爲不包含
zrangebyscore s1 60 80 limit 2 2 #相似於mysql數據庫

zrevrangebyscore s1 90 60 #因爲是反轉，權重是90到60
 刪
zrem s1 v3 #刪除v3

 

位圖(bitcount)

 二進制變量，經常使用於位計數法，節省內存

bitcount usercount # 定義
setbit usercount 999 1 # 設置bitcount 第999位爲1,
getbit usercount 22 # 獲取第22位的值（0或1）
bitcount usercount # usercount裏1的個數

事務

redis事務能夠一次執行一組命令的集合，按順序地執行而不會被其餘命令插入。
redis會將命令集合中的命令依次塞入一個執行隊列。
當使用exec命令時，要麼一次性成功，要麼所有失敗（語法等嚴重錯誤），但若像incr username這種命令，運行時會報錯可是其餘命令得以正常執行（運行時異常）

問：redis不是單線程的嗎，應該不用擔憂數據競爭問題，爲啥還要搞事務？
原本redis就是單線程的io多路複用，按道理說不該該考慮事務問題。
問題是在於，對於單一命令是不用考慮，可是對於一組命令要保證正確執行，就得作成事務。
若一個一個分散執行，結果極可能不如人意

問：爲啥說redis對事務是部分支持？
1.不能回滾
當事務若是在執行過程當中有一條命令出異常(不是嚴重錯誤），其後的命令仍然會被執行，不會回滾
2.雖然說有隔離性。可是沒有隔離級別概念
事務在執行過程當中，不會被其餘客戶端發送過來的命令請求所打斷，由於事務提交前任何指令都不會被實際地執行，也就不存在「事務內的查詢要看到事務裏的更新，在事務外查詢不能看到」這個頭疼的問題

正常執行 1. multi
2. XXXXX命令
3. exec 放棄執行
multi
XXXXX命令
discard  #發現xxxx命令，我寫入了不想執行的命令
 watch 監控 # redis的樂觀鎖，若watch以後有任何key發生了變化，exec命令執行的事務都會被放棄，同時返回Nullmult-bulk應答以通知調用者事務執行失敗
1. watch account # 盯着數據別讓它改
2. multi
3. XXXXX命令
4. exec # account有人改了，返回nil。注意：一旦執行了exec以前watch鎖都會被取消掉
5. unwatch # 取消對全部key的監控
6.從1 開始從頭來過

訂閱與發佈

先說說消息中間件這個概念。進程間的一種消息通訊模式:發送者發送消息，訂閱者接收消息。經常使用於解藕
這個比RabbitQ簡單不少，沒有亂七八糟的交換機過濾啊，沒有什麼消息的持久化和確認性等待機制
這個就是，發佈，你在線就收到，不在線就收不到
因此，redis能夠作消息中間件，可是企業裏面消息中間件確定不是用它作

subscribe c1,c2 c3 # 一次性訂閱c1,c2,c3三個頻道
publish c2 deep_dark_fantasity # 在c2頻道發佈消息

psubscribe c* # 使用通配符訂閱多個頻道

配置

redis默認配置文件，點這裏

Units(單位)

Units單位指明裏面的1K、1G等指的是大小，並且是大小寫敏感

INCLUDES(模塊)

INCLUDES能夠引入其餘被分拆的配置文件

GENERAL(經常使用項)

# 默認狀況下 redis 不是做爲守護進程運行的，若是你想讓它在後臺運行，你就把它改爲 yes。
# 當redis做爲守護進程運行的時候，它會寫一個 pid 到 /var/run/redis.pid 文件裏面,該文件能夠經過pidfile制定
daemonize yes

# 當 Redis 以守護進程的方式運行的時候，Redis 默認會把 pid 文件放在/var/run/redis.pid
# 注意:當運行多個 redis 服務時，須要指定不一樣的 pid 文件和端口
# 指定存儲Redis進程號的文件路徑
pidfile /var/run/redis.pid

# 端口，默認端口是6379，生產環境中建議更改端口號，安全性更高
# 若是你設爲 0 ，redis 將不在 socket 上監放任何客戶端鏈接。
port 6379

# TCP 監聽的最大容納數量,此參數肯定了TCP鏈接中已完成隊列(完成三次握手以後)的長度，
# 當系統併發量大而且客戶端速度緩慢的時候，你須要把這個值調高以免客戶端鏈接緩慢的問題。
# Linux 內核會一言不發的把這個值縮小成 /proc/sys/net/core/somaxconn 對應的值，默認是511，而Linux的默認參數值是128。因此能夠將這二個參數一塊兒參考設定，你以便達到你的預期。
tcp-backlog 511

# 有時候爲了安全起見，redis通常都是監聽127.0.0.1 可是有時候又有同網段能鏈接的需求，固然能夠綁定0.0.0.0 用iptables來控制訪問權限，或者設置redis訪問密碼來保證數據安全
# 不設置將處理全部請求,建議生產環境中設置，有個誤區：bind是用來限制外網IP訪問的，其實不是，限制外網ip訪問能夠經過iptables；如：-A INPUT -s 10.10.1.0/24 -p tcp -m state --state NEW -m tcp --dport 9966 -j ACCEPT ；
# 實際上，bind ip 綁定的是redis所在服務器網卡的ip，固然127.0.0.1也是能夠的
#若是綁定一個外網ip，就會報錯：Creating Server TCP listening socket xxx.xxx.xxx.xxx:9966: bind: Cannot assign requested address
# bind 192.168.1.100 10.0.0.1

# 當客戶端閒置多少時間後關閉其鏈接，默認是0，表示永不超時。
timeout 0

# tcp 心跳包。
# 若是設置爲非零，則在與客戶端缺少通信的時候使用 SO_KEEPALIVE 發送 tcp acks 給客戶端。
# 這個之全部有用，主要由兩個緣由：
# 1) 防止死的 peers
# 2) Take the connection alive from the point of view of network
#    equipment in the middle.
#
# 推薦一個合理的值就是60秒
tcp-keepalive 0


# 日誌記錄等級，4個可選值debug,verbose,notice,warning
# 能夠是下面的這些值：
# debug (適用於開發或測試階段)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (適用於生產環境)
# warning (僅僅一些重要的消息被記錄)
# 默認爲verbose
loglevel notice

#配置 log 文件地址,默認打印在命令行終端的窗口上，也可設爲/dev/null屏蔽日誌
#若配置redis爲守護進程方式運行，而這裏又配置爲日誌記錄爲標準輸出，則日誌將會發送給/dev/null
logfile "/data/logs/redis/redis.log"

# 要想把日誌記錄到系統日誌，就把它改爲 yes，
# syslog-enabled no

# 設置 syslog 的 identity（標識）。
# syslog-ident redis

# Specify the syslog facility. Must be USER or between LOCAL0-LOCAL7.
# syslog-facility local0

# 可用的數據庫數，默認值爲16，默認數據庫爲0，數據庫範圍在0-（database-1）之間
databases 16

 

SNAPSHOTING(RDB相關)

# 在 900 秒內最少有 1 個 key 被改動，或者 300 秒內最少有 10 個 key 被改動，又或者 60 秒內最少有 1000 個 key 被改動，以上三個條件隨便知足一個，就觸發一次保存操做。

#    if(在60秒以內有10000個keys發生變化時){
#      進行鏡像備份
#    }else if(在300秒以內有10個keys發生了變化){
#      進行鏡像備份
#    }else if(在900秒以內有1個keys發生了變化){
#      進行鏡像備份
#    }

save 900 1
save 300 10
save 60 10000

# 默認狀況下，若是 redis 最後一次的後臺保存失敗，redis 將中止接受寫操做，
# 這樣以一種強硬的方式讓用戶知道數據不能正確的持久化到磁盤，不然就會沒人注意到災難的發生。若是後臺保存進程從新啓動工做了，redis 也將自動的容許寫操做。
# 然而你要是安裝了靠譜的監控，你可能不但願 redis 這樣作，那你就改爲 no 好
stop-writes-on-bgsave-error yes

# 指定存儲至本地數據庫時是否壓縮數據，默認爲yes，Redis採用LZF壓縮，若是爲了節省CPU時間，能夠關閉改選項，但會致使數據庫文件變得巨大
# 默認設爲 yes
rdbcompression yes

# 讀取和寫入的時候是否支持CRC64校驗，默認是開啓的
rdbchecksum yes

# 備份文件的文件名，默認爲dump.rdb
dbfilename dump.rdb

# 數據庫備份的文件放置的路徑
# 路徑跟文件名分開配置是由於 Redis 備份時，先會將當前數據庫的狀態寫入到一個臨時文件
# 等備份完成時，再把該臨時文件替換爲上面所指定的文件
# 而臨時文件和上面所配置的備份文件都會放在這個指定的路徑當中,換句話說。這個配置項也關乎臨時文件的存放位置
# 默認值爲 ./
# dir ./
dir /data/redis/

 

REPLICATION(主從複製)

# 設置該數據庫爲其餘數據庫的slave數據庫時，設置master服務的IP及端口，在redis啓動時，它會自動從master進行數據同步
# slaveof <masterip> <masterport>

# 當master服務設置了密碼保護時，slave服務鏈接的master的密碼
# masterauth <master-password>

# 當slave服務器和master服務器失去鏈接後，或者當數據正在複製傳輸的時候，若是此參數值設置「yes」，slave服務器能夠繼續接受客戶端的請求，不然，會返回給請求的客戶端以下信息「SYNC with master in progress」,除了INFO，SLAVEOF這兩個命令
slave-serve-stale-data yes


# 是否容許slave服務器節點只提供讀服務
slave-read-only yes

# Slaves 在一個預約義的時間間隔內發送 ping 命令到 server。你能夠改變這個時間間隔。默認爲 10 秒。
# repl-ping-slave-period 10


# 設置主從複製過時時間
# 這個值必定要比 repl-ping-slave-period 大
# repl-timeout 60

# 指定向slave同步數據時，是否禁用socket的NO_DELAY選 項。若配置爲「yes」，則禁用NO_DELAY，則TCP協議棧會合並小包統一發送，這樣能夠減小主從節點間的包數量並節省帶寬，但會增長數據同步到slave的時間。若配置爲「no」，代表啓用NO_DELAY，則TCP協議棧不會延遲小包的發送時機，這樣數據同步的延時會減小，但須要更大的帶寬。 一般狀況下，應該配置爲no以下降同步延時，但在主從節點間網絡負載已經很高的狀況下，能夠配置爲yes。
repl-disable-tcp-nodelay no

# 設置主從複製容量大小。這個 backlog 是一個用來在 slaves 被斷開鏈接時存放 slave 數據的 buffer，因此當一個 slave 想要從新鏈接，一般不但願所有從新同步，只是部分同步就夠了，即僅僅傳遞 slave 在斷開鏈接時丟失的這部分數據。這個值越大，salve 能夠斷開鏈接的時間就越長。
# repl-backlog-size 1mb

# 在某些時候，master 再也不鏈接 slaves，backlog 將被釋放。若是設置爲 0 ，意味着毫不釋放 backlog 。
# repl-backlog-ttl 3600


# 指定slave的優先級。在不僅1個slave存在的部署環境下，當master宕機時，Redis Sentinel會將priority值最小的slave提高爲master。這個值越小，就越會被優先選中
# 須要注意的是，若該配置項爲0，則對應的slave永遠不會自動提高爲master。
slave-priority 100

# 若是主服務器超過一秒鐘沒有收到從服務器發來的REPLCONF ACK命令，那麼主服務器就知道主從服務器之間的鏈接出現問題了。
# 經過向主服務器發送INFO replication命令，在列出的從服務器列表的lag一欄中，咱們能夠看到相應從服務器最後一次向主服務器發送REPLCONF ACK命令距離如今過了多少秒：
# 127.0.0.1:6379> INFO replication
# Replication
# role:master
# connected_slaves:2
# slave0:ip=127.0.0.1,port=12345,state=online,offset=211,lag=0  
#剛剛發送過 REPLCONF ACK命令
# slave1:ip=127.0.0.1,port=56789,state=online,offset=197,lag=15   
# 在通常狀況下，lag的值應該在0秒或者1秒之間跳動，若是超過1秒的話，那麼說明主從服務器之間的鏈接出現了故障。


# Redis的min-slaves-to-write和min-slaves-max-lag兩個選項能夠防止主服務器在不安全的狀況下執行寫命令。
# 下面配置的是在從服務器的數量少於3個，或者三個從服務器的延遲（lag）值都大於或等於10秒時，主服務器將拒絕執行寫命令，這裏的延遲值就是上面提到的INFO replication命令的lag值。
# min-slaves-to-write 3
# min-slaves-max-lag 10

 

SECURITY(安全)

# 設置鏈接redis的密碼，默認無密碼
# redis速度至關快，一個外部用戶在一秒鐘進行150K次密碼嘗試，需指定強大的密碼來防止暴力破解
requirepass set_enough_strong_passwd


# 重命名一些高危命令，用來禁止高危命令
rename-command FLUSHALL ZYzv6FOBdwflW2nX
rename-command CONFIG aI7zwm1GDzMMrEi
rename-command EVAL S9UHPKEpSvUJMM
rename-command FLUSHDB D60FPVDJuip7gy6l

 

LIMITS(限制策略)

# 限制同時鏈接的客戶數量,默認是10000。若是設置爲0，表示不做限制
# 當鏈接數超過這個值時，redis 將再也不接收其餘鏈接請求，客戶端嘗試鏈接時將收到 error 信息
# maxclients 10000


# 設置redis最大內存閒置，redis會在啓動時將數據加載到內存中，達到最大內存後，redis會嘗試清除已到期或即將到期的key，此方法護理後，若仍到達最大內存設置，將沒法再進行寫入操做，但仍然能夠進行讀取操做。
# 在刪除時,按照過時時間進行刪除，最先將要被過時的key將最早被刪除
# maxmemory的設置比較適合於把redis看成於相似memcached 的緩存來使用
# maxmemory <bytes>

# 達到最大內存時的緩存清除策略
# volatile-lru -> 使用LRU算法移除key，只對設置了過時時間的鍵
# allkeys-lru -> 使用LRU算法移除key
# volatile-random -> 在設置了過時時間的key中隨機移除，只對設置了過時時間的鍵
# allkeys-random -> 移除隨機的key
# volatile-ttl -> 移除那些ttl最小的key，即移除即將過時的key
# noeviction -> 不進行移除，針對寫操做，只是返回錯誤信息
# maxmemory-policy noeviction

# 設置樣本數量，lru算法和最小ttl算法都並不是是精確的算法，而是估算值。因此你能夠設置樣本的大小。redis默認會檢查這麼多個key並選擇其中lru的那個
# maxmemory-samples 5

 

APPEND ONLY MODE(AOF相關)

# redis 默認狀況下時異步地把數據寫入磁盤，即同步數據文件是按上面save條件來同步的，但若是發生諸如拉閘限電、拔插頭等情況,那麼將形成比較大範圍的數據丟失。並且該備份很是耗時，且備份不宜太頻繁。
# 因此redis提供了另一種更加高效的數據庫備份及災難恢復方式aof
# 開啓append only 模式後,redis 將每一次寫操做請求都追加到appendonly.aof 文件中。redis從新啓動時,會從該文件恢復出以前的狀態。但可能會形成 appendonly.aof 文件過大，因此redis支持BGREWRITEAOF 指令，對appendonly.aof從新整理,默認是不開啓的。
appendonly no

# 指定日誌記錄文件名，默認爲appendonly.aof。
appendfilename "appendonly.aof"

# 設置對 appendonly.aof日誌更新的條件,有三種選擇always、everysec、no，默認是everysec表示每秒同步一次。
# always 表示每次更新後手動滴哦啊用fsync()將數據寫到磁盤(慢，安全）
# no 表示等操做系統進行數據緩存同步到磁盤，都進行同步
# everysec 表示對寫操做進行累積,每秒同步一次（折中）
# appendfsync everysec


# 指定是否在後臺aof文件rewrite期間調用fsync，默認爲no，表示要調用fsync（不管後臺是否有子進程在刷盤）。Redis在後臺寫RDB文件或重寫afo文件期間會存在大量磁盤IO，此時，在某些linux系統中，調用fsync可能會阻塞。
no-appendfsync-on-rewrite yes

# 指定Redis重寫aof文件的條件，默認爲100，表示與上次rewrite的aof文件大小相比，當前aof文件增加量超過上次afo文件大小的100%時，就會觸發background rewrite。若配置爲0，則會禁用自動rewrite
auto-aof-rewrite-percentage 100

# 指定觸發rewrite的aof文件大小。若aof文件小於該值，即便當前文件的增量比例達到auto-aof-rewrite-percentage的配置值，也不會觸發自動rewrite。即這兩個配置項同時知足時，纔會觸發rewrite。
# 生產環境中5G起步
auto-aof-rewrite-min-size 64mb

aof-load-truncated yes

LUA SCRIPTING(Lua腳本)

在redis中可使用eval命令執行lua腳本代碼

       192.168.127.128:6379>eval "return redis.call('set',KEYS[1],ARGV[1])" 1 name liulei
       OK

       192.168.127.128:6379>get name
       "liulei"

 

爲了防止某個腳本執行時間過長致使Redis沒法提供服務（好比陷入死循環），Redis提供了lua-time-limit參數限制腳本的最長運行時間，默認爲5秒鐘。當腳本運行時間超過這一限制後，Redis將開始接受其餘命令但不會執行（以確保腳本的原子性，由於此時腳本並無被終止），而是會返回「BUSY」錯誤

# 一個Lua腳本最長的執行時間，單位爲毫秒，若是爲0或負數表示無限執行時間，默認爲5000
lua-time-limit 5000

 

REDIS CLUSTER(集羣)

# 若是配置yes則開啓集羣功能，此redis實例做爲集羣的一個節點，不然，它是一個普通的單一的redis實例。
cluster-enabled yes

# 雖然此配置的名字叫"集羣配置文件"，可是此配置文件不能人工編輯，它是集羣節點自動維護的文件，主要用於記錄集羣中有哪些節點、他們的狀態以及一些持久化參數等，方便在重啓時恢復這些狀態。一般是在收到請求以後這個文件就會被更新。
cluster-config-file nodes-6379.conf

# 這是集羣中的節點可以失聯的最大時間，超過這個時間，該節點就會被認爲故障。若是主節點超過這個時間仍是不可達，則用它的從節點將啓動故障遷移，升級成主節點。注意，任何一個節點在這個時間以內若是仍是沒有連上大部分的主節點，則此節點將中止接收任何請求。通常設置爲15秒便可。 
cluster-node-timeout 15000

# 若是設置成０，則不管從節點與主節點失聯多久，從節點都會嘗試升級成主節點。若是設置成正數，則cluster-node-timeout乘以cluster-slave-validity-factor獲得的時間，是從節點與主節點失聯後，此從節點數據有效的最長時間，超過這個時間，從節點不會啓動故障遷移。假設cluster-node-timeout=5，cluster-slave-validity-factor=10，則若是從節點跟主節點失聯超過50秒，此從節點不能成爲主節點。注意，若是此參數配置爲非0，將可能出現因爲某主節點失聯卻沒有從節點能頂上的狀況，從而致使集羣不能正常工做，在這種狀況下，只有等到原來的主節點從新迴歸到集羣，集羣才恢復運做。
cluster-slave-validity-factor 10

# 主節點須要的最小從節點數，只有達到這個數，主節點失敗時，它從節點纔會進行遷移。更詳細介紹能夠看本教程後面關於副本遷移到部分。
cluster-migration-barrier 1

# 在部分key所在的節點不可用時，若是此參數設置爲"yes"(默認值), 則整個集羣中止接受操做；若是此參數設置爲」no」，則集羣依然爲可達節點上的key提供讀操做。
cluster-require-full-coverage yes

 

SLOW LOG(慢查詢日誌)

redis的slowlog是redis用於記錄記錄慢查詢執行時間的日誌系統。因爲slowlog只保存在內存中，所以slowlog的效率很高，徹底不用擔憂會影響到redis的性能

# slowlog-log-slower-than表示slowlog的劃定界限，只有query執行時間大於slowlog-log-slower-than的纔會定義成慢查詢，纔會被slowlog進行記錄。slowlog-log-slower-than設置的單位是微妙，默認是10000微妙，也就是10ms 
slowlog-log-slower-than 10000


# slowlog-max-len表示慢查詢最大的條數，當slowlog超過設定的最大值後，會將最先的slowlog刪除，是個FIFO隊列
slowlog-max-len 128

LATENCY MONITOR(延遲監控)

能夠幫助咱們檢查和排查引發延遲的緣由。

redis的slowlog在2.2.12版本引入，latency monitor在2.8.13版本引入。slowlog僅僅是記錄純命令的執行耗時，不包括與客戶端的IO交互及redis的fork等耗時
latency monitor監控的latency spikes則範圍廣一點，監控事件的分類：

事件	事件內容	命令	詳解
command	慢命令	latency history command	執行時長超過 latency-monitor-threshold閾值的慢命令
fast-command	時間複雜度爲O(1)和O(logN)的命令	latency history fast-command	時間複雜度爲O(1)和O(logN)的命令
fork	系統調用fork(2)	latency history fork	AOF 或RDB 子進程

# "CONFIG SET latency-monitor-threshold <milliseconds>" if needed.
latency-monitor-threshold 0

EVENT NOTIFICATION(事件訂閱)

# 模式訂閱的配置
# 例如 notify-keyspace-events "gsExe"。便是說只容許監控Set結構的全部事件，而且之啓用了鍵事件通知，沒有啓用鍵空間通知。
notify-keyspace-events ""

 

ADVANCED CONFIG(高級配置)

# 當hash中包含超過指定元素個數而且最大的元素沒有超過臨界時，
# hash將以一種特殊的編碼方式（大大減小內存使用）來存儲，這裏能夠設置這兩個臨界值
# Redis Hash對應Value內部實際就是一個HashMap，實際這裏會有2種不一樣實現，
# 這個Hash的成員比較少時Redis爲了節省內存會採用相似一維數組的方式來緊湊存儲，而不會採用真正的HashMap結構，對應的value redisObject的encoding爲zipmap,
# 當成員數量增大時會自動轉成真正的HashMap,此時encoding爲ht。
hash-max-zipmap-entries 512
hash-max-zipmap-value 64

# list數據類型多少節點如下會採用去指針的緊湊存儲格式。
# list數據類型節點值大小小於多少字節會採用緊湊存儲格式。
list-max-ziplist-entries 512
list-max-ziplist-value 64

# set數據類型內部數據若是所有是數值型，且包含多少節點如下會採用緊湊格式存儲。
set-max-intset-entries 512

# zsort數據類型多少節點如下會採用去指針的緊湊存儲格式。
# zsort數據類型節點值大小小於多少字節會採用緊湊存儲格式。
zset-max-ziplist-entries 128
zset-max-ziplist-value 64


# Redis將在每100毫秒時使用1毫秒的CPU時間來對redis的hash表進行從新hash，能夠下降內存的使用
# 
# 當你的使用場景中，有很是嚴格的實時性須要，不可以接受Redis時不時的對請求有2毫秒的延遲的話，把這項配置爲no。
#
# 若是沒有這麼嚴格的實時性要求，能夠設置爲yes，以便可以儘量快的釋放內存
activerehashing yes

 

VIRTUAL MEMORY(虛擬內存)

# 指定是否啓用虛擬內存機制，默認值爲no，簡單的介紹一下，VM機制將數據分頁存放，由Redis將訪問量較少的頁即冷數據swap到磁盤上，訪問多的頁面由磁盤自動換出到內存中（在後面的文章我會仔細分析Redis的VM機制）

     vm-enabled no

# 虛擬內存文件路徑，默認值爲/tmp/redis.swap，不可多個Redis實例共享

     vm-swap-file /tmp/redis.swap

# 將全部大於vm-max-memory的數據存入虛擬內存,不管vm-max-memory設置多小,全部索引數據都是內存存儲的(Redis的索引數據 就是keys),也就是說,當vm-max-memory設置爲0的時候,實際上是全部value都存在於磁盤。默認值爲0

     vm-max-memory 0

# Redis swap文件分紅了不少的page，一個對象能夠保存在多個page上面，但一個page上不能被多個對象共享，vm-page-size是要根據存儲的 數據大小來設定的，做者建議若是存儲不少小對象，page大小最好設置爲32或者64bytes；若是存儲很大大對象，則可使用更大的page，若是不 肯定，就使用默認值

     vm-page-size 32

# 設置swap文件中的page數量，因爲頁表（一種表示頁面空閒或使用的bitmap）是在放在內存中的，，在磁盤上每8個pages將消耗1byte的內存。

     vm-pages 134217728

# 設置訪問swap文件的線程數,最好不要超過機器的核數,若是設置爲0,那麼全部對swap文件的操做都是串行的，可能會形成比較長時間的延遲。默認值爲4

     vm-max-threads 4

# 設置在向客戶端應答時，是否把較小的包合併爲一個包發送，默認爲開啓

    glueoutputbuf yes

# 指定在超過必定的數量或者最大的元素超過某一臨界值時，採用一種特殊的哈希算法

    hash-max-zipmap-entries 64

    hash-max-zipmap-value 512

# 指定是否激活重置哈希，默認爲開啓（後面在介紹Redis的哈希算法時具體介紹）

    activerehashing yes

 

場景分析

設置密碼

# 注意redis旨在作高速緩存，安全並非主要策略，因此redis默認不像mysql同樣必定要你指定一個密碼
# 1.查看redis的密碼
config get requirepass 
# 2.設置redis密碼
config set requirepass '12345'  
# 3.輸入密碼
auth 12345 

上面端設置只要redis服務端重啓後就失效，若要長久有效，須要在配置文件裏配置

requirepass 12345 # 若是真的要爲安全考慮，就必須設置複雜密碼，redis是高併發的，弱密碼很容易受到暴力破解

注意：除了進入redis後使用auth命令認證，還能夠客戶端啓動時傳入密碼參數

 /usr/local/redis/bin/redis-cli -h 192.168.2.129 -p 6379 -a 12345 

遠程鏈接

在redis.conf中配置
1.遠程鏈接redis要配置密碼，並且還要修改bind 127.0.0.1 爲 bind 0.0.0.0
2.設置密碼 

持久化

咱們已經說過，既能夠把redis理解爲緩存技術，也能夠理解爲數據庫，由於redis支持將內存中的數據週期性的寫入磁盤或者把操做追加到記錄文件中，這個過程稱爲redis的持久化。redis支持兩種方式的持久化，一種是快照方式（snapshotting）,也稱RDB方式；兩一種是追加文件方式（append-only file），也稱AOF方式。RDB方式是redis默認的持久化方式。

RDB

- RDB方式原理
當redis須要作持久化時（執行SAVA或者BGSAVA命令，或者是達到配置條件時執行），redis會fork一個子進程，子進程將數據寫到磁盤上一個臨時RDB文件中，當子進程完成寫臨時文件後，將原來的RDB替換掉（默認文件名爲dump.rdb）

- RDB命令

一、執行SAVE命令，在當前線程執行，會卡住
二、執行BGSAVE命令，在後臺線程執行，立刻返回
三、當符合用戶給定的配置條件時Redis會自動將內存中的全部數據進行快照並存儲在硬盤上。由兩個參數構成：時間和改動的鍵的個數。當在指定的時間內被更改的鍵的個數大於指定的數值時就會進行快照

注意，SHUTDOWN命令會迅速生成dump.db文件（flushall+shutdown毀天滅地）

- RDB優缺點
定時備份，Redis效率高，可是容易形成數據丟失，丟失的多少和備份策略有關，例如：5分鐘備份一次，可是第8分時宕機了，那麼就丟失了後面的3分鐘數據

AOF

- AOF方式原理
AOF就能夠作到全程持久化，Redis每執行一個修改數據的命令，都會把這個命令添加到AOF文件中，當Redis重啓時，將會讀取AOF文件進行「重放」以恢復到 Redis關閉前的最後時刻。

因爲os會在內核中緩存 write作的修改，因此可能不是當即寫到磁盤上。這樣aof方式的持久化也仍是有可能會丟失部分修改。不過咱們能夠經過配置文件告訴redis咱們想要 經過fsync函數強制os寫入到磁盤的時機。有三種方式以下（默認是：每秒fsync一次）

 

- 爲何aof會在rdb以後產生？
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 ：很是慢，也很是安全

appendfsync always

#每秒 fsync 一次：足夠快（和使用 RDB 持久化差很少），而且在故障時只會丟失 1 秒鐘的數據

appendfsync everysec

#從不 fsync ：將數據交給操做系統來處理。更快，也更不安全的選擇

appendfsync no 

從上面三種AOF持久化時機來看，爲了保證不丟失數據，appendfsync always是最安全的。

- AOF優缺點

優勢：AOF基本能夠保證數據不丟失，數據完整性比rdb要高。
缺點： 1.AOF持久化文件會變的愈來愈大。例如咱們調用incr test命令100次，文件中必須保存所有的100條命令，其實有99條都是多餘的。
　　　2.頻繁的IO和aof文件過大時的rewrite會帶來系統波動，而且因爲語句過多且不斷變化，致使恢復數據速度慢於rdb，而且備份數據庫可能會出bug。因此通常不單獨使用（以防萬一）

- 若是一個系統裏面，同時存在rdb和aof，它們是衝突仍是協做？
二者能夠共存，先加載的是aof。若是aof錯誤，redis-server起不來

- aof文件修復
redis-check-aof --fix xxx.aof 用來修復錯誤的aof文件，去除裏面的錯誤數據（延時，丟包，病毒，大程序異常致使的文件錯損等都會產生錯誤數據）

主從複製

主從複製主要用於容災恢復（主機掛了，能迅速切換到從機，而後去修從機）和讀寫分離。
主從複製有延遲這個不可避免的缺點，可是不妨礙其成爲流行的技術

 

- 主從複製的特色
一個主服務器能夠有多個從服務器。不只主服務器能夠有從服務器， 從服務器也能夠有本身的從服務器。

Redis 支持異步複製和部分複製（這兩個特性從Redis 2.8開始），主從複製過程不會阻塞主服務器和從服務器。

Master Server是以非阻塞的方式爲Slaves提供服務。因此在Master-Slave同步期間，客戶端仍然能夠提交查詢或修改請求。Slave Server一樣是以非阻塞的方式完成數據同步。在同步期間，若是有客戶端提交查詢請求，Redis則返回同步以前的數據。

通常是主寫從讀。如讓多個從服務器處理只讀命令，使用複製功能來讓主服務器免於頻繁的執行持久化操做。即只有主機能夠寫，從機不能夠寫

Master能夠將數據保存操做交給Slaves完成，從而避免了在Master中要有獨立的進程來完成此操做。

---

主機down了，從機不上位等待主機迴歸。若已經有從機上位（哨兵模式或者手動調整）以前的master將會變爲slave爲新的master服務

從機掛了，要從新使用slave of命令認主（能夠寫入配置文件避免） 

- 主從複製過程

 

Redis主從複製過程示意圖

 

 

從上面的示意圖能夠看出，主服務器與從服務器創建鏈接以後，Redis主從複製過程主要有下面幾步：

1. 從服務器向主服務器發送SYNC命令；
2. 收到SYNC命令的主服務器執行BGSAVE命令，在後臺生成一個RDB文件，並使用一個緩衝區記錄從如今開始執行的全部寫命令；
3. 當主服務器的BGSAVE命令執行完畢時，主服務器會將BGSAVE命令生成的RDB文件發送給從服務器，從服務器接收並載入這個RDB文件，將本身的數據庫狀態更新至主服務器執行BGSAVE命令時的數據庫狀態。
4. 主服務器將記錄在緩衝區裏面的全部寫命令發送給從服務器，從服務器執行這些寫命令，將本身的數據庫狀態更新至主服務器數據庫當前所處的狀態。

從服務器對主服務器的複製能夠分爲如下兩種狀況：

• 初次複製：從服務器之前沒有複製過任何主服務器，或者從服務器當前要複製的主服務器和上一次複製的主服務器不一樣；
• 斷線後重複製：處於命令傳播階段的主從服務器由於網絡緣由而中斷了複製，但從服務器經過自動重鏈接從新連上了主服務器，並繼續複製主服務器。

 

可是SYNC命令是很是消耗資源的，SYNC是一個如此消耗資源的命令，因此Redis最好在真須要的時候才須要執行SYNC命令。
由於每次執行SYNC命令，主從服務器須要執行一下操做：

 

1. 主服務器須要執行BGSAVE命令來生成RDB文件，這個生成操做會耗費主服務器大量的CPU、內存和磁盤I/O資源；
2. 主服務器須要將本身生成的RDB文件發送給從服務器，這個發送操做會耗費主從服務器大量的網絡資源（帶寬和流量），並對主服務器響應命令請求的時間產生影響；
3. 接收到RDB文件的從服務器須要載入主服務器發來的RDB文件，而且在載入期間，從服務器會由於阻塞而沒辦法處理命令請求。

爲了解決舊版複製功能在處理斷線重複制狀況時的低效問題，Redis從2.8版本開始，使用PSYNC命令代替SYNC命令來執行復制時的同步操做。

PSYNC命令具備完整重同步（full resynchronization）和部分重同步（partial resynchronization）兩種模式：

• 其中完整重同步用於處理初次複製狀況：完整重同步的執行步驟和SYNC命令的執行步驟基本同樣，它們都是經過讓主服務器建立併發送RDB文件，以及向從服務器發送保存在緩衝區裏面的寫命令來進行同步；
• 而部分重同步則用於處理斷線後重複製狀況：當從服務器在斷線後從新鏈接主服務器時，若是條件容許，主服務器能夠將主從服務器鏈接斷開期間執行的寫命令發送給從服務器，從服務器只要接收並執行這些寫命令，就能夠將數據庫更新至主服務器當前所處的狀態。

配置

配從不配主

info replication #查看當前redis的角色

slave of 127.0.0.1 6379 #從機認主

slaveof no one # 叢機上位

 

 

  見以下步驟：
    1). 同時啓動兩個Redis服務器，能夠考慮在同一臺機器上啓動兩個Redis服務器，分別監聽不一樣的端口，如6379和6380。
    2). 在Slave服務器上執行一下命令：
    /> redis-cli -p 6380   #這裏咱們假設Slave的端口號是6380
    redis 127.0.0.1:6380> slaveof 127.0.0.1 6379 #咱們假設Master和Slave在同一臺主機，Master的端口爲6379
    OK
    上面的方式只是保證了在執行slaveof命令以後，redis_6380成爲了redis_6379的slave，一旦服務(redis_6380)從新啓動以後，他們之間的複製關係將終止。
    若是但願長期保證這兩個服務器之間的Replication關係，能夠在redis_6380的配置文件中作以下修改：
    /> cd /etc/redis  #切換Redis服務器配置文件所在的目錄。
    /> ls
    6379.conf  6380.conf
    /> vi 6380.conf
    將
    # slaveof <masterip> <masterport>
    改成
    slaveof 127.0.0.1 6379
    保存退出。
    這樣就能夠保證Redis_6380服務程序在每次啓動後都會主動創建與Redis_6379的Replication鏈接了。

  這裏咱們假設Master-Slave已經創建。
    #啓動master服務器。
    [root@Stephen-PC redis]# redis-cli -p 6379
    redis 127.0.0.1:6379>
    #狀況Master當前數據庫中的全部Keys。
    redis 127.0.0.1:6379> flushdb
    OK
    #在Master中建立新的Keys做爲測試數據。
    redis 127.0.0.1:6379> set mykey hello
    OK
    redis 127.0.0.1:6379> set mykey2 world
    OK
    #查看Master中存在哪些Keys。
    redis 127.0.0.1:6379> keys *
    1) "mykey"
    2) "mykey2"
    
    #啓動slave服務器。
    [root@Stephen-PC redis]# redis-cli -p 6380
    #查看Slave中的Keys是否和Master中一致，從結果看，他們是相等的。
    redis 127.0.0.1:6380> keys *
    1) "mykey"
    2) "mykey2"
    
    #在Master中刪除其中一個測試Key，並查看刪除後的結果。
    redis 127.0.0.1:6379> del mykey2
    (integer) 1
    redis 127.0.0.1:6379> keys *
    1) "mykey"
    
    #在Slave中查看是否mykey2也已經在Slave中被刪除。
    redis 127.0.0.1:6380> keys *
    1) "mykey"

 

- 哨兵模式

通俗地講，讓哨兵（一個進程）盯着主機，主機一掛當即組織從機投票選取新的老大
反客爲主的自動版，能都後臺監控主機是否故障，若是故障了根據投票數自動將從庫轉換爲主庫

 

 

集羣

我所在的公司用不上redis集羣，不過仍是做一下了解
詳細

訂閱發佈

　　Redis從2.X版本開始，就支持一種基於非持久化消息的、使用發佈/訂閱模式實現的事件通知機制。
redis當消息訂閱機制，簡單一句就是你在線就收到，不在線就收不到。當消息訂閱者因爲各類異常狀況而被迫斷開鏈接，在其從新鏈接後，其離線期間的事件是沒法被從新通知的（一些redis資料中也稱爲即發即棄）。
其使用的發佈/訂閱模式的機制並不是由訂閱者週期性的從Redis服務拉取事件通知，而是由Redis服務主動推送事件通知到符合條件的若干訂閱者。

Redis訂閱/發佈功能的不足

Redis提供的訂閱/發佈功能並不完美，更不能和ActiveMQ/RabbitMQ提供的訂閱/發佈功能相提並論。

• 首先這些消息並無持久化機制，屬於即發即棄模式。也就是說它們不能像ActiveMQ中的消息那樣保證持久化消息訂閱者不會錯過任何消息，不管這些消息訂閱者是否隨時在線。

• 因爲原本就是即發即棄的消息模式，因此Redis也不須要專門制定消息的備份和恢復機制。

• 也是因爲即發即棄的消息模式，因此Redis也沒有必要專門對使用訂閱/發佈功能的客戶端鏈接進行識別，用來明確該客戶端鏈接的ID是否在以前已經鏈接過Redis服務了。ActiveMQ中保持持續通知的功能的前提，就是可以識別客戶端鏈接ID的歷史鏈接狀況，以便肯定哪些訂閱消息這個客戶端尚未處理。

• Redis當前版本有一個簡單的事務機制，這個事務機制能夠用於PUBLISH命令。可是徹底沒有ActiveMQ中對事務機制和ACK機制那麼強的支持。而在我寫做的「系統間通信」專題中，專門講到了ActiveMQ的ACK機制和事務機制。

• Redis也沒有爲發佈者和訂閱者準備保證消息性能的任何方案，例如在大量消息同時到達Redis服務是，若是消息訂閱者來不及完成消費，就可能致使消息堆積。而ActiveMQ中有專門針對這種狀況的慢消息機制。
  
  

Redis中的事件功能能夠提供兩種不一樣的功能
第一類：基於Channel的消息事件
　　　　這一類消息和Redis中存儲的Keys沒有太多關聯，也就是說即便不在Redis中存儲任何Keys信息，這類消息事件也能夠獨立使用。 　　
第二類：消息事件能夠對（也能夠不對）Redis中存儲的Keys信息的變化事件進行通知

　　　　能夠用來向訂閱者通知Redis中符合訂閱條件的Keys的各類事件。Redis服務的事件功能在實際場景中雖然使用得很少，不過仍是能夠找到案例。

　　　　例如服務治理框架DUBBO默認狀況下使用Zookeeper做爲各節點的服務協調裝置，但能夠經過更改DUBBO的配置，將Zookeeper更換爲Redis。

普通訂閱

咱們先從比較簡單的publish命令和subscribe命令開始介紹，由於這組命令所涉及到的Channel（通道）和Redis中存儲的數據相對獨立。publish命令由發送者使用，負責向指定的Channel發送消息；subscribe命令由訂閱者使用，負責從指定的一個或者多個Channel中獲取消息。
如下是 publish 命令和 subscribe 命令的使用示例：

// 該命令向指定的channel名字發送一條消息（字符串）
PUBLISH channel message 
// 例如：向名叫FM955的頻道發送一條消息，消息信息爲「hello!」
PUBLISH FM955  "hello!"
// 再例如：向名叫FM900的頻道發送一條消息，消息信息爲「 doit!」
PUBLISH FM900 "doit!"
// 該命令能夠開始向指定的一個或者多個channel訂閱消息
SUBSCRIBE channel [channel ...]
// 例如：向名叫FM955的頻道訂閱消息
SUBSCRIBE FM955
// 再例如：向名叫FM95五、FM900的兩個頻道訂閱消息
SUBSCRIBE FM955 FM900

若是您使用須要使用publish命令和subscribe命令，您並不須要對Redis服務的配置信息作任何更改。如下示例將向讀者展現兩個命令的簡單使用方式——前提是您的Redis服務已經啓動好了：
由客戶端A充當訂閱者，在ChannelA和ChannelB兩個頻道上訂閱消息

-- 咱們使用的Redis服務地址爲192.168.61.140，端口爲默認值
[root@kp2 ~]# redis-cli -h 192.168.61.140
192.168.61.140:6379> SUBSCRIBE ChannelA ChannelB
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ChannelA"
3) (integer) 1
1) "subscribe"
2) "ChannelB"
3) (integer) 2

• 有客戶端B從當訂閱者，經過ChannelB發送消息給全部訂閱者

-- 鏈接到Redis服務器後，直接運行PUBLISH命令，發送信息

[root@kp1 ~]# redis-cli -h 192.168.61.140
192.168.61.140:6379> PUBLISH ChannelB "hello"
(integer) 1

• 如下是訂閱者客戶端A所受到的message信息

-- 這時訂閱者收到消息以下：

1) "message"
2) "ChannelB"
3) "hello"

　　從以上示例中能夠看到，客戶端A確實收到了客戶端B所發送的消息信息，而且收到三行信息。這三行信息分別表示消息類型、消息通道和消息內容。注意，以上介紹的這組publish命令和subscribe命令的操做過程並無對Redis服務中已存儲的任何Keys信息產生影響。

模式訂閱psubscribe

　　Redis中還支持一種模式訂閱，它主要依靠psubscribe命令向技術人員提供訂閱功能。模式訂閱psubscribe最大的特色是，它除了能夠經過Channel訂閱消息之外，還能夠配合配置命令來進行Keys信息變化的事件通知。

　　模式訂閱psubscribe的Channel訂閱和subscribe命令相似，這裏給出一個命令格式，就再也不多作介紹了（可參考上文對subscribe命令的介紹）：

// 該命令能夠開始向指定的一個或者多個channel訂閱消息
// 具體使用示例可參見SUBSCRIBE命令
PSUBSCRIBE channel [channel ...]

　　模式訂閱psubscribe對Keys變化事件的支持分爲兩種類型：keyspace（鍵空間通知）和keyevent（鍵事件通知），這兩類事件都是依靠Key的變化觸發的，而關鍵的區別在於事件描述的焦點，舉例說明：

　　當Redis服務中0號數據庫的MyKey鍵被刪除時，鍵空間和鍵事件向模式訂閱者分別發送的消息格式以下：

// 如下命令可訂閱鍵空間通知
// 訂閱0號數據庫任何Key信息的變化
192.168.61.140:6379> psubscribe __keyspace@0__:*
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "__keyspace@0__:*"
3) (integer) 1
// 出現以上信息，說明訂閱成功
// 當其餘客戶端執行 set mykey 123456 時，該訂閱可收到如下信息
1) "pmessage"
2) "__keyspace@0__:*"
3) "__keyspace@0__:mykey"
4) "set"

　　以上收到的訂閱信息，其描述能夠歸納爲：「mykey的鍵空間發生了事件，事件爲set」。這樣的事件描述着重於key的名稱，而且告訴客戶端key的事件爲set。咱們再來看看訂閱鍵事件通知時，發生一樣事件所獲得的訂閱信息：

// 如下命令可訂閱鍵空間通知
// 訂閱0號數據庫任何Key信息的變化
192.168.61.140:6379> psubscribe __keyspace@0__:*
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "__keyspace@0__:*"
3) (integer) 1
// 出現以上信息，說明訂閱成功
// 當其餘客戶端執行 set mykey 123456 時，該訂閱可收到如下信息
1) "pmessage"
2) "__keyspace@0__:*"
3) "__keyspace@0__:mykey"
4) "set"

　　以上收到的訂閱信息中事件是主體，其信息能夠歸納爲：「0號數據庫發生了set事件，發生這個事件的key信息爲mykey」。

模式訂閱的配置

一、配置和通配符

　　要使用psubscribe命令進行鍵事件的訂閱，就首先須要在Redis的主配置文件中對模式訂閱進行設定。注意，若是您只是使用psubscribe命令經過Channel發送消息到訂閱者，或者更單純的使用publish命令和subscribe命令組合經過Channel發送和接收消息，就不須要進行這樣的配置。

　　默認狀況下Redis服務下的鍵空間通知和鍵事件通知都是關閉的。在redis.conf文件下，有專門的「EVENT NOTIFICATION」區域進行設定，設置的格式爲：

notify-keyspace-events [通配符]

通配符的定義描述以下：

• K：啓用keyspace鍵空間通知，客戶端可使用keyspace@爲前綴的格式使用訂閱功能；
• E：啓用keyevent鍵事件通知，客戶端可使用keyevent@爲前綴的格式使用訂閱功能；
• g：監控通常性事件，包括但不限於對del，expire，rename事件的監控；
• $：啓用對字符串格式（即通常K-V結構）命令的監控；
• l：啓用對List數據結構命令的監控；
• s：啓用對Set數據結構命令的監控；
• h：啓用對Hash數據結構命令的監控；
• z：啓用對ZSet數據結構命令的監控；
• x：啓用對過時事件的監控；
• e：啓用對驅逐事件的監控，當某個鍵因maxmemory達到設置時，使用策略進行內存清理，會產生這個事件；
• A：g$lshzxe通配符組合的別名，也就是說」AKE」這樣的通配符組合，意味着全部事件。

如下的幾個實例說明了配置格式中通配符的用法：

// 監控任何數據格式的全部事件，包括鍵空間通知和鍵事件通知
notify-keyspace-events "AKE"

// 只監控字符串結構的全部事件，包括鍵空間通知和鍵事件通知
notify-keyspace-events "g$KExe"

// 只監控全部鍵事件通知
notify-keyspace-events "AE"

// 只監控Hash數據解構的鍵空間通知
notify-keyspace-events "ghKxe"

// 只監控Set數據結構的鍵事件通知
notify-keyspace-events "gsExe"

　　注意，在Redis主配置文件中進行事件通知的配置，其配置效果是全局化的。也就是說全部鏈接到Redis服務的客戶端都會使用這樣的Key事件通知邏輯。但若是單獨須要爲某一個客戶端會話設置獨立的Key事件通知邏輯，則能夠在客戶端成功鏈接Redis服務後，使用相似以下的命令進行設置：

......
192.168.61.140:6379> config set notify-keyspace-events KEA  
OK 

二、鍵事件訂閱

　　完成鍵事件的配置後，就可使用psubscribe命令在客戶端訂閱消息通知了。這個過程仍是須要使用通配符參數，才能完成訂閱指定。通配符格式以下所示：

psubscribe __[keyspace|keyevent]@<db>__:[prefix]

// 例如：
// 訂閱0號數據庫中，全部的鍵變化事件，進行鍵空間通知
psubscribe __keyspace@0__:*

// 訂閱0號數據庫，全部的鍵變化事件，進行鍵空間通知和鍵事件通知
psubscribe __key*@0__:*

　　注意，就如上文所提到的那樣，客戶端可以進行鍵信息變化事件訂閱的前提是Redis服務端或者這個客戶端會話自己開啓了相應配置。如下舉例說明psubscribe命令中參數的使用方式：

// 注意，Redis服務上的配置信息以下
// notify-keyspace-events "gsExe"
// 便是說只容許監控Set結構的全部事件，而且之啓用了鍵事件通知，沒有啓用鍵空間通知。

// 客戶端使用如下命令開始訂閱Key的變化事件
192.168.61.140:6379> psubscribe __key*@0__:*
// 以上命令訂閱了0號數據庫全部鍵信息的變化通知，包括鍵事件通知和鍵空間通知
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "__key*@0__:*"
3) (integer) 1

// 接着，已鏈接到Redis服務上的另外一個客戶端執行了以下命令
// > sadd mysetkey rt
// 那麼收到的消息通知爲
1) "pmessage"
2) "__key*@0__:*"
3) "__keyevent@0__:sadd"
4) "mysetkey"

以上實例操做中有兩個問題須要單獨進行說明：

　　當客戶端使用psubscribe命令進行訂閱時（psubscribe key*@0:*），其實是連同keyspace（鍵空間通知）和keyevent（鍵事件通知）一塊兒訂閱了。那麼按照上文介紹的內容來講，這個訂閱者本該收到兩條事件消息。一條消息的描述重點在key上，另外一條消息的描述重點在sadd事件上。但實際狀況是，這個訂閱者只收到了以描述重點在事件上的鍵事件通知。這是由於在以上實例中特別說明的一點：Redis服務端只開啓鍵事件通知的配置。因此不管客戶端如何訂閱鍵空間通知，也收不到任何消息。

　　另外，包括Redis官方資料在內的資料都在闡述這樣一個事實，既是經過sadd命令對一個Set結構中的元素進行變動和直接經過「PUBLISH keyevent@0:sadd mysetkey」這樣的命令向訂閱者發送消息，在消息訂閱者看來效果都是同樣。可是這兩種不一樣的操做過程對於Redis存儲的Key數據，則是徹底不同的。前者的操做方式會改變Redis中存儲的數據情況，但後者則不會。