緩存 & redis

cache vs buffer

cache 緩存。經常使用的東西放在離自己更近的地方,比如cpu將最近使用的數據放入緩存中,提高存取速度。redis通常被當著緩存服務器使用。

buffer 緩沖。如泄洪湖/池時,將淡水湖作為泄洪時的緩沖地帶,確保下游河道的流量平穩(wěn),降低風險。

Redis定位

Redis 是一個開源(BSD許可)的,內存中的數據結構存儲系統(tǒng),它可以用作數據庫、緩存、消息隊列等;

支持多種數據結構:String、Hash、List、Sorted List、Set等;

支持不同級別的持久化(RDB、AOF--redis1.1版本出現);

通過哨兵(Sentinel)機制和集群(Cluter,3.0.2版本出現)機制提供高可用性

redis cluter

集群出現的目的在于:提高可擴展性,提高可用性

redis cluster的目標:

在1000個節(jié)點的時候仍能表現得很好并且可擴展性(scalability)是線性的。

沒有合并操作,這樣在 Redis 的數據模型中最典型的大數據值中也能有很好的表現。

寫入安全(Write safety):那些與大多數節(jié)點相連的客戶端所做的寫入操作,系統(tǒng)嘗試全部都保存下來。不過公認的,還是會有小部分場景寫入會丟失:(兩個場景:主從之間異步復制、非強一致性保證)。

可用性(Availability):在絕大多數的主節(jié)點(master node)是可達的,并且對于每一個不可達的主節(jié)點都至少有一個它的從節(jié)點(slave)可達的情況下,Redis 集群仍能進行分區(qū)(partitions)操作。

redis cluster為了獲取更好的性能和擴展性,在可用性和一致性上做出了舍棄:Redis采取了P2P而非Proxy方式、異步復制、客戶端重定向(節(jié)點間不需要傳遞command)

redis cluster的Availability允許少數節(jié)點出錯,當某一主節(jié)點及其所有的從節(jié)點都掛掉的時候,cluster不可用(試配置而定),出現的概率其實不高。

redis cluster沒有采用一致性hash算法(參考:五分鐘理解一致性哈希算法(consistent hashing)),而是使用了固定數碼的HASH_SOLT(hash槽),減少了復雜度,reshare就是完成HASH_SOLT和節(jié)點直接的映射關系變化。

自我理解:

1、redis cluster通過固定的HASH_SOLT,將key分散到不同的節(jié)點;

2、為提高可用性,每個master節(jié)點都可以有一個/多個slave節(jié)點,當master節(jié)點死掉后,其中的某個slave節(jié)點會通過選舉算法升級為master節(jié)點,繼續(xù)服務;

3、redis cluster還支持備份遷移,適用于某個master節(jié)點死掉后,再也無法回來的情況下,另外的master節(jié)點,會將其slave節(jié)點貢獻出來,配給剛剛升級上來的master節(jié)點,作為slave節(jié)點;

4、redis cluster為了達到高性能和高擴展性,犧牲了部分可用性和數據一致性:各個master node之間不能互為備份,在少數情況下不能完全安全寫入。

5、從redis cluster的設計思路中,可以發(fā)現:架構設計的關鍵在于搞清楚問題域,找到關鍵問題點,做好取舍。


參考資料:

Redis 的幾種數據結構&五種數據類型對象

Redis作者談Redis應用場景

redis中文站點

示例:

考慮存儲用戶基本信息、綁定賬戶列表、社交信息、最近登錄信息,分析下來,擬采用如下數據結構存儲

用戶基本信息 —— Hash

綁定賬戶列表 —— Set,賬戶信息詳情使用String即可,畢竟更改賬戶信息場景的地方很少;

社交信息 —— Hash

最近登錄信息 —— List,限定長度的列表表示,如果需要按照登錄時間排序,則考慮使用Sorted List


使用redis做隊列

redis提供Pub/Sub命令,提供消息發(fā)布/訂閱 機制,使用List數據結構可以模擬隊列,使用Sorted List可以模擬優(yōu)先級的隊列。

問題思考

1、redis什么場景下需要做持久化處理?

RE:作為緩存服務器使用時,可以不做持久化處理;作為數據存儲服務器時,如果數據不容丟失且沒有關系型數據庫兜底,則需要做持久化處理。

作為緩存服務器時,不宜做持久化處理,緩存的數據可能被更改,在redis不可用期間,應用程序孩子繼續(xù)修改數據,這時的修改并沒有反應到redis緩存中,這時做持久化可能帶來數據一致性問題。比如用戶基本信息的緩存數據,不宜做持久化。

在redis當著存儲服務器使用時,如果數據沒有其他存儲方式兜底,則需要做持久化。如用戶最后登錄時間,數據丟失一兩次,影響不大,而且為了計算和存取速度,選擇放在redis中,這時需要考慮持久化,丟一兩次可以,但是不能全丟了。

2、redis cluster總的hash solt(哈希槽)的數量為什么是16384(2的14次方)?

RE:算法實現決定的。間redis官方網站解釋,參考:cluster-spec

redis cluster HASH_SLOT algorithm

3、redis cluster 從節(jié)點升級為主節(jié)點的選舉過程是不是一個paxos算法實現?

RE:不是。redis cluster的選舉過程目標是:選舉出唯一的一個從節(jié)點來代替已經FAIL掉的主節(jié)點。但是算法實現上和paxos上有一些相似之處:參加選舉的原slave節(jié)點是proposaler,其他或者的master node是acceptor;

redis的使用場景案例

1、作為計數器使用

需要記錄一個時間窗口期內某行為發(fā)生的次數,比如需要記錄一天內用戶登錄失敗次數,如果失敗次數大于5次則鎖定用戶??梢赃@樣做:用戶每次登錄失敗,使用登錄標識(手機號或者用戶名)作為key,使用SET數據結構,將登錄失敗信息(時間戳、登錄渠道)寫入redis,過期時間設置為24小時;用戶再次登錄時,首先從redis查詢該登錄標識對應的登錄失敗記錄是否超過了5次,如果沒有則繼續(xù)登錄流程,否則報錯。

由于redis記錄自身天然過期,所以redis set記錄寫入后,無需再作更改,效率高效。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容