cache vs buffer
cache 緩存。經常使用的東西放在離自己更近的地方，比如cpu將最近使用的數據放入緩存中，提高存取速度。redis通常被當著緩存服務器使用。
buffer 緩沖。如泄洪湖/池時，將淡水湖作為泄洪時的緩沖地帶，確保下游河道的流量平穩，降低風險。
Redis定位
Redis 是一個開源(BSD許可)的,內存中的數據結構存儲系統,它可以用作數據庫、緩存、消息隊列等；
支持多種數據結構：String、Hash、List、Sorted List、Set等；
支持不同級別的持久化（RDB、AOF--redis1.1版本出現）；
通過哨兵（Sentinel）機制和集群（Cluter，3.0.2版本出現）機制提供高可用性
redis cluter
集群出現的目的在于：提高可擴展性，提高可用性
redis cluster的目標：
在1000個節點的時候仍能表現得很好并且可擴展性（scalability）是線性的。
沒有合并操作，這樣在 Redis 的數據模型中最典型的大數據值中也能有很好的表現。
寫入安全（Write safety）：那些與大多數節點相連的客戶端所做的寫入操作，系統嘗試全部都保存下來。不過公認的，還是會有小部分場景寫入會丟失：（兩個場景：主從之間異步復制、非強一致性保證）。
可用性（Availability）：在絕大多數的主節點（master node）是可達的，并且對于每一個不可達的主節點都至少有一個它的從節點（slave）可達的情況下，Redis 集群仍能進行分區（partitions）操作。
redis cluster為了獲取更好的性能和擴展性，在可用性和一致性上做出了舍棄：Redis采取了P2P而非Proxy方式、異步復制、客戶端重定向（節點間不需要傳遞command）
redis cluster的Availability允許少數節點出錯，當某一主節點及其所有的從節點都掛掉的時候，cluster不可用（試配置而定），出現的概率其實不高。
redis cluster沒有采用一致性hash算法（參考：五分鐘理解一致性哈希算法(consistent hashing)），而是使用了固定數碼的HASH_SOLT（hash槽），減少了復雜度，reshare就是完成HASH_SOLT和節點直接的映射關系變化。
自我理解：
1、redis cluster通過固定的HASH_SOLT，將key分散到不同的節點；
2、為提高可用性，每個master節點都可以有一個/多個slave節點，當master節點死掉后，其中的某個slave節點會通過選舉算法升級為master節點，繼續服務；
3、redis cluster還支持備份遷移，適用于某個master節點死掉后，再也無法回來的情況下，另外的master節點，會將其slave節點貢獻出來，配給剛剛升級上來的master節點，作為slave節點；
4、redis cluster為了達到高性能和高擴展性，犧牲了部分可用性和數據一致性：各個master node之間不能互為備份，在少數情況下不能完全安全寫入。
5、從redis cluster的設計思路中，可以發現：架構設計的關鍵在于搞清楚問題域，找到關鍵問題點，做好取舍。
參考資料：
示例：
考慮存儲用戶基本信息、綁定賬戶列表、社交信息、最近登錄信息，分析下來，擬采用如下數據結構存儲
用戶基本信息 —— Hash
綁定賬戶列表 —— Set，賬戶信息詳情使用String即可，畢竟更改賬戶信息場景的地方很少；
社交信息 —— Hash
最近登錄信息 —— List，限定長度的列表表示，如果需要按照登錄時間排序，則考慮使用Sorted List
使用redis做隊列
redis提供Pub/Sub命令，提供消息發布/訂閱 機制，使用List數據結構可以模擬隊列，使用Sorted List可以模擬優先級的隊列。
問題思考
1、redis什么場景下需要做持久化處理？
RE：作為緩存服務器使用時，可以不做持久化處理；作為數據存儲服務器時，如果數據不容丟失且沒有關系型數據庫兜底，則需要做持久化處理。
作為緩存服務器時，不宜做持久化處理，緩存的數據可能被更改，在redis不可用期間，應用程序孩子繼續修改數據，這時的修改并沒有反應到redis緩存中，這時做持久化可能帶來數據一致性問題。比如用戶基本信息的緩存數據，不宜做持久化。
在redis當著存儲服務器使用時，如果數據沒有其他存儲方式兜底，則需要做持久化。如用戶最后登錄時間，數據丟失一兩次，影響不大，而且為了計算和存取速度，選擇放在redis中，這時需要考慮持久化，丟一兩次可以，但是不能全丟了。
2、redis cluster總的hash solt（哈希槽）的數量為什么是16384（2的14次方）？
RE：算法實現決定的。間redis官方網站解釋，參考：cluster-spec
3、redis cluster 從節點升級為主節點的選舉過程是不是一個paxos算法實現？
RE：不是。redis cluster的選舉過程目標是：選舉出唯一的一個從節點來代替已經FAIL掉的主節點。但是算法實現上和paxos上有一些相似之處：參加選舉的原slave節點是proposaler，其他或者的master node是acceptor；
redis的使用場景案例
1、作為計數器使用
需要記錄一個時間窗口期內某行為發生的次數，比如需要記錄一天內用戶登錄失敗次數，如果失敗次數大于5次則鎖定用戶。可以這樣做：用戶每次登錄失敗，使用登錄標識（手機號或者用戶名）作為key，使用SET數據結構，將登錄失敗信息（時間戳、登錄渠道）寫入redis，過期時間設置為24小時；用戶再次登錄時，首先從redis查詢該登錄標識對應的登錄失敗記錄是否超過了5次，如果沒有則繼續登錄流程，否則報錯。
由于redis記錄自身天然過期，所以redis set記錄寫入后，無需再作更改，效率高效。
