redis相關(guān)

導(dǎo)讀

  1. redis的工作模型和常用數(shù)據(jù)結(jié)構(gòu)
  2. redis的持久化及數(shù)據(jù)淘汰機(jī)制
  3. redis的應(yīng)用場(chǎng)景及應(yīng)對(duì)措施
    1. 分布式鎖
    2. 緩存穿透、緩存擊穿和緩存雪崩
  4. redis的性能瓶頸

redis工作模型

redis的特點(diǎn)：

  1. 單線程
  2. 高并發(fā)
  3. 高性能
  4. 支持分布式鎖

單線程

  1. 多線程的優(yōu)缺點(diǎn)：

    1. 優(yōu)點(diǎn)：提高cpu的利用率
    2. 缺點(diǎn)：需要額外的管理開銷，需要復(fù)雜的同步機(jī)制，避免死鎖等等。

  2. 單線程的優(yōu)缺點(diǎn)：

    1. 沒有線程切換的消耗
    2. 實(shí)現(xiàn)并發(fā)處理，有點(diǎn)復(fù)雜

  3. redis為什么要使用單線程？

    1. 沒有線程上下文切換的消耗
    2. redis在內(nèi)存中工作，性能比較好，無需多線程
    3. redis依賴多路復(fù)用，實(shí)現(xiàn)了并發(fā)處理

    redis為什么選擇單線程工作模型
    redis單線程解讀

底層數(shù)據(jù)結(jié)構(gòu)

  1. redis底層的數(shù)據(jù)類型

    • 字符串

      • 簡(jiǎn)單動(dòng)態(tài)字符串
      • free：可以知道緩存區(qū)還有多少剩余空間，可以將惰性空間釋放
      • len：做字符串間隔，不需要用指定的字符來間隔，并且可以直接獲取字符串長(zhǎng)度，不需要遍歷

    • 鏈表

      1. 壓縮列表

      2. 雙端鏈表

      3. 快速鏈表
        ：壓縮列表和雙端鏈表的折中方案。

      4. 無環(huán)

      5. 如果列表中的元素較少，Redis傾向于使用壓縮列表進(jìn)行存儲(chǔ)，因?yàn)閴嚎s列表占用內(nèi)存更少，而且比雙端鏈表可以更快載入；當(dāng)列表對(duì)象元素較多時(shí)，壓縮列表就會(huì)轉(zhuǎn)化為更適合存儲(chǔ)大量元素的雙端鏈表。

    • 哈希

      1. table：指向桶
      2. size：元素的個(gè)數(shù)
      3. sizemask：hash計(jì)算掩碼
      4. rehash的過程：
        1. 按照ht[0]的大小給h[1]分配空間
        2. 將ht[0]的元素rehash計(jì)算放入ht[1]中
        3. ht[0]放完之后，釋放ht[0]
        4. 將原h(huán)t[0]指向ht[1]
      5. 漸進(jìn)式rehash
        1. 按照ht[0]的大小給h[1]分配空間
        2. 維持一個(gè)rehashIndex，記錄遷移狀態(tài)
        3. 每次增刪改查都對(duì)ht[0]和ht[1]操作，將ht[0]刪除，rehashIndex++
        4. 當(dāng)遷移完成之后，將ht[0]釋放，并rehashIndex置未-1

    • 集合

      • 無序
      • 不重復(fù)
      • 整數(shù)集合：當(dāng)這個(gè)集合內(nèi)只有整數(shù)的時(shí)候，redis會(huì)自動(dòng)選擇使用整數(shù)集合

    • 有序集合 sortSet

  2. redis的工作模型
    了解redis的單線程模型工作原理？一篇文章就夠了
    多路復(fù)用模型+事件處理器

  3. redis的應(yīng)用場(chǎng)景
    Redis在互聯(lián)網(wǎng)公司一般有以下應(yīng)用:
    String：緩存、限流、計(jì)數(shù)器、分布式鎖、分布式Session
    Hash：存儲(chǔ)用戶信息、用戶主頁訪問量、組合查詢
    List：微博關(guān)注人時(shí)間軸列表、簡(jiǎn)單隊(duì)列
    Set：贊、踩、標(biāo)簽、好友關(guān)系
    Zset：排行榜

持久化

  1. redis持久化
    1. RDB：數(shù)據(jù)快照模式（save、bgsave、自定義）
      • 優(yōu)點(diǎn)：
        • 簡(jiǎn)單、恢復(fù)快
        • 不影響性能（bgsave）
      • 缺點(diǎn)：
        • 在fork的之后，如果有變更，會(huì)丟失
        • 實(shí)現(xiàn)比較重，只有數(shù)據(jù)的最終狀態(tài)
    2. AOF：增量日志模式（always、second、自定義）
      • 優(yōu)點(diǎn)：
        • 安全，可以根據(jù)不同配置，保證較小區(qū)間的數(shù)據(jù)丟失
        • 輕量、靈活
      • 缺點(diǎn)：
        • rewrite可能會(huì)影響系統(tǒng)性能
        • 恢復(fù)慢

    10分鐘徹底理解Redis的持久化機(jī)制：RDB和AOF

緩存淘汰

  1. redis過期策略和內(nèi)存淘汰

    1. 過期淘汰策略

      • redis采用定時(shí)刪除+惰性刪除，缺點(diǎn)是如果一些key始終沒有被操作，那會(huì)一直存在于內(nèi)存中。這時(shí)就需要內(nèi)存淘汰機(jī)制。
      • redis的定時(shí)刪除

      Redis 默認(rèn)會(huì)每秒進(jìn)行 10 次（redis.conf 中通過 hz 配置）過期掃描，掃描并不是遍歷過期字典中的所有鍵，而是采用了如下方法：

      從過期字典中隨機(jī)取出 20 個(gè)鍵
      刪除這 20 個(gè)鍵中過期的鍵
      如果過期鍵的比例超過 25% ，重復(fù)步驟 1 和 2

      為了保證掃描不會(huì)出現(xiàn)循環(huán)過度，導(dǎo)致線程卡死現(xiàn)象，還增加了掃描時(shí)間的上限，默認(rèn)是 25 毫秒（即默認(rèn)在慢模式下，如果是快模式，掃描上限是 1 毫秒）

    2. 內(nèi)存淘汰機(jī)制

redis集群

  1. redis分布式集群的常見形式
    主從模式
    哨兵模式
    集群模式

    Redis分布式集群----redis的三種集群方式總結(jié)(5)

  2. Redis的多路復(fù)用

    Redis I/O 多路復(fù)用

  3. 集群模式下key是怎么尋址的

  4. 分布式尋址都有哪些算法

  5. 一致性hash算法如何動(dòng)態(tài)的增加和刪除一個(gè)節(jié)點(diǎn)

常見問題

  1. 緩存穿透、緩存擊穿、緩存雪崩

    1. 緩存穿透
      1. 查詢了不存在的數(shù)據(jù)，每次都會(huì)透過redis，查詢db
      2. 解決方法：布隆過濾器、當(dāng)返回結(jié)果為空，也進(jìn)行緩存。
    2. 緩存雪崩
      1. 大量key在同一時(shí)刻過期，導(dǎo)致db壓力暴增。
      2. 解決方法：
        1. 可以設(shè)置一個(gè)隨機(jī)范圍的過期時(shí)間
        2. 互斥鎖更新
    3. 緩存擊穿
      1. 單個(gè)key過期時(shí)，正好有大量調(diào)用，請(qǐng)求直接打到db上。
      2. 解決方法：
        1. 互斥鎖更新
        2. 設(shè)置永不失效（不推薦）
        3. 無論結(jié)果是否存在都返回，不存在則起異步線程去獲取

  2. redis性能為什么高?

    1. 設(shè)計(jì)巧妙的數(shù)據(jù)結(jié)構(gòu)
    2. 多路復(fù)用模型
    3. 事件機(jī)制

    為什么單線程的Redis能夠達(dá)到百萬級(jí)的QPS？

  3. 有海量key和value都比較小的數(shù)據(jù)，在redis中如何存儲(chǔ)才更省內(nèi)存？
    首先這是一個(gè)hash結(jié)構(gòu)的數(shù)據(jù)，在redis中hash結(jié)構(gòu)的數(shù)據(jù)通常是有兩種結(jié)構(gòu)保存。

    1. 壓縮列表
    2. hashtable

    從更省內(nèi)存的角度來看，應(yīng)該選擇壓縮列表，這種場(chǎng)景，可以將key映射到不同的map里，因?yàn)閗ey和value都很小，這樣就可以使用壓縮列表的數(shù)據(jù)結(jié)構(gòu)保存數(shù)據(jù)。
    （事實(shí)上，redis在創(chuàng)建數(shù)據(jù)的時(shí)候，會(huì)自我判斷使用哪種數(shù)據(jù)結(jié)構(gòu)。）

  4. 如何保證redis和DB中的數(shù)據(jù)一致性？

    參考

  5. 如何用redis實(shí)現(xiàn)分布式鎖？

  6. 壓測(cè)產(chǎn)生的垃圾數(shù)據(jù)該怎么清理

    1. db，用影子表
    2. redis，key帶上后綴，標(biāo)志
  • 常見緩存問題解決方案
  • redis事務(wù)
  • redis的CAS方案
  • redis的pipeline
  • redis的主從復(fù)制原理
  • 百億級(jí)key存儲(chǔ)方案
  • 如何保證redis和數(shù)據(jù)庫的一致性
  • redis和membercache的區(qū)別，為什么單線程的redis性能要比多線程的membercache要高
  • redis的并發(fā)競(jìng)爭(zhēng)實(shí)質(zhì)是什么？如何解決

redis的并發(fā)競(jìng)爭(zhēng)問題是什么？如何解決這個(gè)問題？

延伸

  1. redis中hash的擴(kuò)容與縮容與java的hashmap方法的比較？
  2. 有序鏈表的實(shí)現(xiàn)
    1. redis中的跳躍表與hashmap的紅黑樹

參考

1. 一文深入了解Redis內(nèi)存模型

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • Redis相關(guān) Reids沒有直接使用C語言傳統(tǒng)的字符串表示，而是自己構(gòu)建了一種名為簡(jiǎn)單動(dòng)態(tài)字符串（simple ...
    萬福來閱讀 396評(píng)論 0贊 0
  • 原文：https://blog.csdn.net/qq_14958051/article/details/1061...
    longLiveData閱讀 297評(píng)論 0贊 0
  • 1、Redis的數(shù)據(jù)類型 String：格式：set key valuestring是二進(jìn)制安全的，可包含任何數(shù)據(jù)...
    夏與清風(fēng)閱讀 361評(píng)論 0贊 0
  • 一 目前主流應(yīng)用的架構(gòu)實(shí)現(xiàn)草圖 ??該應(yīng)用架構(gòu)是最常見的應(yīng)用架構(gòu),一般為了提升性能,都會(huì)在中間添加一個(gè)緩存層,當(dāng)客...
    十丈_紅塵閱讀 624評(píng)論 0贊 8
  • 最近寫了一篇自己搭建redis集群并在自己項(xiàng)目中使用的文章，今天早上看別人寫的面經(jīng)發(fā)現(xiàn)redis在面試中還是比較常...
    南風(fēng)開發(fā)大大閱讀 966評(píng)論 0贊 0

友情鏈接更多精彩內(nèi)容