1、發佈訂閱模式
例子：比如說你們家有個收音機 你收聽了 xxxxx 頻道 那麼只要你打開這個頻道 你就能收聽到這個頻道的所有的內容
你的收音機-----------接收方(訂閱方)
頻道的內容發送方-------內容的發佈者
subscribe 訂閱的頻道的名稱
publish 頻道名字 內容
場景：這個功能實際上就是咋們的 MQ中的功能
2、Redis中事務問題
事務應該是具有原子性，一串的操作要麼同時成功、要麼同時失敗
multi 開啓事務
.....
.....
exec 提交事務
3、rdb模式實現持久化
Redis是基於內存的、所以速度快、但是Redis的數據放到內存裏面、當Redis重啓的時候 這個數據會發生丟失
假設我們能把寫入到內存的數據、持久化到硬盤 那是不是就能保證我們的數據即使發生丟失 也不會全部丟失、或者全部不丟失呢?
Redis的持久化就產生了----默認情況下 Redis本身也是有持久化策略的
我們即使不配置 那麼這個Redis的持久化依然存在的
rdb是數據庫默認的持久化模式-----又稱爲快照模式
這個模式是將內存的數據內容 直接保存到 dump.rdb這樣的一個二進制文件中的
特點：因爲保存的是二進制文件、所以做數據的恢復是相當的快的—適合於做數據的備份
rdb到底是如何保存我們的數據庫的：rdb每一次在保存這個數據的時候、首先都會清空原有的dump.rdb文件、然後將整個內存的數據全部寫入到這個文件中 rbd-------保存的是redis內存中某一個時刻的數據(適合備份、不適合開發用)
rdb模式的問題：
假設剛好清空dump.rdb這個文件、現在斷電了------------數據全丟了
什麼時候 rdb模式會觸發內存的數據和硬盤進行同步呢?
save 900 1 在900秒的時間內如果有1和key發生改變 那麼將觸發內存和硬盤同步
save 300 10 在300秒的事件內如果有10個key發生改變 那麼將會觸發內存和硬盤同步
save 60 10000 在60秒的時間類假設有10000個key發生改變那麼也變觸發內存和硬盤同步
rdb模式是不用開啓的、這個模式的redis自動開啓的
4、aof實現持久化
aof模式是在redis1.1的版本的時候、才增加的一種持久化模式
aof模式在使用的時候 保存的不是數據 是我們操作的時候的一條一條的命令
只要調用了Redis 那麼只要有命令的使用那麼都會被記錄到aof文件中
aof---------------記錄的是操作的命令 不記錄實際的數據
aof模式如果是在數據恢復還原的時候 效率並不高 數據恢復的話採用rdb文件恢復是最快的
aof模式如何使用
appendonly yes ：表示的是開啓 aof 的模式
*3 *代表的是命令的開始 3 ：這個表示的是命令中一共有3塊內容
$3 $使用修飾命令中的每一個參數的 3代表的是下面的這個命令一共有3個字符
set
$5
email
$5
xxxxx
rdb 存在 aof 現在也存在 ? 會以誰優先呢？
這裏如果是開啓了aof模式 那麼會以aof模式爲優先
aof模式是否有觸發策略?
appendfsync always ：只要有鍵發生改變 立馬同步(每一次都觸發IO操作、速度就慢下來、這種情況是不會丟數據)-----一般不用（效率太低了）
appendfsync everysec ：每一秒鐘進行數據同步一次(開發的時候一般選用他----速度上也比較快 即使出現數據的丟失也只會丟失1秒鐘的數據)
appendfsync no ：永遠不同步、數據只是放到緩存裏面 速度快 但是數據容易丟失
aof模式是如何同步數據的呢?
每一次在進行數據同步的時候 使用的是 追加的模式 以前的數據不用刪除 只需要追加新的操作即可
aof模式消息的重寫
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100 (這個表示的是必須達到100%的增加才重寫 64M+64M=128M )
auto-aof-rewrite-min-size 64mb aof文件（簡單的說就是至少aof文件達到64M才重寫）
手動重寫
bgrewriteaof ：這個命令就是手動重寫
重寫的好處是對aof文件進行優化(最終的結果都是一樣的)
如果你要去手動重寫(需要關閉混合持久化的開關才能看到功能)
aof-use-rdb-preamble no
5、混合持久化的問題
我們在開發的時候到底是選擇 rdb 還是aof呢?
如果你關心的是你的數據、但是任然可以接受在一段時間內依然可以接受一些數據的丟失 那麼你可以使用rdb(速度快)
我們以前開發的時候基本上都使用aof模式來做開發、如果你用的版本是4.0以前的版本那麼建議你呢還是使用aof
在4.0以後 就出現了一種新的持久化模式(混合持久化)
這個混合持久化 就集成了 rdb的有點和aof所有的有點
畫圖：理解混合持久化
6、緩存的淘汰策略
什麼是緩存淘汰策略、簡單的說就是咋們的redis中的內存已經滿了、現在要保證內存中的Redis的數據 一定是最新的、那麼這個時候就需要配置緩存的淘汰策略了
noeviction：只要緩存滿了、那麼就不繼續服務器裏面的寫的請求、讀的請求是可以完成的、這種模式緩存裏面的所有數據 都不會丟失、這種情況會導致參與Redis的業務會失敗
volatile-lru：他會優先淘汰掉 設置了過期時間的這個key、然後第二步才淘汰掉使用的比較少的key 假設我們的key沒有設置過期時間的話 那麼不會優先淘汰
這種模式也是咋們在開發中使用的比較多的一種緩存策略模式
allkeys-lfu：和lru是有區別的、這個在淘汰的時候、淘汰的是全體key的集合、不是過期的key的集合(過期這一說法沒有)、這就意味着你沒有設置過期時間的key 只要使用的比較少那麼依然會被淘汰
volatile-ttl：這個淘汰策略不是LRU 、而是key剩餘的壽命的ttl值 ttl值越小 越先被淘汰
allkeys-random：使用這個淘汰策略的時候 淘汰的是隨機的key
maxmemory-policy volatile-lru 這個就是配置緩存的淘汰策略的
maxmemory <bytes> ：這個是配置Redis的緩存的大小
7、主從複製問題
一臺服務器主服務器(39.99.200.54)
另外兩臺作爲從服務器
106.54.13.167 47.96.119.26
實操
主服務器更改
daemonize yes //後臺啓動
bind 0.0.0.0 //表示的是允許所有人訪問
從服務器配置的更改
daemonize yes //後臺啓動
bind 0.0.0.0 //表示的是允許所有人訪問
slaveof 主服務器的ip地址 主服務器端口
使用如下命名 檢查主從是否配置好
./redis-cli
info
如果主服務器是如下的
8、哨兵模式
哨兵是安裝在任意一臺服務器上 、跟咋們的主服務器 並沒有任何的關聯
哨兵配置的節點：47.96.119.26
哨兵的配置
1、將Redis解壓目錄下的sentinal.xml文件複製到 /usr/local/zhucong/目錄下
2、配置sentinal.xml文件
#配置的是配置文件的目錄
dir /usr/local/zhucong/
#配置的是監聽主服務器信息 最後一個參數很重要 一般設置爲1 多少票通過
sentinel monitor mymaster 39.99.200.54 6379 1
#配置的是意思是心跳信號發給你了 多久沒回應就認爲主服務器死了...
sentinel down-after-milliseconds mymaster 5000
哨兵的啓動命令
./redis-server /usr/local/zhucong/sentinel.conf --sentinel &