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的安裝，所以這里只是提一下。
1、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的默認持久化的方式，所需要修改的就是上面的寫入磁盤的條件
2、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也是通過配置文件來設置持久化的，
1、appendfsync no
當設置appendfsync為no的時候，Redis不會主動調用fsync去將AOF日志內容同步到磁盤，所以這一切就完全依賴於操作系統的調試了。對大多數Linux操作系統，是每30秒進行一次fsync，將緩沖區中的數據寫到磁盤上。
2、appendfsync everysec （默認）
當設置appendfsync為everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩沖區中的數據寫到磁盤。但是當這一 次的fsync調用時長超過1秒時。Redis會采取延遲fsync的策略，再等一秒鍾。也就是在兩秒后再進行fsync，
這一次的fsync就不管會執行多長時間都會進行。這時候由於在fsync時文件描述符會被阻塞，所以當前的寫操作就會阻塞。
所以，結論就是：在絕大多數情況下，Redis會每隔一秒進行一次fsync。在最壞的情況下，兩秒鍾會進行一次fsync操作。
3、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.windows.conf，需要修改兩個地方
- 修改從服務綁定端口（修改時可以直接搜索port關鍵字）
這里本來是6379，主服務的端口就是6379,現在從服務改成6380
- 修改從服務對應的主服務地址（修改時可以直接搜索slaveof關鍵字）
這里本來是沒有這行的，現在添加上。
然后分別啟動主從服務
打開主服務的客戶端，添加一個簡單的數據
再打開從服務的客戶端，來獲取剛才寫入的數據
