Redis總結筆記

Redis總結筆記 

應用場景

1. 緩存——熱數據
2. 計算器
3. 隊列
4. 位操做
5. 分佈式鎖與單線程機制
6. 最新列表
7. 排行榜

 

Maxmemory-policy算法

1. volatile-lru：使用LRU算法移除key，只對設置了過時時間的鍵。
2. allkeys-lru：使用LRU算法移除key。
3. volatile-random：在過時集合中移除隨機的key，只對設置了過時的時間的鍵。
4. allkeys-random：移除隨機的key。
5. volatile-ttl：移除那些TTL值最小的key，即那些最近要過時的key。
6. noeviction：不進行移除。針對寫操做，只返回錯誤信息。

 

RDB

介紹 

　　RDB是整個內存在壓縮過的Snapshot，RDB的數據結構，能夠配置複合的快照觸發條件。默認：

　　是1分鐘內改了1萬次，

　　或5分鐘內改了10次，

　　或15分鐘內該了1次。

小總結

• RDB是一個很是緊湊的文件。
• RDB在保存RDB文件是父進程惟一須要作的就是fork出一個紫禁城，接下來的工做所有由子進程來作，父進程不須要再作其餘I/O操做，因此RDB持久化方式能夠最大化Redis的性能。
• 與AOF相比，在回覆大的數據集的時候，RDB方式會更快一些。
• 數據丟失風險大。
• RDB須要常常fork子進程來保存數據集到硬盤上，當數據集比較大的時候，fork的進程過程是很是耗時的，可能會致使Redis在一些毫秒級不能響應客戶端請求。

 

AOF

　　是什麼

　　AOF保存的是appendonly.aof文件

　　配置位置

　　AOF啓動/修復/恢復

　　Rewrite

優點

劣勢

小總結

• AOF文件是一個只進行追加的日誌文件。
• Redis能夠在AOF文件體積變得過大時，自動地在後臺對AOF進行重寫。
• AOF文件有序地保存了對數據庫執行的全部寫入操做，這些寫入操做以Redis協議的格式保存，所以AOF文件的內容很是容易被人讀懂，對文件進行分析也很輕鬆。
• 對於相同的數據集來講，AOF文件的體積一般要大於RDB文件的體積。
• 根據所使用的fsync策略，AOF的速度可能會慢於RDB。

 

持久化總結

• RDB持久化方式可以在指定的時間間隔能對你的數據進行快照存儲。
• AOF持久化方式記錄每次對服務器寫的操做，當服務器重啓的時候回從新執行這些命令來恢復原始的數據，AOF命令以redis協議追加保存每次寫的操做到文件末尾。
• Redis還能對AOF文件進行後臺重寫，使得AOF文件的體積不至於過大。
• 只作緩存：若是你只但願你的數據在服務器運行的時候存在，你也能夠不使用任何持久化方式。
• 同時開啓兩種持久化方式。
• RDB的數據不實時，同時使用二者時服務器重啓也只會找AOF文件。那要不要只使用AOF呢？
• 做者建議不要，由於RDB更適合用於備份數據庫（AOF在不斷變化很差備份）。
• 快速重啓，並且不會有AOF可能潛在的BUG，留着做爲一個萬一的手段。
• 性能建議。
• 由於RDB文件只用作後備用途，建議只在Slave上持久化RDB文件，並且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。
• 若是Enable AOF，好處是在最惡劣狀況下也智慧丟失不超過兩秒的數據，啓動腳本比較簡單隻load本身的AOF文件就能夠了。代價以是帶來了持續的I/O，二是AOF rewrite的最後將rewrite過程當中產生的新數據寫到新文件形成的阻塞幾乎是不可避免的。只要硬盤許可，應該儘可能減小AOF rewrite的頻率，AOF重寫的基礎大小默認值64M大小了，能夠設到5G以上，默認超過原大小的100%大小時重寫能夠改到適當的數值。
• 若是不Enable AOF，僅靠Master-Slave Replication實現高可用也能夠，能省掉一大筆I/O也減小了rewrite時帶來的系統波動，代價是若是Master/Slave同時掛掉，會丟失十幾分鐘的數據，啓動腳本也要比較買兩個Master/Slave中的RDB文件，載入較新的那個，新浪微博就選用了這種架構。

 

事務

小結

• Watch指令相似樂觀鎖，事務提交時，若是key的值已被別的客戶端改變，好比某個list已被別的客戶端push/pop過了，整個事務隊列不會被執行。
• 經過Watch命令在事務執行以前監聽了多個keys，假若在Watch以後有任何key的值發生了變化，Exec命令執行的事務都會被放棄，同時Nullmulti-bulk應答以通知調用者事務執行失敗。

單獨的隔離操做：事務中的全部命令都會序列化、按順序地執行。事務在執行過程當中，不會被其餘客戶端發送來的命令請求所打斷。

沒有隔離級別的概念：隊列中的命令沒有提交以前都不會實際的被執行，由於事務提交前任何指令都不會被實際執行，也不會存在「事務內的查詢要看到事務裏的更新，在事務外查詢不能看到」這個讓人萬分頭疼的問題。

不保證原子性：Redis同一個事務若是有一條命令執行失敗，其後的命令仍然會被執行，沒有回滾。

 

主從複製

配置從（庫）不配主（庫）

從庫配置：slaveof主庫IP主庫端口

• 每次與master斷開以後，都須要從新鏈接，除非你配置進redis.conf文件。
• Info Replication。

修改配置文件細節操做

• 拷貝多個redis.conf文件。
• 開啓daemonize yes。
• Pid文件名字。
• 指定端口。
• Log文件名字。
• Dump.rdb名字。

經常使用三招

1. 一主二僕

• Init。
• 一個Master兩個Slave。
• 日誌查看。
• 主從問題演示。
• 能幹嗎。
• 怎麼玩。
• 複製原理。
• Slave啓動成功鏈接到Master後會發送一個sync命令。
• Master鏈接命令啓動後臺的存盤進程，同時收集全部接受到的用於修改數據命令，在後臺進程執行完畢以後，master將傳送整個數據到slave，以完成一次徹底同步。
• 全量複製：而Slave服務在接收到數據庫文件數據後，將其存盤並加載到內存中。
• 增量複製：Master繼續將新的全部收集到的修改命令一次傳給slave，完成同步，可是隻要從新鏈接master，一次徹底同步（全量複製）將被自動執行。
• 哨兵模式。
• 是什麼。
• 怎麼玩。
• 自定義/myredis目錄下新建sentinel.conf文件，名字絕對不能錯。
• 配置哨兵，填寫內容
• sentinel monitor被監控的數據庫名字（本身起名字）如：127.0.0.1 6379 1。
• 上面最後的一個數字1，表示主機掛掉後slave投票看讓誰接替爲主機，得票數多稱爲主機。
• 啓動哨兵。
• Redis-sentinel /myredis/sentinel.conf。
• 上述目錄依照各自的實際狀況配置，可能目錄不一樣。
• 正常主從演示。
• 原有的master掛了。
• 投票新選。
• 從新主從繼續開工，Info Replication查查看。
• 問題：若是以前的master從新回來，會不會master衝突？
• 一組sentinel能同時監控多個master。

 

• 複製缺點。
• 因爲全部的寫操做都是先在Master上操做，而後同步更新到Slave上，因此從Master同步到Slave機器有必定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，Slave機器數量的增長也會使這個問題變得更加嚴重。

2. 薪火相傳
3. 反客爲主

• SlaveOf no one。使當前數據庫中止與其餘數據庫同步，轉爲主數據庫。

 

 

需瞭解的問題：

1. RDB成功恢復，RDB能夠搞定備份爲何會有OAF。新技術的出現必定要彌補老技術的不足同不一樣意，新技術必定會借鑑老技術，是老技術的子類，通常子類要比父類強大？
2. 若是一個系統裏面同時存在RDB和AOF是衝突仍是協做？
3. 爲何AOF會在RDB以後產生？
4. AOF有什麼優缺點？

 

一主二從典型問題

1. 主機寫入k1，從機寫入k1，會報錯，從機只能讀。
2. 主機宕機，從機不會上位爭master，從機原地待命，若是主機從新恢復，主機寫入，從機依然能獲取到數據。
3. 從機宕機了，主機可以寫入，從機重啓後需從新鏈接主機才能獲取到主機數據，或者寫入配置中。
4. 從機備份時，是把主機的數據所有從新同步一遍。