緩存好處：高性能 + 高並發
數據庫查詢耗費了800ms，其他用戶對同壹個數據再次查詢 ，假設該數據在10分鐘以內沒有變化過，並且 10 分鐘之內有 1000 個用戶 都查詢了同壹數據，10 分鐘之內，那 1000 每個用戶，每個人查詢這個數據都感覺很慢 800ms
比如 ：某個商品信息，在 壹天之內都不會改變，但是這個商品每次查詢壹次都要耗費2s，壹天之內被瀏覽 100W次
mysql 單機也就 2000qps,緩存單機輕松幾萬幾十萬qps,單機 承載並發量是 mysql 單機的幾十倍。
在中午高峰期，有 100W 個用戶訪問系統 A，每秒有 4000 個請求去查詢數據庫，數據庫承載每秒 4000 個請求會宕機，加上緩存後，可以 3000 個請求走緩存 ，1000 個請求走數據庫。
緩存是走內存的，內存天然可以支撐4w/s的請求，數據庫（基於磁盤）壹般建議並發請求不要超過 2000/s
redis 單線程 ，memcached 多線程
redis 是單線程 nio 異步線程模型
壹個線程+壹個隊列
redis 基於 reactor 模式開發了網絡事件處理器，這個處理器叫做文件事件處理器，file event handler，這個文件事件處理器是單線程的，所以redis 是單線程的模型，采用 io多路復用機制同時監聽多個 socket,根據socket上的事件來選擇對應的事件處理器來處理這個事件。
文件事件處理器包含：多個 socket,io多路復用程序，文件事件分派器，事件處理器（命令請求處理器、命令恢復處理器、連接應答處理器）
文件事件處理器是單線程的，通過 io 多路復用機制監聽多個 socket，實現高性能和線程模型簡單性
被監聽的 socket 準備好執行 accept,read,write,close等操作的時候，會產生對應的文件事件，調用之前關聯好的時間處理器處理
多個 socket並發操作，產生不同的文件事件，i/o多路復用會監聽多個socket，將這些 socket放入壹個隊列中排隊。事件分派器從隊列中取出socket給對應事件處理器。
壹個socket時間處理完後，事件分派器才能從隊列中拿到下壹個socket，給對應事件處理器來處理。
文件事件：
AE_READABLE 對應 socket變得可讀（客戶端對redis執行 write操作）
AE_WRITABLE 對應 socket 變得可寫（客戶端對 redis執行 read操作）
I/O 多路復用可以同時監聽AE_REABLE和 AE_WRITABLE ，如果同時達到則優先處理 AE_REABLE 時間
文件事件處理器：
連接應答處理器 對應 客戶端要連接 redis
命令請求處理器 對應 客戶端寫數據到 redis
命令回復處理器 對應 客戶端從 redis 讀數據
流程：
壹秒鐘可以處理幾萬個請求
普通的 set,get kv緩存
類型 map結構，比如壹個對象（沒有嵌套對象）緩存到 redis裏面，然後讀寫緩存的時候，可以直接操作hash的字段（比如把 age 改成 21，其他的不變）
key=150
value = {
}
有序列表 ，元素可以重復
可以通過 list 存儲壹些列表型數據結構，類似粉絲列表，文章評論列表。
例如：微信大 V的粉絲，可以以 list 的格式放在 redis 裏去緩存
key=某大 V value=[zhangsan,lisi,wangwu]
比如 lrange 可以從某個元素開始讀取多少個元素，可以基於 list 實現分頁查詢功能，基於 redis實現高性能分頁，類似微博下來不斷分頁東西。
可以搞個簡單的消息隊列，從 list頭懟進去（lpush），list尾巴出來 (brpop)
無序集合，自動去重
需要對壹些數據快速全局去重，（當然也可以基於 HashSet，但是單機）
基於 set 玩差集、並集、交集的操作。比如：2 個人的粉絲列表整壹個交集，看看 2 個人的***同好友是誰？
把 2 個大 V 的粉絲都放在 2 個 set中，對 2 個 set做交集（sinter）
排序的 set，去重但是可以排序，寫進去的時候給壹個分數，自動根據分數排序
排行榜：
zadd board score username
例如：
zadd board 85 zhangsan
zadd board 72 wangwu
zadd board 96 lis
zadd board 62 zhaoliu
自動排序為：
96 lisi
85 zhangsan
72 wangwu
62 zhaoliu
獲取排名前 3 的用戶 ： zrevrange board 0 3
96 lisi
85 zhangsan
72 wangwu
查看zhaoliu的排行 ：zrank board zhaoliu 返回 4
內存是寶貴的，磁盤是廉價的
給key設置過期時間後，redis對這批key是定期刪除+惰性刪除
定期刪除：
redis 默認每隔 100ms隨機抽取壹些設置了過期時間的 key，檢查其是否過期了，如果過期就刪除。
註意：redis是每隔100ms隨機抽取壹些 key來檢查和刪除，而不是遍歷所有的設置過期時間的key（否則CPU 負載會很高，消耗在檢查過期 key 上）
惰性刪除：
獲取某個key的時候， redis 會檢查壹下，這個key如果設置了過期時間那麽是否過期，如果過期了則刪除。
如果定期刪除漏掉了許多過期key，然後妳也沒及時去查，也沒走惰性刪除，如果大量過期的key堆積在內存裏，導致 redis 內存塊耗盡，則走內存淘汰機制。
內存淘汰策略：
LRU 算法：
緩存架構（多級緩存架構、熱點緩存）
redis 高並發瓶頸在單機，讀寫分離，壹般是支撐讀高並發，寫請求少，也就 壹秒壹兩千，大量請求讀，壹秒鐘二十萬次。
壹主多從，主負責寫，將數據同步復制到其他 slave節點，從節點負責讀，所有讀的請求全部走從節點。主要是解決讀高並發。、
主從架構->讀寫分離->支撐10W+讀QPS架構
master->slave 復制，是異步的
核心機制：
master持久化對主從架構的意義：
如果開啟了主從架構，壹定要開啟 master node的持久化，不然 master宕機重啟數據是空的，壹經復制，slave的數據也丟了
主從復制原理：
第壹次啟動或者斷開重連情況：
正常情況下：
master 來壹條數據，就異步給 slave
全年 99.99%的時間，都是出於可用的狀態，那麽就可以稱為高可用性
redis 高可用架構叫故障轉移，failover，也可以叫做主備切換，切換的時間不可用，但是整體高可用。
sentinal node(哨兵)
作用：
quorum = 1 （代表哨兵最低個數可以嘗試故障轉移，選舉執行的哨兵）
master 宕機，只有 S2 存活，因為 quorum =1 可以嘗試故障轉移，但是沒達到 majority =2 （最低允許執行故障轉移的哨兵存活數）的標準，無法執行故障轉移
如果 M1 宕機了，S2,S3 認為 master宕機，選舉壹個執行故障轉移，因為 3 個哨兵的 majority = 2，所以可以執行故障轉移
丟數據：
解決方案：
sdown 主觀宕機，哨兵覺得壹個 master 宕機（ping 超過了 is-master-down-after-milliseconds毫秒數）
odown 客觀宕機，quorum數量的哨兵都覺得 master宕機
哨兵互相感知通過 redis的 pub/sub系統，每隔 2 秒往同壹個 channel裏發消息（自己的 host,ip,runid），其他哨兵可以消費這個消息
以及同步交換master的監控信息。
哨兵確保其他slave修改master信息為新選舉的master
當壹個 master被認為 odown && marjority哨兵都同意，那麽某個哨兵會執行主備切換，選舉壹個slave成為master（考慮 1. 跟master斷開連接的時長 2. slave 優先級 3.復制 offset 4. runid）
選舉算法：
quorum 數量哨兵認為odown->選舉壹個哨兵切換->獲得 majority哨兵的授權（quorum majority 需要 majority個哨兵授權，quorum >= majority 需要 quorum 哨兵授權）
第壹個選舉出來的哨兵切換失敗了，其他哨兵等待 failover-time之後，重新拿confiuration epoch做為新的version 切換，保證拿到最新配置，用於 configuration傳播（通過 pu/sub消息機制，其他哨兵對比 version 新舊更新 master配置）
高並發：主從架構
高容量：Redis集群，支持每秒幾十萬的讀寫並發
高可用：主從+哨兵
持久化的意義在於故障恢復數據備份（到其他服務器）+故障恢復（遇到災難，機房斷電，電纜被切）
AOF 只有壹個，Redis 中的數據是有壹定限量的，內存大小是壹定的,AOF 是存放寫命令的，當大到壹定的時候，AOF 做 rewrite 操作，就會基於當時 redis 內存中的數據，來重新構造壹個更小的 AOF 文件，然後將舊的膨脹很大的文件給刪掉，AOF 文件壹直會被限制在和Redis內存中壹樣的數據。AOF同步間隔比 RDB 小，數據更完整
優點：
缺點：
AOF 存放的指令日誌，數據恢復的時候，需要回放執行所有指令日誌，RDB 就是壹份數據文件，直接加載到內存中。
優點：
缺點：
AOF 來保證數據不丟失，RDB 做不同時間的冷備
支持 N 個 Redis master node,每個 master node掛載多個 slave node
多master + 讀寫分離 + 高可用
數據量很少，高並發 -> replication + sentinal 集群
海量數據 + 高並發 + 高可用 -> redis cluster
hash算法->壹致性 hash 算法-> redis cluster->hash slot算法
redis cluster :自動對數據進行分片，每個 master 上放壹部分數據，提供內置的高可用支持，部分master不可用時，還是可以繼續工作
cluster bus 通過 16379進行通信，故障檢測，配置更新，故障轉移授權，另外壹種二進制協議，主要用於節點間進行高效數據交換，占用更少的網絡帶寬和處理時間
key進行hash，然後對節點數量取模，最大問題只有任意壹個 master 宕機，大量數據就要根據新的節點數取模，會導致大量緩存失效。
key進行hash，對應圓環上壹個點，順時針尋找距離最近的壹個點。保證任何壹個 master 宕機，只受 master 宕機那臺影響，其他節點不受影響，此時會瞬間去查數據庫。
緩存熱點問題：
可能集中在某個 hash區間內的值特別多，那麽會導致大量的數據都湧入同壹個 master 內，造成 master的熱點問題，性能出現瓶頸。
解決方法：
給每個 master 都做了均勻分布的虛擬節點，這樣每個區間內大量數據都會均勻的分布到不同節點內，而不是順時針全部湧入到同壹個節點中。
redis cluster 有固定 16384 個 hash slot,對每個key計算 CRC16 值，然後對16384取模，可以獲取 key對應的 hash slot
redis cluster 中每個 master 都會持有部分 slot ,當壹臺 master 宕機時候，會最快速度遷移 hash slot到可用的機器上（只會短暫的訪問不到）
走同壹個 hash slot 通過 hash tag實現
集群元數據：包括 hashslot->node之間的映射表關系，master->slave之間的關系，故障的信息
集群元數據集中式存儲（storm），底層基於zookeeper（分布式協調中間件）集群所有元數據的維護。好處：元數據的更新和讀取，時效性好，壹旦變更，其他節點立刻可以感知。缺點：所有元數據的更新壓力全部集中在壹個地方，可能會導致元數據的存儲有壓力。
goosip: 好處：元數據的更新比較分散，有壹定的延時，降低了壓力。缺點：更新有延時，集群的壹些操作會滯後。（reshared操作時configuration error）
自己提供服務的端口號+ 10000 ，每隔壹段時間就會往另外幾個節點發送ping消息，同時其他幾點接收到ping之後返回pong
故障信息，節點的增加和移除， hash slot 信息
meet:某個節點發送 meet給新加入的節點，讓新節點加入集群中，然後新節點就會開始於其他節點進行通信
ping:每個節點都會頻繁給其他節點發送ping，其中包含自己的狀態還有自己維護的集群元數據，互相通過ping交換元數據
ping:返回ping和meet，包含自己的狀態和其他信息
fail:某個節點判斷另壹個節點fail之後，就發送 fail 給其他節點，通知其他節點，指定的節點宕機了
ping 很頻繁，且攜帶元數據，會加重網絡負擔
每個節點每秒會執行 10 次 ping，每次選擇 5 個最久沒有通信的其他節點
當如果發現某個節點通信延遲達到了 cluster_node_timeout /2 ，那麽立即發送 ping， 避免數據交換延遲過長，落後時間太長（2 個節點之間 10 分鐘沒有交換數據，整個集群處於嚴重的元數據不壹致的情況）。
每次ping，壹個是帶上自己的節點信息，還有就是帶上1/10其他節點的信息，發送出去，進行數據交換
至少包含 3 個其他節點信息，最多包含總節點-2 個其他節點的信息
客戶端發送到任意壹個redis實例發送命令，每個redis實例接受到命令後，都會計算key對應的hash slot，如果在本地就本地處理，否則返回moved給客戶端，讓客戶端進行重定向 （redis-cli -c）
通過tag指定key對應的slot,同壹個 tag 下的 key，都會在壹個 hash slot中，比如 set key1:{100} 和 set key2:{100}
本地維護壹份hashslot->node的映射表。
JedisCluster 初始化的時候，隨機選擇壹個 node，初始化 hashslot->node 映射表，同時為每個節點創建壹個JedisPool連接池，每次基於JedisCluster執行操作，首先JedisCluster都會在本地計算key的hashslot，然後再本地映射表中找到對應的節點，如果發現對應的節點返回moved，那麽利用該節點的元數據，更新 hashslot->node映射表（重試超過 5 次報錯）
hash slot正在遷移，那麽會返回ask 重定向給jedis,jedis 接受到ask重定向之後，，會重定向到目標節點去執行
判斷節點宕機：
如果壹個節點認為另外壹個節點宕機了， 就是pfail,主觀宕機
如果多個節點都認為另外壹個節點宕機了，那麽就是fail，客觀宕機（跟哨兵原理壹樣）
在cluster-node-timeout內，某個節點壹直沒有返回 pong,那麽就被認為是 pfail
如果壹個節點認為某個節點pfail了，那麽會在gossip消息中，ping給其他節點，如果超過半數的節點認為pfail了，那麽就會變成fail。
從節點過濾：
對宕機的 mster node ，從其所有的 slave node中，選擇壹個切換成 master node
檢查每個 slave node與master node斷開連接的時間，如果超過了cluster-node-timeout * cluster-slave-validity-factor，那麽就沒資格切換成 master（和哨兵壹致）
從節點選舉：
每個從節點，根據自己對 master 復制數據的 offset，設置壹個選舉時間，offset越大（復制數據越多）的從節點，選舉時間越靠前，所有的 master node 開始投票，給要進行選舉的 slave進行投票，如果大部分 master node(N/2 +1) 都投票給某個從節點，那麽選舉通過，從節點執行主備切換，從節點切換成主節點
總結：和哨兵很像，直接集成了 replication 和 sentinal
方案：
事前：保證 redis 集群高可用性 （主從+哨兵或 redis cluster），避免全盤崩潰
事中：本地 ehcache 緩存 + hystrix 限流（保護數據庫） & 降級，避免 MySQL被打死
事後： redis持久化，快速恢復緩存數據，繼續分流高並發請求
限制組件每秒就 2000 個請求通過限流組件進入數據庫，剩余的 3000 個請求走降級，返回壹些默認 的值，或者友情提示
好處 ：
4000 個請求黑客攻擊請求數據庫裏沒有的數據
解決方案：把黑客查數據庫中不存在的數據的值，寫到緩存中，比如： set -999 UNKNOWN
讀的時候，先讀緩存，緩存沒有，就讀數據庫，然後取出數據後放入緩存，同時返回響應
更新的時候，刪除緩存，更新數據庫
為什麽不更新緩存：
更新緩存代價太高（更新 20 次，只讀 1 次），lazy思想，需要的時候再計算，不需要的時候不計算
方案：先刪除緩存，再修改數據庫
方案：寫，讀路由到相同的壹個內存隊列（唯壹標識，hash，取模）裏，更新和讀操作進行串行化（後臺線程異步執行隊列串行化操作），（隊列裏只放壹個更新查詢操作即可，多余的過濾掉，內存隊列裏沒有該數據更新操作，直接返回 ）有該數據更新操作則輪詢取緩存值，超時取不到緩存值，直接取壹次數據庫的舊值
TP 99 意思是99%的請求可以在200ms內返回
註意點：多個商品的更新操作都積壓在壹個隊列裏面（太多操作積壓只能增加機器），導致讀請求發生大量的超時，導致大量的讀請求走數據庫
壹秒 500 寫操作，每200ms，100 個寫操作，20 個內存隊列，每個隊列積壓 5 個寫操作，壹般在20ms完成
方案：分布式鎖 + 時間戳比較
10臺機器，5 主 5 從，每個節點QPS 5W ，壹*** 25W QPS（Redis cluster 32G + 8 核 ，Redis 進程不超過 10G）總內存 50g，每條數據10kb，10W 條數據1g，200W 條數據 20G，占用總內存不到50%，目前高峰期 3500 QPS
作者： mousycoder