終於把redis系統的學習了一遍，結合redis深度歷險把知識點整理一下。
Redis 基礎數據結構
String: 字符串
Hash: 散列
List: 列表
Set: 集合
Sorted Set: 有序集合
-------
分佈式鎖
業務場景
業務數據的特殊性
1. 原始業務功能設計
2. 秒殺
3. 618活動
4. 雙11活動
5. 排隊購票
運營平臺監控到的突發高頻訪問數據
1. 突發時政要聞，被強勢關注圍觀
高頻、複雜的統計數據
1.在線人數
2.投票排行榜
String
Tips 1：redis用於控制數據庫表主鍵id，爲數據庫表主鍵提供生成策略，保障數據庫表的主鍵唯一性
Tips 2：redis 控制數據的生命週期，通過數據是否失效控制業務行爲，適用於所有具有時效性限定控制的操作 (一定時間內vip試用，每天3票)
Tips 3：redis應用於各種結構型和非結構型高熱度數據訪問加速 （粉絲數量）
hash
Tips 4：redis 應用於購物車數據存儲設計
Tips 5：redis 應用於搶購，限購類、限量發放優惠卷、激活碼等業務的數據存儲設計
list
Tips 6：redis 應用於具有操作先後順序的數據控制 (關注的人，微信消息的顯示順序，點贊與取消點贊)
Tips 7：redis 應用於最新消息展示 （新的新聞資訊）
依賴list的數據具有順序的特徵對信息進行管理
使用隊列模型解決多路信息彙總合併的問題
使用棧模型解決最新消息的問題
set
Tips 8：redis 應用於隨機推薦類信息檢索，例如熱點歌單推薦，熱點新聞推薦，熱賣旅遊線路，應用APP推薦，大V推薦等
系統分析出各個分類的最新或最熱點信息條目並組織成set集合
隨機挑選其中部分信息
配合用戶關注信息分類中的熱點信息組織成展示的全信息集合
Tips 9：redis 應用於同類信息的關聯搜索，二度關聯搜索，深度關聯搜索 （有幾位好友也關注了公衆號，可能認識的人）
顯示共同關注（一度）
顯示共同好友（一度）
由用戶A出發，獲取到好友用戶B的好友信息列表（一度）
由用戶A出發，獲取到好友用戶B的購物清單列表（二度）
由用戶A出發，獲取到好友用戶B的遊戲充值列表（二度）
Tips 10：redis 應用於同類型不重複數據的合併、取交集操作
Tips 11：redis 應用於同類型數據的快速去重
公司對旗下新的網站做推廣，統計網站的PV（訪問量）,UV（獨立訪客）,IP（獨立IP）。
PV：網站被訪問次數，可通過刷新頁面提高訪問量
UV：網站被不同用戶訪問的次數，可通過cookie統計訪問量，相同用戶切換IP地址，UV不變
IP：網站被不同IP地址訪問的總次數，可通過IP地址統計訪問量，相同IP不同用戶訪問，IP不變
利用set集合的數據去重特徵，記錄各種訪問數據
建立string類型數據，利用incr統計日訪問量（PV）
建立set模型，記錄不同cookie數量（UV）
建立set模型，記錄不同IP數量（IP）
Tips 12：redis 應用於基於黑名單與白名單設定的服務控制（爬蟲的地址或者用戶）
基於經營戰略設定問題用戶發現、鑑別規則
週期性更新滿足規則的用戶黑名單，加入set集合
用戶行爲信息達到後與黑名單進行比對，確認行爲去向
黑名單過濾IP地址：應用於開放遊客訪問權限的信息源
黑名單過濾設備信息：應用於限定訪問設備的信息源
黑名單過濾用戶：應用於基於訪問權限的信息源
zset
Tips 13：redis 應用於計數器組合排序功能對應的排名
Tips 14：redis 應用於定時任務執行順序管理或任務過期管理 ( 網站會定期開啓投票、討論，限時進行，逾期作廢。如何有效管理此類過期信息。 )
對於基於時間線限定的任務處理，將處理時間記錄爲score值，利用排序功能區分處理的先後順序
記錄下一個要處理的時間，當到期後處理對應任務，移除redis中的記錄，並記錄下一個要處理的時間
當新任務加入時，判定並更新當前下一個要處理的任務時間
爲提升sorted_set的性能，通常將任務根據特徵存儲成若干個sorted_set。例如1小時內，1天內，周內， 月內，季內，年度等，操作時逐級提升，將即將操作的若干個任務納入到1小時內處理的隊列中
Tips 15：redis 應用於及時任務/消息隊列執行管理
對於帶有權重的任務，優先處理權重高的任務，採用score記錄權重即可 多條件任務權重設定 如果權重條件過多時，需要對排序score值進行處理，保障score值能夠兼容2條件或者多條件，例如外貿 訂單優先於國內訂單，總裁訂單優先於員工訂單，經理訂單優先於員工訂單
因score長度受限，需要對數據進行截斷處理，尤其是時間設置爲小時或分鐘級即可（折算後）
先設定訂單類別，後設定訂單發起角色類別，整體score長度必須是統一的，不足位補0。第一排序規則首 位不得是0
例如外貿101，國內102，經理004，員工008。
員工下的外貿單score值爲101008（優先） 經理下的國內單score值爲102004
擴展
Tips 16：redis 應用於按次結算的服務控制 (現時會員體驗次數)
Tips 17：redis 應用於基於時間順序的數據操作，而不關注具體時間 （使用微信的過程中，當微信接收消息後，會默認將最近接收的消息置頂，當多個好友及關注的訂閱號同時發 送消息時，該排序會不停的進行交替。同時還可以將重要的會話設置爲置頂）
依賴list的數據具有順序的特徵對消息進行管理，將list結構作爲棧使用
對置頂與普通會話分別創建獨立的list分別管理
當某個list中接收到用戶消息後，將消息發送方的id從list的一側加入list（此處設定左側）
多個相同id發出的消息反覆入棧會出現問題，在入棧之前無論是否具有當前id對應的消息，先刪除對應id
推送消息時先推送置頂會話list，再推送普通會話list，推送完成的list清除所有數據
消息的數量，也就是微信用戶對話數量採用計數器的思想另行記錄，伴隨list操作同步更新
redis 持久化
RDB
數據 （快照）
AOF
過程 （日誌）
：以獨立日誌的方式記錄每次寫命令，重啓時再重新執行AOF文件中命令 達到恢復數據的目的。與RDB相比可以簡單描述爲改記錄數據爲記錄數據產生的過程
RDB與AOF的選擇
雙保險策略，同時開啓 RDB 和 AOF，重啓後，Redis優先使用 AOF 來恢復數據，降低丟失數據的量
RDB啓動方式 —— save指令
save指令的執行會阻塞當前Redis服務器，直到當前RDB過程完成爲止，有可能會造成長時間阻塞，線上環境不建議使用
RDB啓動方式 —— bgsave指令
bgsave命令是針對save阻塞問題做的優化。Redis內部所有涉及到RDB操作都採用bgsave的方式，save命令可以放棄使用。
save配置
滿足限定時間範圍內key的變化數量達到指定數量即進行持久化
second：監控時間範圍
changes：監控key的變化量
rdb特殊啓動形式 主從複製。
RDB 優點
RDB是一個緊湊壓縮的二進制文件，存儲效率較高
RDB內部存儲的是redis在某個時間點的數據快照，非常適合用於數據備份，全量複製等場景
RDB恢復數據的速度要比AOF快很多
應用：服務器中每X小時執行bgsave備份，並將RDB文件拷貝到遠程機器中，用於災難恢復。
RDB 缺點
RDB方式無論是執行指令還是利用配置，無法做到實時持久化，具有較大的可能性丟失數據
bgsave指令每次運行要執行fork操作創建子進程，要犧牲掉一些性能
Redis的衆多版本中未進行RDB文件格式的版本統一，有可能出現各版本服務之間數據格式無法兼容現象
AOF寫數據三種策略(appendfsync)
always(每次） 每次寫入操作均同步到AOF文件中，數據零誤差，性能較低
everysec（每秒） 每秒將緩衝區中的指令同步到AOF文件中，數據準確性較高，性能較高 在系統突然宕機的情況下丟失1秒內的數據
no（系統控制） 由操作系統控制每次同步到AOF文件的週期，整體過程不可控
AOF重寫
是將對同一個數據的若干個條命令執行結 果轉化成最終結果數據對應的指令進行記錄。
AOF重寫作用
降低磁盤佔用量，提高磁盤利用率
提高持久化效率，降低持久化寫時間，提高IO性能
降低數據恢復用時，提高數據恢復效率
AOF重寫規則
進程內已超時的數據不再寫入文件
忽略無效指令，重寫時使用進程內數據直接生成，這樣新的AOF文件只保留最終數據的寫入命令
對同一數據的多條寫命令合併爲一條命令 ，爲防止數據量過大造成客戶端緩衝區溢出，對list、set、hash、zset等類型，每條指令最多寫入64個元素
AOF重寫方式
手動重寫 ： bgrewriteaof
自動重寫 ： auto-aof-rewrite-min-size size / auto-aof-rewrite-percentage percentage
主從複製
互聯網“三高”架構
高併發
高性能
高可用 (99.99%)
爲了避免單點Redis服務器故障，準備多臺服務器，互相連通。將數據複製多個副本保存在不同的服 務器上，連接在一起，並保證數據是同步的。即使有其中一臺服務器宕機，其他服務器依然可以繼續 提供服務，實現Redis的高可用，同時實現數據冗餘備份。
主從複製過程大體可以分爲3個階段
建立連接階段（即準備階段）
數據同步階段
命令傳播階段
命令傳播階段的部分複製
命令傳播階段出現了斷網現象
網絡閃斷閃連 忽略
短時間網絡中斷 部分複製
長時間網絡中斷 全量複製
部分複製的三個核心要素
服務器的運行 id（run id）
主服務器的複製積壓緩衝區
主從服務器的複製偏移量
主從複製 常見問題
哨兵模式
哨兵(sentinel) 是一個分佈式系統，用於對主從結構中的每臺服務器進行監控，當出現故障時通過投票機制選擇新的 master並將所有slave連接到新的master。
哨兵工作原理
主從切換
哨兵在進行主從切換過程中經歷三個階段
監控
通知
故障轉移
1服務器列表中挑選備選master
在線的
響應慢的
與原master斷開時間久的 （說明網好，第一時間就知道了）
優先原則
--優先級
--offset
--runid
2發送指令（ sentinel ）
向新的master發送slaveof no one
向其他slave發送slaveof 新masterIP端口
集羣
集羣就是使用網絡將若干臺計算機聯通起來，並提供統一的管理方式，使其對外呈現單機的服務效果
集羣作用
分散單臺服務器的訪問壓力，實現負載均衡
分散單臺服務器的存儲壓力，實現可擴展性
降低單臺服務器宕機帶來的業務災難
Redis 事務
redis事務就是一個命令執行的隊列，將一系列預定義命令包裝成一個整體（一個隊列）。當執行時，一次性 按照添加順序依次執行，中間不會被打斷或者干擾。
一個隊列中，一次性、順序性、排他性的執行一系列命令