redis優化方案

流水線（pipelined）

批量提交redis命令，減小通訊次數

事務

• mulit，事務的開始
• exec，執行事務快內的命令
• discard，放棄事務快內的命令
• watch，監視key，若是key改動則中斷事務,CAS樂觀鎖
• unwatch,取消監視key

分佈式鎖機制

• 隨着負載增長，失敗重試次數也增長
• 爲表明鎖的key生成值，來獲取鎖
• setnx命令，當key不存在時爲key設置value(set not exist)
• 設置expire過時時間，防止掛掉的進程一直持有鎖，造成死鎖
• 刪除鎖時須要先獲取，再判斷，最後刪除，存在相似i++的原子性問題，可使用lua腳本把一組命令當成一個原子語句來執行

分佈式鎖高併發優化

對同一個商品id的key進行鎖請求，會進行串行化處理。相似於ConcurrentHashMap的鎖分段原理，把庫存分段，好比0-100，100-200，對應的key爲id_100,id_200，把對一個key的鎖請求變成分段的鎖請求。

publish和subscribe替代方案，解決鏈接斷開失敗的問題

生產者把消息發送到消費者的消息列表裏

發佈消息，更新到follower的timeline中

相似twitter的網紅帳號，有幾千萬粉絲，好比前1000的粉絲直接添加。超過數量的經過消息隊列延遲處理

ziplist壓縮列表

當整數集合在設置的限制條件內時，底層會使用ziplist壓縮列表
主要包括list-max-ziplist-entires（最大元素數量）和list-max-ziplist-value（每一個節點最大致積）

分片和哨兵機制

通常使用hash一致性算法獲取取模，根據key值計算出屬於哪個節點上
通常是奇數臺哨兵，哨兵會向主機發送心跳檢測。若是長時間沒回應，認爲主機死亡，選舉出新的master

配置只讀服務器（拓展讀性能）

slaveof host post
在多個服務器嘗試與主服務器進行鏈接時，在主節點建立快照完成以前，子節點都會受到同一份快照。可是過多的快照副本可能會耗盡主節點資源，能夠採樹狀的結構，將一級子節點做爲二級子節點的主節點。

預先分片（拓展寫性能）

在單機上運行多個實例，監聽不一樣端口

應用和redis隔離部署

應用可能瞬間搶佔了所有的CPU資源，致使redis沒有資源超時，而應用若是恰好須要鏈接redis，會產生相似的死鎖

redis和db的數據一致性

• 通常狀況下，更新數據時先刪除緩存再更新db，等讀時再將db查詢結果更新到緩存
• 高併發下，可能在更新db前就有新的讀請求，這時緩存失效因而去db查舊數據又更新到緩存。解決方案是使用任務隊列，把更新操做加入到隊列中，當有讀請求時，先看是否有更新請求
• 延時雙刪 ，在更新完db後，休眠比讀請求耗時多幾百ms的時間，再次刪除緩存，消除高併發下讀請求形成的髒數據
• 對key加分佈式鎖

db更新緩存失敗

• 經過循環操做固定次數，減小網絡瞬時抖動形成的影響
• 仍是失敗的話，添加任務到mq中，通知更新失敗，讓消費mq隊列去更新緩存

熱點數據防止緩存穿透和雪崩（利用分佈式鎖）

查詢到緩存中key不存在，使用分佈式鎖，防止多個線程讀同一個key請求屢次db。在查詢db前再判斷一次緩存中key是否存在，若是別的線程已經將db更新到緩存中，則不容許再讀db。
限制鎖的數量，好比固定1000個，根據id的hashcode對1000取模，使得同時最多隻有1000個併發，其餘線程沒有鎖阻塞，延遲競爭鎖。