當前位置:名人名言大全網 - 傷感說說 - 京東面試官:Redis 這些我必問

京東面試官:Redis 這些我必問

緩存好處:高性能 + 高並發

數據庫查詢耗費了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