redis持久化和分佈式實現

Redis是一種面向「key-value」類型數據的分佈式NoSQL數據庫系統，具備高性能、持久存儲、適應高併發應用場景等優點。

本文使用的redis是3.2.1版本。下載後，文件以下

 

將文件解壓到指定的目錄，而後打開一個cmd，定位到這個目錄，輸入：redis-server.exe redis.windows.conf。這樣就開啓了redis服務。

一個簡單的客戶端，再打開一個cmd，一樣的切換到剛纔的目錄，輸入：redis-cli.exe -h 127.0.0.1 -p 6379 

上面這些東西網上都有，就是redis的安裝，因此這裏只是提一下。

 一、RDB快照 （snapshots）

缺省狀況狀況下，Redis把數據快照存放在磁盤上的二進制文件中，文件名爲dump.rdb。你能夠配置Redis的持久化策略，例如數據集中每N秒鐘有超過M次更新，就將數據寫入磁盤；或者你能夠手工調用命令SAVE或BGSAVE。

Redis藉助了fork命令的copy on write機制。在生成快照時，將當前進程fork出一個子進程，而後在子進程中循環全部的數據，將數據寫成爲RDB文件。 

RDB存在哪些優點：

    1). 一旦採用該方式，那麼你的整個Redis數據庫將只包含一個文件，這對於文件備份而言是很是完美的。好比，你可能打算每一個小時歸檔一次最近24小時的數據，同時還要天天歸檔一次最近30天的數據。經過這樣的備份策略，

　　一旦系統出現災難性故障，咱們能夠很是容易的進行恢復。
    2). 對於災難恢復而言，RDB是很是不錯的選擇。由於咱們能夠很是輕鬆的將一個單獨的文件壓縮後再轉移到其它存儲介質上。
    3). 性能最大化。對於Redis的服務進程而言，在開始持久化時，它惟一須要作的只是fork出子進程，以後再由子進程完成這些持久化的工做，這樣就能夠極大的避免服務進程執行IO操做了。
    4). 相比於AOF機制，若是數據集很大，RDB的啓動效率會更高。

RDB的不足：

　1). 若是你想保證數據的高可用性，即最大限度的避免數據丟失，那麼RDB將不是一個很好的選擇。由於系統一旦在定時持久化以前出現宕機現象，此前沒有來得及寫入磁盤的數據都將丟失。

    2). 因爲RDB是經過fork子進程來協助完成數據持久化工做的，所以，若是當數據集較大時，可能會致使整個服務器中止服務幾百毫秒，甚至是1秒鐘。

 

rdb的持久化是指在指定的時間間隔內將內存中的數據集快照寫入磁盤。     這個指定的時間間隔在redis.windows.conf文件中有設置。

這裏爲了試驗須要，我將其修改成10秒內有一次修改就將數據寫入磁盤。

打開簡單的客戶端窗口，先寫入一條數據，而後等10秒後，將服務關掉，再次打開服務，在客戶端獲取剛纔寫入的數據

若是數據沒有寫入磁盤持久化，那麼在關閉服務後，以前寫入的數據就不存在。如今重啓服務，在客戶端獲取數據看看

看到數據獲取是成功的。

RDB快照是redis的默認持久化的方式，所須要修改的就是上面的寫入磁盤的條件

 

 二、Redis的第二個持久化策略：AOF日誌 

 AOF日誌的全稱是Append Only File，從名字上咱們就能看出來，它是一個追加寫入的日誌文件。與通常數據庫不一樣的是，AOF文件是可識別的純文本，它的內容就是一個個的Redis標準命令。

AOF的優點：

    1). 該機制能夠帶來更高的數據安全性，即數據持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不一樣步。事實上，每秒同步也是異步完成的，其效率也是很是高的，所差的是一旦系統出現宕機現象，

　　　那麼這一秒鐘以內修改的數據將會丟失。而每修改同步，咱們能夠將其視爲同步持久化，即每次發生的數據變化都會被當即記錄到磁盤中。能夠預見，這種方式在效率上是最低的。至於無同步，無需多言，我想你們都能正確的理解它。
    2). 因爲該機制對日誌文件的寫入操做採用的是append模式，所以在寫入過程當中即便出現宕機現象，也不會破壞日誌文件中已經存在的內容。然而若是咱們本次操做只是寫入了一半數據就出現了系統崩潰問題，不用擔憂，

　　   在Redis下一次啓動以前，咱們能夠經過redis-check-aof工具來幫助咱們解決數據一致性的問題。
    3). 若是日誌過大，Redis能夠自動啓用rewrite機制。即Redis以append模式不斷的將修改數據寫入到老的磁盤文件中，同時Redis還會建立一個新的文件用於記錄此期間有哪些修改命令被執行。所以在進行rewrite切換時能夠更好的保證數據安全性。
    4). AOF包含一個格式清晰、易於理解的日誌文件用於記錄全部的修改操做。事實上，咱們也能夠經過該文件完成數據的重建。

要使用這種方式，須要修改redis.windows.conf文件

重啓服務，在客戶端執行如下操做

而後打開appendonly.aof，這個文件是在重啓服務後建立的

能夠看到文件記錄了每次的操做。固然get操做不會記錄

 另外AOF日誌也不是徹底按客戶端的請求來生成日誌的，好比命令 INCRBYFLOAT 在記AOF日誌時就被記成一條SET記錄，由於浮點數操做可能在不一樣的系統上會不一樣，因此爲了不同一份日誌在不一樣的系統上生成不一樣的數據集，因此這裏只將操做後的結果經過SET來記錄。 

 

與rdb同樣，aof也是經過配置文件來設置持久化的，

 

　　一、appendfsync no 

 　　當設置appendfsync爲no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁盤，因此這一切就徹底依賴於操做系統的調試了。對大多數Linux操做系統，是每30秒進行一次fsync，將緩衝區中的數據寫到磁盤上。 

 　　二、appendfsync everysec （默認）

 　　當設置appendfsync爲everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩衝區中的數據寫到磁盤。可是當這一 次的fsync調用時長超過1秒時。Redis會採起延遲fsync的策略，再等一秒鐘。也就是在兩秒後再進行fsync，

　　這一次的fsync就無論會執行多長時間都會進行。這時候因爲在fsync時文件描述符會被阻塞，因此當前的寫操做就會阻塞。 

　　因此，結論就是：在絕大多數狀況下，Redis會每隔一秒進行一次fsync。在最壞的狀況下，兩秒鐘會進行一次fsync操做。 

　　三、appednfsync always 

　　當設置appendfsync爲always時，每一次寫操做都會調用一次fsync，這時數據是最安全的，固然，因爲每次都會執行fsync，因此其性能也會受到影響。 

 

AOF重寫

每一條寫命令都生成一條日誌,AOF文件會很大

 AOF重寫是從新生成一份AOF文件，新的AOF文件中一條記錄的操做只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的屢次操做。其生成過程和RDB相似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程當中，全部的寫操做日誌仍是會寫到原來老的 AOF文件中，同時還會記錄在內存緩衝區中。當重完操做完成後，會將全部緩衝區中的日誌一次性寫入到臨時文件中。而後調用原子性的rename命令用新的 AOF文件取代老的AOF文件

爲了試驗，我屢次對key1進行了操做，在aof文件中，記錄以下

如今來看看aof重寫，這樣的aof文件會是什麼樣子

再看下面的操做

 

 從試驗結果看，AOF重寫，將同一條記錄（好比key1）的屢次操做，在寫入日誌的時候都只記錄一次。

數據恢復：

• 若是隻配置AOF,重啓時加載AOF文件恢復數據；
• 若是同時 配置了RBD和AOF,啓動是隻加載AOF文件恢復數據;
• 若是隻配置RBD,啓動是講加載dump文件恢復數據。

 

RDB和AOF同時工做會怎麼樣

（1）若是RDB在執行snapshotting操做，那麼redis不會執行AOF rewrite；若是redis在執行AOF rewrite，那麼就不會執行RDB snapshotting操做。

（2）若是RDB在執行snapshotting，此時用戶主動執行BGREWRITEAOF命令，那麼要等到RDB快照生成完以後，纔會執行AOF rewrite。

（3）同時有RDB snapshotting文件和AOF日誌，那麼redis重啓的時候，會優先使用AOF進行數據恢復，由於其中的日誌更完整，這點已經屢次強調過了。

（
做者：一寂知千秋
連接：https://www.jianshu.com/p/bd074bdea9b9
來源：簡書
簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。）

 

redis分佈式的簡單實現

這裏主要是實現讀寫的分離，將redis下載下來後，分別解壓到兩個文件夾M(主)和S(從)。

主服務的配置別動，打開從服務的配置文件redis.windows.conf，須要修改兩個地方

　　

• 修改從服務綁定端口（修改時能夠直接搜索port關鍵字）

　　　　 

　　　　這裏原本是6379，主服務的端口就是6379,如今從服務改爲6380

• 修改從服務對應的主服務地址（修改時能夠直接搜索slaveof關鍵字）

 　　　　

　　　　這裏原本是沒有這行的，如今添加上。

而後分別啓動主從服務

 

打開主服務的客戶端，添加一個簡單的數據

再打開從服務的客戶端，來獲取剛纔寫入的數據

 

 能夠看到，在從服務中是不能寫入數據的。