正確使用redis

client-server通訊模式，完全基於記憶體（記憶體不會成為瓶頸）；
資料結構簡單；
多路I/O複用模型，避免上下文交換（利用select、poll、epoll可以同時監察多個流的 I/O 事件的能力，描述了使用者態和核心態）；

elect/epoll的優勢並不是對於單個連線能處理得更快，而是在於能處理更多的連線。所以，如果處理的連線數不是很高的話，使用select/epoll的web server不一定比使用多執行緒 + 阻塞 IO的web server效能更好，可能延遲還更大。

Pub/Sub 釋出訂閱

解耦釋出者和訂閱者，不關心是否有訂閱者

管道 Pipelining（客戶端一次可傳送多個命令）

必須等本次Pipe返回才能繼續寫，基於此，其本質是要減少網路延遲問題（減少 RTT： round trip time）
舉例：若 RTT為250ms，即使伺服器1s能處理10w個請求，那麼每秒最多處理 4 個請求。
儘量創造本機網路（減小RTT，本機網路小於 1ms）
pipelining VS Scripting （client支援傳送請求後不必等server響應返回，就繼續傳送下個請求，然後一次性收到返回）

複製機制（非同步非阻塞）

1）slave 為master的副本，基於命令流的同步。
2）哨兵模式問題：本質是主從切換技術。
master自動重啟足夠快時，sentinel無法探測到，重啟後的master將從空資料集開始複製，若slaver試圖從master複製，則slaver被清空問題。（此針對關閉持久化，且允許重啟程序的設定）

持久化

1）RDB 資料快照儲存（二進位制）
AOF 記錄寫操作
2）同步時鐘問題：歸根結底是資料一致性的問題，可由cap理論引申到base理論；

不穩定性

基於redis用於分散式鎖場景。
分散式鎖的基本要求：
1）安全性：即互斥，任意時刻最多1個客戶端持有；
2）活性 ：無死鎖，即使客戶端崩潰或者網路分割槽時；
3）容錯：鎖可釋放，不可重複獲取；
舉例：C1----master 獲取鎖， master宕機前同步了該鎖到slaver，此slaver變為master，C2從新master獲取鎖
分散式鎖原則：安全，代價小。
儘量key失效時間+客戶端Id
事務、儲存
解決方式： 延遲重啟、時間漂移問題（每臺例項時間差）