上一章博客redis學習---上講的是redis常用的數據類型，接下來講的是redis的持久化和主從複製與哨兵模式、事務、發佈訂閱。

一、redis持久化

redis持久化分爲rdb 和aof這兩種。其中rdb是默認開啓的，aof是默認關閉的。

1.rdb

1.1 rdb介紹：

在指定的時間間隔內將內存中的數據集快照寫入磁盤。

也就是行話將的Snapshot快照，它回覆時時將快照文件直接讀到內存裏。

1.2 rdb的工作流程：

Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。

整個過程中，主進程時不進行任何IO操作的，這就確保了極高的性能。

1.3 rdb的設置及操作：

如果需要進行大規模數據的恢復，且對於數據的恢復的完成性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點時最後一次持久化後的數據可能丟失。

備份默認設置：save 60 10000 （可以在配置文件中修改）
是1分鐘內改了1萬次，或5分鐘內改了10次，或15分鐘內改了1次。

停止使用rdb：config set save ""

1.4 快照操作：

① save直接保存其他不管。
② bgsave會在後臺異步進行快照操作，快照同時還可以響應客戶的請求。可以通過lastsave命令獲取最後一次成功執行快照的時間。
③ 執行flushall 也會產生dump.rdb文件，但是裏面是空的，無意義。

1.5 rdb的優劣勢

rdb的優勢：適合大規模的數據恢復，對數據完整性和一直性要求不高。
rdb的劣勢：在一定間隔時間做一次備份，所以如果redis意外的down掉的話，就會丟失最後一次快照後的所以修改。Fork的時候，內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮。

2. aof

2.1 aof介紹

以日誌的形式來記錄每個寫操作，將redis執行過的所有寫指令記錄下來（讀取操作不記錄），只許追加文件但不可以改寫文件，redis啓動之初會讀取該文件重新構建數據，換言之，redis重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作。

2.2 aof修復及加載

如果aof和rdb同時存在，先加載aof。
aof錯誤修復 redis-check-aof --fix **.aof

2.3 aof持久化策略的配置

no 表示不執行fsync，由操作系統保證數據同步到磁盤，速度最快。

always 表示每次寫入都執行fsync，以保證數據同步到磁盤。

everysec 表示每秒執行一次fsync，可能會導致丟失這1s數據。

appendfsync everysec

rewrite 默認是64M 100%的時候增加一倍

2.4 aof的優劣勢

aof的優勢：

①每秒同步：appendfsync always 同步持久化每次發生數據變更會被立即記錄到磁盤，性能較差但數據完整性比較好。

② 每修改同步：appendfsyns everysec 異步操作，每秒記錄如果一秒內宕機，有數據丟失。

③ appendfsync no 從不同步

aof的劣勢：

① 相同數據集的數據而言aof文件要遠大於rdb文件，恢復速度慢與rdb

② aof運行效率要慢與rdb，每秒同步策略效率較好，不同步效率和rdb相同

3. rdb和aof的總結

3.1 rdb持久化方式能夠在制定的時間間隔能對你的數據進行快照存儲。

3.2 aof持久化方式記錄每次對服務器寫的操作，當服務器重啓的時候會重新執行這些命令來恢復原始的數據，aof命令以redis協議追加保存每次寫的操作的文件末尾。redis還能對aof文件進行後臺的重寫，使得aof文件的體積不至於過大。

3.3 只做緩存：如果你希望你的數據在服務器運行的時候存在，你也可以不使用任何持久化方式。

3.4 同事開啓兩種持久化方式：

3.4.1 在這種情況下，當redis重啓的時候會優先載入aof文件來恢復原始的數據，因爲在通常情況下 aof文件保存的數據集要比rdb文件保存的數據集要完整。

3.4.2 rdb的數據不實時，同時使用兩者時服務器重啓也只會找aof文件。那要不要只使用aof呢？作者建議不要，因爲rdb更適合用於備份數據庫（aof在不斷的變化不好備份），快速重啓，而且不會有aof 可能潛在的bug，留着作一個萬一的手段。

二、redis事務

1.1 redis事務介紹

可以一次執行多個命令，本質是一組命令的集合。一個事務中的所有命令都會序列化，按順序地串行化執行而不會被其它命令插入，不許加塞。

1.2 redis事務做什麼

一個隊列中，一次性、順序性、排他性的執行一系列命令。

1.3 事務的命令

discard：取消事務，放棄執行事務快內的所以命令，
exec：執行所有事務塊內的命令。
multi：標記一個事務塊的開始。
unwatch：取消watch命令所有key的監視。

atch key...：監視一個或多個key，如果在事務執行之前這個或這些key被其他命令所修改，那麼事務將被打斷，一旦執行exec之前加的監控鎖都會被取消掉了。

1.4 事務小結

watch指令，類似樂觀鎖，事務提交時，如果key的值已被別的客戶端改變，比如某個list已被別的客戶端push/pop過了，整個事務隊列都不會被執行。

通過watch命令在事務執行之前監控了多個Keys，倘若在watch之後有任何key的值發生了變化，exec命令執行的事務都將被放棄，同時發回Nullmulti-bulk應答以通知調用者事務執行失敗。

三、redis的發佈訂閱

1.1 redis的發佈訂閱介紹

進程間的一種消息通信模式：發送者（pub）發送消息，訂閱者（sub）接受消息。

1.2 redis的發佈訂閱操作

訂閱命令：subscribe 頻道1 頻道2 頻道3

發送消息：publish 頻道消息

訂閱的終端你就會接受到相應頻道發送的消息。

四、redis的複製（Master/Slave）

1.1 redis複製介紹

行話：也就是我們所說的主從複製，主機數據更新後根據配置和策略，自動同步到備機的master、slaver機制，master以寫爲主，slave以讀爲主。

1.2 主從複製作用

1.2.1 讀寫分離。

1.2.2 災難恢復。

1.3 操作

1.3.1 配從（庫）不配主（庫）

1.3.2 從庫配置：slaveof 主庫ip 主庫端口注意：每次與master斷開之後，都需要重新連接，除非你配

置redis.conf文件Info replication。

1.3.3 查看redis服務啓動：info replication

1.3.4 備份主機數據：slaveof ip 端口號

主要是從機slave 就會拷貝主機的所有數據

從庫轉主庫：slaveof no one

1.4 主從複製情況

1.4.1 主機添加數據，配置從機後從機會從主機同步全部數據。

1.4.2 主機有相應的鍵值數據，從機不能覆蓋主機的鍵值。

1.4.3 主機宕機後，從機不宕機，那麼從機還是從機保持不變。但是主機重啓後從機會同步主機的全部數據。

1.4.4 從機宕機後，主機保持不變，那麼從機重啓後就變成主機，除非重新命令成爲從機或者寫入配置文件中。

1.4.5 主從機確定後，從機的數據和主機完全保持一致。從機原有的數據會被刪除。

1.5 主從複製原理

1.5.1 Slave啓動成功連接到master後會發送一個sync命令。

1.5.2 Master接到命令啓動後臺的存盤進程，同時收集所有接收到的用於修改數據集的命令，在後臺進程執行完畢之後，master將傳送整個數據文件到slave，以完成一次完全同步。

1.5.3 複製分爲：

① 全量複製：而slave服務在接收到數據庫文件數據後，將其存盤並加載到內存中。

② 增量複製：Master繼承將新的所有收集到的修改命令依次傳給slave，完成同步

1.5.4 但是隻要重新連接master，一次完成同步（全量複製）將被自動執行。

五、哨兵模式

1. 哨兵模式介紹

反客爲主的自動版,能夠後臺監控主機是否故障，如果故障了根據投票數自動將從庫轉換爲主庫。

2. 哨兵模式配置

2.1 自定義sentinel.conf文件，名字絕對不能錯。

2.2 配置哨兵，填寫內容：

2.2.1 sentinel monitor 被監控數據庫（自己起的名字）ip（127.0.0.1 端口號（6379）1（票數）

2.2.2 最後一位是票數，表示主機掛掉後salve投票看讓誰接替成爲主機，得票數多少後成爲主機。

2.2.3 啓動哨兵：Redis-sentinel /**/sentinel.conf目錄按照實際創建的sentinel.conf文件爲主。

2.2.4 當master掛掉之後，投票開始，有可能選不出主機會繼續選擇。選中主機後重新主從繼續開工，可以通過info replication查查看。

2.2.5 當之前宕掉的master重新啓動回來，不會和現在的master衝突，會變成從機繼續工作。

一組sentinel能夠同時監控多個Master。

3. 複製的缺點（哨兵模式和主從複製）

複製延時：由於所有的寫操作都是先在Master上操作，然後同步更新到slave上，所以從master同步到slave機器有一定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，slave機器數量的增加也會使這個問題更加嚴重。

實例：

public class jedisTest {
	public static void main(String[] args) 
	{
		Jedis jedis = new Jedis("127.0.0.1",6379);
		
		System.out.println(jedis.ping());
		
		jedis.set("k1","v1");
		jedis.set("k2","v2");
		jedis.set("k3","v3");
		
		
		System.out.println(jedis.get("k3"));
		
		Set<String> sets = jedis.keys("*");
		System.out.println(sets.size());
		
		
	}
}

以上就是redis的學習，介紹了redis部分功能。如果要和java連接，下載jedis-2.1.0.jar和commons-pool-1.6.jar。然後就可以在java中操作redis。

轉載請標明：http://blog.csdn.net/whm114336793/article/details/78634722

redis學習---下