摘要：優(yōu)點可以不使用機(jī)器的硬盤，直接網(wǎng)絡(luò)傳輸。三使用，獲取文件，解析后獲取數(shù)據(jù)。執(zhí)行該命令時，會在后臺異步進(jìn)行快照操作，快照同時還可以響應(yīng)客戶端請求。具體操作是進(jìn)程執(zhí)行操作創(chuàng)建子進(jìn)程，持久化過程由子進(jìn)程負(fù)責(zé)，完成后自動結(jié)束。統(tǒng)計并生成報表。

//舉例
$redis->set();
$redis->get();
$redis->hset();
$redis->hget();

//舉例
$redis->rpush();
$redis->lpop();
$redis->lrange();

//舉例
$redis->publish();
$redis->subscribe();

//舉例
$redis->set();
$redis->incr();

//舉例
$redis->zadd();
$redis->zrevrange();
$redis->zrange();

//舉例
$redis->sadd();
$redis->spop();
$redis->sinter();
$redis->sunion();
$redis->sdiff();

解釋：悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀。

每次去拿數(shù)據(jù)的時候都認(rèn)為別人會修改，所以每次在拿數(shù)據(jù)的時候都會上鎖。

場景：如果項目中使用了緩存且對緩存設(shè)置了超時時間。

當(dāng)并發(fā)量比較大的時候，如果沒有鎖機(jī)制，那么緩存過期的瞬間，

大量并發(fā)請求會穿透緩存直接查詢數(shù)據(jù)庫，造成雪崩效應(yīng)。

/**
 * 獲取鎖
 * @param  String  $key    鎖標(biāo)識
 * @param  Int     $expire 鎖過期時間
 * @return Boolean
 */
public function lock($key = "", $expire = 5) {
    $is_lock = $this->_redis->setnx($key, time()+$expire);
    //不能獲取鎖
    if(!$is_lock){
        //判斷鎖是否過期
        $lock_time = $this->_redis->get($key);
        //鎖已過期，刪除鎖，重新獲取
        if (time() > $lock_time) {
            unlock($key);
            $is_lock = $this->_redis->setnx($key, time() + $expire);
        }
    }

    return $is_lock? true : false;
}

/**
 * 釋放鎖
 * @param  String  $key 鎖標(biāo)識
 * @return Boolean
 */
public function unlock($key = ""){
    return $this->_redis->del($key);
}

// 定義鎖標(biāo)識
$key = "test_lock";

// 獲取鎖
$is_lock = lock($key, 10);
if ($is_lock) {
    echo "get lock success
";
    echo "do sth..
";
    sleep(5);
    echo "success
";
    unlock($key);
} else { //獲取鎖失敗
    echo "request too frequently
";
}

解釋：樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀。

每次去拿數(shù)據(jù)的時候都認(rèn)為別人不會修改，所以不會上鎖。

watch命令會監(jiān)視給定的key，當(dāng)exec時候如果監(jiān)視的key從調(diào)用watch后發(fā)生過變化，則整個事務(wù)會失敗。

也可以調(diào)用watch多次監(jiān)視多個key。這樣就可以對指定的key加樂觀鎖了。

注意watch的key是對整個連接有效的，事務(wù)也一樣。

如果連接斷開，監(jiān)視和事務(wù)都會被自動清除。

當(dāng)然了exec，discard，unwatch命令都會清除連接中的所有監(jiān)視。

$strKey = "test_age";

$redis->set($strKey,10);

$age = $redis->get($strKey);

echo "---- Current Age:{$age} ---- 

";

$redis->watch($strKey);

// 開啟事務(wù)
$redis->multi();

//在這個時候新開了一個新會話執(zhí)行
$redis->set($strKey,30);  //新會話

echo "---- Current Age:{$age} ---- 

"; //30

$redis->set($strKey,20);

$redis->exec();

$age = $redis->get($strKey);

echo "---- Current Age:{$age} ---- 

"; //30

//當(dāng)exec時候如果監(jiān)視的key從調(diào)用watch后發(fā)生過變化，則整個事務(wù)會失敗

上面的一些場景，咱們大部分都使用過，卻還沒有提及到Rdb文件。

“對吧，使用過Redis，卻不知道Rdb文件，你中槍了嗎？”

Redis 作為互聯(lián)網(wǎng)產(chǎn)品開發(fā)中不可缺少的常備武器，它性能高、數(shù)據(jù)結(jié)構(gòu)豐富、簡單易用，但同時也是因為太容易用了，不管什么數(shù)據(jù)、不管這數(shù)據(jù)有多大、不管數(shù)據(jù)有多少，通通塞進(jìn)去，最后導(dǎo)致的問題就是 Redis 內(nèi)存使用持續(xù)上升，但是又不知道里面的數(shù)據(jù)是不是有用，是否可以拆分和清理，最可怕的是服務(wù)器發(fā)生宕機(jī)后，Redis 數(shù)據(jù)庫里的所有數(shù)據(jù)將會全部丟失。

比如當(dāng)內(nèi)存上升，性能慢時，我們進(jìn)行性能調(diào)優(yōu)的時候，我們想知道：

哪些Key占用了大量的內(nèi)存？

想知道每個Key的占用空間？

想知道占用空間大的Key都存了啥？

想知道占用空間大的Key的重要性，當(dāng)性能慢的時候是否可以馬上刪除？

更想知道這些Key是哪個業(yè)務(wù)方，哪個開發(fā)創(chuàng)建的？這樣就可以找他溝通了。

一、先通過 keys * 命令，拿到所有的 key，然后根據(jù) key 再獲取所有的內(nèi)容。

優(yōu)點：可以不使用 Redis 機(jī)器的硬盤，直接網(wǎng)絡(luò)傳輸。

缺點：如果 key 數(shù)據(jù)特別多，keys 命令可能會直接導(dǎo)致 Redis 卡住，從而影響業(yè)務(wù)使用 或 對 Redis 請求太多次，資源消耗多，遍歷數(shù)據(jù)太慢。

二、開啟 aof，通過 aof 文件獲取所有的數(shù)據(jù)。

優(yōu)點：無需影響 Redis 服務(wù)，完全離線操作，足夠安全。

缺點：有一些 Redis 實例寫入頻繁，不適合開啟 aof，普適性不強(qiáng)；aof 文件有可能特別大，傳輸、解析起來太慢，效率低。

三、使用 bgsave，獲取 rdb 文件，解析后獲取數(shù)據(jù)。

優(yōu)點：機(jī)制成熟，可靠性好；文件相對小，傳輸、解析效率高。

缺點：bgsave 雖然會 fork 子進(jìn)程，但還是有可能導(dǎo)致主進(jìn)程卡住一段時間，對業(yè)務(wù)有產(chǎn)生影響的風(fēng)險。

綜合評估后，決定采用低峰期在從節(jié)點做 bgsave 獲取 rdb 文件，相對安全可靠，也可以覆蓋所有業(yè)務(wù)的 Redis 集群。

也就是說每個實例每天在低峰期自動生成一個 .rdb 文件，即使報表數(shù)據(jù)有一天的延遲也是可以接受的。

“哦，原來.rdb文件是磁盤的緩存文件，那么如何開啟持久化呢？”

下面簡單的介紹下，Redis 的持久化。

Redis 支持兩種方式的持久化，一種是RDB方式，一種是AOF方式。

RDB 是 Redis 用來進(jìn)行持久化的一種方式，是把當(dāng)前內(nèi)存中的數(shù)據(jù)集，快照寫入磁盤。

RDB（Redis DataBase）方式是通過快照完成的，當(dāng)符合一定條件時Redis會自動將內(nèi)存中的所有數(shù)據(jù)進(jìn)行快照，并且存儲到硬盤上，RDB是Redis的默認(rèn)持久化方式。

vim /usr/local/redis/conf/redis.conf

save 900 1    #15分鐘內(nèi)有至少1個鍵被更改
save 300 10   #5分鐘內(nèi)至少有10個鍵被更改
save 60 1000  #1分鐘內(nèi)至少有10000個鍵被更改

#以上條件都是或的關(guān)系，當(dāng)滿足其一就會進(jìn)行快照。

dbfilename "dump.rdb"       #持久化文件名稱
dir "/data/dbs/redis/6381"  #持久化數(shù)據(jù)文件存放的路徑

#配置文件修改后，需要重啟redis服務(wù)。

還可以通過命令行的方式進(jìn)行配置：

CONFIG GET save    #查看redis持久化配置

CONFIG SET save "100 20" #修改redis持久化配置

#使用命令行的方式配置，即時生效，服務(wù)器重啟后需要重新配置。

save

該命令會阻塞當(dāng)前Redis服務(wù)器，執(zhí)行save命令期間，Redis不能處理其他命令，直到RDB過程完成為止。

顯然該命令對于內(nèi)存比較大的實例會造成長時間阻塞，這是致命的缺陷。

bgsave

執(zhí)行該命令時，Redis會在后臺異步進(jìn)行快照操作，快照同時還可以響應(yīng)客戶端請求。

具體操作是Redis進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，RDB持久化過程由子進(jìn)程負(fù)責(zé)，完成后自動結(jié)束。阻塞只發(fā)生在fork階段。

AOF（APPEND ONLY MODE）是通過保存對redis服務(wù)端的寫命令（如set、sadd、rpush）來記錄數(shù)據(jù)庫狀態(tài)的，即保存你對redis數(shù)據(jù)庫的寫操作。

配置日志文件如下：

vim /usr/local/redis/conf/redis.conf
dir "/data/dbs/redis/6381"           #AOF文件存放目錄
appendonly yes                       #開啟AOF持久化，默認(rèn)關(guān)閉
appendfilename "appendonly.aof"      #AOF文件名稱（默認(rèn)）
appendfsync no                       #AOF持久化策略
auto-aof-rewrite-percentage 100      #觸發(fā)AOF文件重寫的條件（默認(rèn)）
auto-aof-rewrite-min-size 64mb       #觸發(fā)AOF文件重寫的條件（默認(rèn)）

#上面的每個參數(shù)，可以找資料了解下，不做多解釋了。

RDB 與 AOF 的優(yōu)缺點，見上面的即可。

至此，我們了解了 Redis 持久化的一些配置，里面的細(xì)節(jié)建議查詢相關(guān)資料進(jìn)行研究。

接下來繼續(xù)，通過上一步我們拿到了 rdb 文件，就相當(dāng)于拿到了Redis實例的數(shù)據(jù)。

解析 rdb 文件，獲取key和value的值。

根據(jù)相應(yīng)的數(shù)據(jù)結(jié)構(gòu)及內(nèi)容，估算內(nèi)存消耗。

統(tǒng)計并生成報表。

雪球 rdr：https://github.com/xueqiu/rdr

redis-rdb-tools：https://github.com/sripathikr...

講解了工作中常用的 redis 使用場景。

講解了 redis 持久化的兩個方式（RDB、AOF）。

推薦了兩個分析rdb的工具。

通過對 redis 的使用 到 了解到服務(wù)器上如何對redis數(shù)據(jù)做持久化快照，再到如何利用工具進(jìn)行分析rdb文件，最后通過分析后的數(shù)據(jù)，可以反過來對 redis 的使用提出一些建議。

其他知識點也是這樣，我們不能只停留在方法的簡單調(diào)用，就覺得理解了這門技術(shù)！

其實上面分析出來的數(shù)據(jù)，是不可能定位到這個key是哪個業(yè)務(wù)方的，哪個開發(fā)創(chuàng)建的，是否重要等等，那我們應(yīng)該怎么做呢？

制定開發(fā)團(tuán)隊的Redis Key的使用規(guī)范，通過key的命名可以得到：

屬于什么業(yè)務(wù)（加域名表示）

屬于什么數(shù)據(jù)類型（加數(shù)據(jù)類型標(biāo)示）

是否設(shè)置過期時間

...

統(tǒng)一平臺進(jìn)行Redis Key的申請，只有申請了才能進(jìn)行使用：

填寫申請人

填寫申請時間

填寫申請業(yè)務(wù)方

填寫數(shù)據(jù)類型

填寫Key的重要性

填寫Key是否存在過期時間

根據(jù)填寫項生成規(guī)范的key名稱

...(等等需要標(biāo)記的)

上面我們已經(jīng)能分析出某個redis實例rdb文件的內(nèi)容，通過分析出來的內(nèi)容 與 統(tǒng)一平臺申請的數(shù)據(jù)，進(jìn)行整合，分析key的合格率、內(nèi)存使用量、不同數(shù)據(jù)類型的分布、內(nèi)存占用量Top 100的值 等等。

我們可以通過運維了解到，每個服務(wù)器與實例之間的配置關(guān)系，就可以了解到某臺服務(wù)器（N個實例）上的 key的合格率、內(nèi)存使用量、不同數(shù)據(jù)類型的分布、內(nèi)存占用量Top 100的值等等。

這樣，在后臺系統(tǒng)中就可以看到哪臺服務(wù)器，哪個實例的使用情況，解決了Redis濫用并無法進(jìn)行監(jiān)控的問題。

系統(tǒng)的講解 - SSO 單點登錄

系統(tǒng)的講解 - PHP WEB 安全防御

系統(tǒng)的講解 - PHP 緩存技術(shù)

系統(tǒng)的講解 - PHP 接口簽名驗證

系統(tǒng)的講解 - PHP 浮點數(shù)高精度運算