Redis總結筆記
應用場景
- 緩存——熱數據
- 計算器
- 隊列
- 位操作
- 分佈式鎖與單線程機制
- 最新列表
- 排行榜
Maxmemory-policy算法
- volatile-lru：使用LRU算法移除key，只對設置了過期時間的鍵。
- allkeys-lru：使用LRU算法移除key。
- volatile-random：在過期集合中移除隨機的key，只對設置了過期的時間的鍵。
- allkeys-random：移除隨機的key。
- volatile-ttl：移除那些TTL值最小的key，即那些最近要過期的key。
- 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名字。
常用三招
- 一主二僕
- 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機器數量的增加也會使這個問題變得更加嚴重。
- 薪火相傳
- 反客爲主
- SlaveOf no one。使當前數據庫停止與其他數據庫同步，轉爲主數據庫。
需瞭解的問題：
- RDB成功恢復，RDB可以搞定備份爲什麼會有OAF。新技術的出現一定要彌補老技術的不足同不同意，新技術一定會借鑑老技術，是老技術的子類，一般子類要比父類強大？
- 如果一個系統裏面同時存在RDB和AOF是衝突還是協作？
- 爲什麼AOF會在RDB之後產生？
- AOF有什麼優缺點？
一主二從典型問題
- 主機寫入k1，從機寫入k1，會報錯，從機只能讀。
- 主機宕機，從機不會上位爭master，從機原地待命，如果主機重新恢復，主機寫入，從機依然能獲取到數據。
- 從機宕機了，主機能夠寫入，從機重啓後需重新連接主機才能獲取到主機數據，或者寫入配置中。
- 從機備份時，是把主機的數據全部重新同步一遍。