1.Redis架構(gòu)

• 訪問(wèn)框架
  • 網(wǎng)絡(luò)訪問(wèn)框架
• 索引模塊
• 基于不同value類(lèi)型的操作模塊
• 存儲(chǔ)模塊
  • 持久化（AOF/RDB）
• 高可用集群支撐模塊
  • 主從復(fù)制
  • 哨兵機(jī)制
• 高可擴(kuò)展集群支撐模塊
  • 數(shù)據(jù)分片

2. Redis數(shù)據(jù)結(jié)構(gòu)底層實(shí)現(xiàn)

為了實(shí)現(xiàn)從key到value的快速訪問(wèn)，Redis使用了一個(gè)<u>哈希桶</u>來(lái)保存，哈希桶里的元素是指向具體指的指針。計(jì)算key的hash值就可以知道哈希桶位置從而訪問(wèn)到相應(yīng)的entry

潛在問(wèn)題

• 哈希表的沖突問(wèn)題

  • 負(fù)載因子：哈希表中的K-V對(duì)數(shù)量/哈希表長(zhǎng)度
  • 解決方式：鏈?zhǔn)焦?/li>

• rehash可能帶來(lái)的操作阻塞

  rehash過(guò)程：增加現(xiàn)有的哈希桶數(shù)量，讓逐漸多的entry能在更多的桶之間分散保存，減少哈希沖突

  • 漸進(jìn)式hash

    把一次性的大量拷貝開(kāi)銷(xiāo)分?jǐn)偟蕉啻翁幚碚?qǐng)求中避免耗時(shí)操作

  • 擴(kuò)展/收縮策略（盡可能避免在子進(jìn)程做持久化的時(shí)候進(jìn)行rehash避免不必要的內(nèi)存寫(xiě)入操作）

    • 服務(wù)器目前沒(méi)在執(zhí)行BGSAVE或者BGREWRITEAOF命令（持久化）并且哈希因子>=1
    • 服務(wù)器正在執(zhí)行BGSAVE或者BGREWRITEAOF命令并且哈希因子>=5

<img src="https://cdn.meishakeji.com/study/Redis%E5%85%A8%E5%B1%80%E5%93%88%E5%B8%8C%E8%A1%A8.png" style="zoom:50%;" />

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

• 整數(shù)數(shù)組

• 雙向鏈表

• 哈希表

• 壓縮列表

• 跳表

  在鏈表的基礎(chǔ)上增加了多級(jí)索引通過(guò)索引位置的跳轉(zhuǎn)快速定位數(shù)據(jù)

  <img src="https://cdn.meishakeji.com/study/Redis%E8%B7%B3%E8%A1%A8.png" style="zoom:50%;" />

3.Redis快的原因

1. 單線(xiàn)程

   redis的單線(xiàn)程主要是指Redis的網(wǎng)絡(luò)IO和鍵值對(duì)讀寫(xiě)是由一個(gè)線(xiàn)程來(lái)完成的，redis的其他功能如持久化、異步刪除、集群同步等是由額外的線(xiàn)程執(zhí)行的

2. 高效的數(shù)據(jù)結(jié)構(gòu)

3. 基于多路復(fù)用的高性能I/O模型 epoll機(jī)制（基于事件的回調(diào)機(jī)制）

   • 一個(gè)Redis線(xiàn)程處理多個(gè)IO流 一旦檢測(cè)到FD上有請(qǐng)求到達(dá)時(shí)就會(huì)觸發(fā)相應(yīng)的事件
   • 事件被放進(jìn)一個(gè)事件隊(duì)列，Redis單線(xiàn)程對(duì)事件隊(duì)列不斷進(jìn)行處理，調(diào)用相應(yīng)的處理函數(shù)實(shí)現(xiàn)基于事件的回調(diào)
   • 這就像病人去醫(yī)院瞧病。在醫(yī)生實(shí)際診斷前，每個(gè)病人（等同于請(qǐng)求）都需要先分診、測(cè)體溫、登記等。如果這些工作都由醫(yī)生來(lái)完成，醫(yī)生的工作效率就會(huì)很低。所以，醫(yī)院都設(shè)置了分診臺(tái)，分診臺(tái)會(huì)一直處理這些診斷前的工作（類(lèi)似于 Linux 內(nèi)核監(jiān)聽(tīng)請(qǐng)求），然后再轉(zhuǎn)交給醫(yī)生做實(shí)際診斷。這樣即使一個(gè)醫(yī)生（相當(dāng)于 Redis 單線(xiàn)程），效率也能提升。

   <img src="https://cdn.meishakeji.com/study/%E5%9F%BA%E4%BA%8E%E5%A4%9A%E8%B7%AF%E5%A4%8D%E7%94%A8%E7%9A%84redis%E9%AB%98%E6%80%A7%E8%83%BDIO%E6%A8%A1%E5%9E%8B.png" style="zoom:50%;" />

4.Redis如何避免數(shù)據(jù)丟失

• 錯(cuò)誤方案：從數(shù)據(jù)庫(kù)恢復(fù)

    頻繁訪問(wèn)數(shù)據(jù) 從慢速數(shù)據(jù)庫(kù)中讀取出來(lái)性能上比不上redis讀
  

• 正確方案：redis要實(shí)現(xiàn)數(shù)據(jù)持久化

• AOF持久化方案

  • 實(shí)現(xiàn)：先執(zhí)行命令把數(shù)據(jù)寫(xiě)入內(nèi)存后記錄日志（DB寫(xiě)日志是實(shí)際寫(xiě)數(shù)據(jù)前把修改的數(shù)據(jù)記到日志文件中）

    • 日志內(nèi)容：redis收到的每一條命令
    • 實(shí)現(xiàn)的好處：避免出現(xiàn)記錄錯(cuò)誤命令的情況避免額外的檢查開(kāi)銷(xiāo)；不會(huì)阻塞當(dāng)前的寫(xiě)操作
    • 實(shí)現(xiàn)的潛在風(fēng)險(xiǎn)：執(zhí)行完還沒(méi)來(lái)得及日志就掛了；給下一個(gè)操作帶來(lái)阻塞風(fēng)險(xiǎn)

  • 寫(xiě)回策略

    配置項(xiàng)	寫(xiě)回時(shí)機(jī)	優(yōu)點(diǎn)	缺點(diǎn)
    always	同步寫(xiě)回	可靠性高 數(shù)據(jù)基本不丟失	性能影響較大
    everysec	每秒寫(xiě)回	性能適中	宕機(jī)時(shí)丟失1s的數(shù)據(jù)
    no	操作系統(tǒng)控制寫(xiě)回	性能好	宕機(jī)時(shí)丟失數(shù)據(jù)較多

• AOF文件瘦身

  • 一個(gè)拷貝

    每次執(zhí)行重寫(xiě)時(shí)，主線(xiàn)程fork出后臺(tái)的bgrewriteaof子進(jìn)程，此時(shí)fork會(huì)把子進(jìn)程的內(nèi)存拷貝一份給bgrewriteaof子進(jìn)程（copy on write）這里面就包含了redis數(shù)據(jù)庫(kù)的最新數(shù)據(jù)。bgrewriteaof子進(jìn)程就在可以不影響主進(jìn)程的情況下逐一把拷貝的數(shù)據(jù)寫(xiě)成操作計(jì)入重寫(xiě)日志

  • 兩處日志

    主線(xiàn)程如果有寫(xiě)操作，第一處日志就是指正在使用的AOF日志，redis會(huì)把這個(gè)操作寫(xiě)到緩沖區(qū)。第二處日志是指新的AOF重寫(xiě)日志。這樣重寫(xiě)日志也不會(huì)丟失最新的操作。

    <img src="https://cdn.meishakeji.com/study/AOF%E9%9D%9E%E9%98%BB%E5%A1%9E%E7%9A%84%E9%87%8D%E5%86%99%E8%BF%87%E7%A8%8B.png" style="zoom:50%;" />

5.Redis如何實(shí)現(xiàn)快速恢復(fù)

RDB持久化

• 命令：bgsave 創(chuàng)建一個(gè)子進(jìn)程專(zhuān)門(mén)用于寫(xiě)入RDB文件避免主進(jìn)程阻塞。redis借助操作系統(tǒng)的寫(xiě)時(shí)復(fù)制技術(shù)（copy-on-write）在執(zhí)行快照時(shí)主線(xiàn)程正常進(jìn)行寫(xiě)操作

  • 增量快照：做了一次全量快照后后續(xù)的快照只對(duì)修改的數(shù)據(jù)進(jìn)行快照記錄避免每次全量快照的開(kāi)銷(xiāo)，為了記住修改引入的額外空間開(kāi)銷(xiāo)較大

  • 缺點(diǎn)：快照的頻率不好把握，頻率太低兩次快照間掛掉的話(huà)有較多數(shù)據(jù)丟失，頻率太高又會(huì)產(chǎn)生較大額外開(kāi)銷(xiāo)

  • 終極方案：AOF混合RDB

    內(nèi)存快照以一定頻率執(zhí)行，在兩次快照之間使用AOF日志記錄期間命令執(zhí)行

• 注意：子進(jìn)程創(chuàng)建后不會(huì)阻塞主進(jìn)程，但是<u>fork操作本身會(huì)阻塞主進(jìn)程</u>

  <img src="https://cdn.meishakeji.com/study/COW%E6%9C%BA%E5%88%B6%E4%BF%9D%E8%AF%81RDB%E5%BF%AB%E7%85%A7%E6%9C%9F%E9%97%B4%E6%95%B0%E6%8D%AE%E5%8F%AF%E4%BF%AE%E6%94%B9.png" style="zoom:50%;" />

6.Redis主從如何實(shí)現(xiàn)數(shù)據(jù)一致

• redis的高可靠性

  • AOF/RDB保證數(shù)據(jù)盡量少丟失
  • 增加副本冗余量保證服務(wù)盡量少中斷

• Redis主從模式

  • 讀操作：主庫(kù)、從庫(kù)都可以接收

  • 寫(xiě)操作：首先到主庫(kù)執(zhí)行，主庫(kù)將寫(xiě)操作同步給從庫(kù)

  • 主從庫(kù)第一次同步的流程

    • 第一階段

      從庫(kù)和主庫(kù)建立起連接并告訴主庫(kù)即將進(jìn)行同步，發(fā)送psync命令（包含主庫(kù)的runId和復(fù)制進(jìn)度 第一次不知道主庫(kù)ID 和進(jìn)度）。主庫(kù)收到psync命令后用FULLRESYNC命令響應(yīng)

    • 第二階段

      主庫(kù)執(zhí)行bgsave命令生成RDB文件，將文件發(fā)給從庫(kù)。從庫(kù)通過(guò)replicaof命令和主庫(kù)同步，收到RDB文件后先清空現(xiàn)有數(shù)據(jù)然后加載RDB文件。主庫(kù)同步數(shù)據(jù)給從庫(kù)的過(guò)程中主庫(kù)不會(huì)被阻塞，主庫(kù)會(huì)在內(nèi)存中用專(zhuān)門(mén)的replication buffer記錄RDB文件生成后收到的所有寫(xiě)操作

      用RDB不用AOF的原因：RDB文件是經(jīng)過(guò)壓縮的二進(jìn)制文件（不同數(shù)據(jù)類(lèi)型做了針對(duì)性?xún)?yōu)化）文件小，傳輸時(shí)對(duì)主庫(kù)網(wǎng)絡(luò)帶寬消耗小。RDB存的是二進(jìn)制文件從庫(kù)按照RDB協(xié)議解析還原數(shù)據(jù)非?？於鳤OF需要依次重放每個(gè)命令。

    • 第三階段

      主庫(kù)完成RDB文件發(fā)送后把此時(shí)replication buffer中的修改操作發(fā)送給從庫(kù)，從庫(kù)重新執(zhí)行這些操作，最終實(shí)現(xiàn)主從同步。

  • 主從級(jí)聯(lián)模式（主-從-從）分擔(dān)全量復(fù)制時(shí)的主庫(kù)壓力

    • 主庫(kù)耗時(shí)操作：生成RDB文件（fork操作阻塞）、傳輸RDB文件（占用主庫(kù)網(wǎng)絡(luò)帶寬）

  <img src="https://cdn.meishakeji.com/study/%E4%B8%BB%E4%BB%8E%E5%BA%93%E7%AC%AC%E4%B8%80%E6%AC%A1%E5%90%8C%E6%AD%A5.png" style="zoom:50%;" />

  • 非首次的同步

    基于長(zhǎng)連接的命令傳播（避免頻繁建立連接的成本）

    • 網(wǎng)絡(luò)斷了之后增量同步，把主從庫(kù)網(wǎng)絡(luò)斷連期間主庫(kù)收到的命令同步給從庫(kù)

    • 增量復(fù)制時(shí)主從保持同步

      主庫(kù)記錄寫(xiě)到的位置，從庫(kù)記錄自己已經(jīng)讀到的位置。主從庫(kù)的連接恢復(fù)之后，從庫(kù)會(huì)給主庫(kù)發(fā)送psync命令，把自己的偏移量發(fā)給主庫(kù)主庫(kù)判斷偏移量的差距

      <img src="https://cdn.meishakeji.com/study/redis%E7%9A%84repl_backlog_buffer%E7%8E%AF%E5%BD%A2%E7%BC%93%E5%86%B2%E5%8C%BA.png" style="zoom:50%;" />

    • 潛在風(fēng)險(xiǎn)

      因?yàn)閞epl_backlog_buffer是一個(gè)環(huán)形緩沖區(qū)所以在緩沖區(qū)寫(xiě)滿(mǎn)之后主庫(kù)會(huì)繼續(xù)寫(xiě)入此時(shí)會(huì)覆蓋之前寫(xiě)的操作，如果從庫(kù)讀取速度比較慢就有可能導(dǎo)致從庫(kù)還未讀取的操作被主庫(kù)新寫(xiě)的操作覆蓋了導(dǎo)致主從不一致

7.Redis哨兵機(jī)制

哨兵其實(shí)就是一個(gè)運(yùn)行在特殊模式下的redis進(jìn)程。哨兵主要負(fù)責(zé)的三個(gè)任務(wù)：監(jiān)控、選擇主庫(kù)、通知

• 監(jiān)控

  哨兵在進(jìn)程運(yùn)行時(shí)周期性給所有的主從庫(kù)發(fā)送PING命令，檢測(cè)它們是否仍然在線(xiàn)運(yùn)行。如果主庫(kù)或從庫(kù)沒(méi)有在規(guī)定時(shí)間內(nèi)響應(yīng)哨兵的PING命令，哨兵就把它標(biāo)記為下線(xiàn)狀態(tài)，主庫(kù)下線(xiàn)的話(huà)開(kāi)始自動(dòng)切換主庫(kù)的流程

• 選主

  • 引入多個(gè)哨兵實(shí)例一起判斷主機(jī)是否下線(xiàn)，避免單個(gè)哨兵因?yàn)樽陨砭W(wǎng)絡(luò)狀況不好而誤判主庫(kù)下線(xiàn)
  • 選主策略
    • 按照在線(xiàn)狀態(tài)、網(wǎng)絡(luò)狀態(tài)篩選過(guò)濾一部分不符合要求的從庫(kù)
    • 按照優(yōu)先級(jí)、復(fù)制進(jìn)度、ID號(hào)大小對(duì)剩余從庫(kù)大分

• 通知

  • 讓從庫(kù)執(zhí)行replicaof與新主庫(kù)同步
  • 通知客戶(hù)端與新主庫(kù)連接

• 哨兵集群的運(yùn)行機(jī)制

  • redis提供了pub/sub（發(fā)布/訂閱）機(jī)制，使得哨兵之間可以相互發(fā)現(xiàn)。哨兵只要和主庫(kù)建立了連接，就可以在主庫(kù)上發(fā)布消息（比如發(fā)布自己的連接信息IP和端口）
  • 哨兵知道從庫(kù)的連接信息靠的是哨兵向主庫(kù)發(fā)送INFO命令，之后和從庫(kù)建立連接并進(jìn)行監(jiān)控
  • 選取哨兵執(zhí)行主從切換
    • raft算法選舉

8. Redis切片集群

• redis如何保存更多數(shù)據(jù)

  • 縱向擴(kuò)展：升級(jí)單個(gè)Redis實(shí)例的資源配置，包括內(nèi)存、硬盤(pán)、CPU。

    • 優(yōu)點(diǎn)：實(shí)施簡(jiǎn)單直接
    • 缺點(diǎn)：受硬件成本限制大；數(shù)據(jù)量增大fork阻塞時(shí)間久

  • 橫向擴(kuò)展：增加當(dāng)前Redis實(shí)例的個(gè)數(shù)

    • 數(shù)據(jù)切片后在多個(gè)實(shí)例之間如何分布

      • Redis Cluster方案采用哈希槽來(lái)處理數(shù)據(jù)和實(shí)例之間的映射關(guān)系，映射過(guò)程：一個(gè)集群有16384個(gè)哈希槽，根據(jù)key按照CRC16算法計(jì)算一個(gè)16bit的值 ，對(duì)16384取模，對(duì)應(yīng)一個(gè)編號(hào)的哈希槽。哈希槽映射成具體的Redis實(shí)例的過(guò)程：均分或者手動(dòng)分配（按照具體實(shí)例的配置）
      • 哈希槽和實(shí)例的對(duì)應(yīng)關(guān)系不是一成不變的，最常見(jiàn)的變化有：集群中有實(shí)例新增或刪除Redis需要重新分配哈希槽，為了負(fù)載均衡Redis需要把哈希槽在所有實(shí)例重新分布一遍
      • 實(shí)例之間可以通過(guò)相互傳遞信息獲取最新的哈希槽分配信息

    • 客戶(hù)端怎么確定想要訪問(wèn)的數(shù)據(jù)在哪個(gè)實(shí)例上

      • 重定向機(jī)制

        客戶(hù)端會(huì)緩存分配信息，緩存結(jié)果和分配結(jié)果不一致的時(shí)候，目標(biāo)實(shí)例會(huì)給客戶(hù)端發(fā)送MOVED命令告訴客戶(hù)端新實(shí)例的訪問(wèn)地址且更新本地緩存（前提是數(shù)據(jù)已經(jīng)全部遷移到新的實(shí)例了）。還有一種情況是數(shù)據(jù)遷移沒(méi)全部完成，此時(shí)會(huì)返回ASK命令表明數(shù)據(jù)還在遷移中且把客戶(hù)端請(qǐng)求數(shù)據(jù)的最新實(shí)例地址返回給客戶(hù)端但不會(huì)更新緩存

9.Redis阻塞點(diǎn)分析

• 交互時(shí)產(chǎn)生操作

  • 客戶(hù)端：網(wǎng)絡(luò)I/O、鍵值對(duì)增刪改查操作、數(shù)據(jù)庫(kù)操作
  • 磁盤(pán)：生成RDB快照、記錄AOF、AOF日志重寫(xiě)
  • 主從節(jié)點(diǎn)：主庫(kù)生成、傳輸RDB文件、從庫(kù)接受RDB文件、清空數(shù)據(jù)庫(kù)、加載RDB文件
  • 切片集群實(shí)例：向其他實(shí)例傳輸哈希槽信息、數(shù)據(jù)遷移

• 判斷操作復(fù)雜度是否算高：操作復(fù)雜度是否為O(N)

• 阻塞點(diǎn)

  • 集合全量查詢(xún)和聚合操作（讀操作是關(guān)鍵路徑操作無(wú)法異步操作）

  • bigkey刪除

    刪除本質(zhì)是要釋放鍵值對(duì)占用的內(nèi)存空間，為了更加高效管理內(nèi)存空間操作系統(tǒng)需要把釋放掉的內(nèi)存塊插入一個(gè)空閑內(nèi)存塊的鏈表，阻塞當(dāng)前釋放內(nèi)存的應(yīng)用程序，增加空閑內(nèi)存塊鏈表操作時(shí)間相應(yīng)造成redis主線(xiàn)程阻塞（可異步執(zhí)行）

  • 清空數(shù)據(jù)庫(kù)（可異步執(zhí)行）

  • AOF日志同步寫(xiě)（可異步執(zhí)行）

  • 加載RDB文件（關(guān)鍵路徑操作）

10.Redis變慢

• 從慢查詢(xún)命令開(kāi)始排查，根據(jù)業(yè)務(wù)需求替換慢查詢(xún)命令
• 排查過(guò)期key的時(shí)間設(shè)置，根據(jù)實(shí)際使用需求設(shè)置不同的過(guò)期時(shí)間

11.Redis秒殺

• 秒殺前
  • 使用CDN把頁(yè)面靜態(tài)化元素緩存起來(lái)
• 秒殺活動(dòng)開(kāi)始

12.Redis 事務(wù)機(jī)制

13.Redis內(nèi)存碎片

• 內(nèi)因：內(nèi)存分配器的分配策略

  Redis默認(rèn)使用jemalloc，按照一系列固定大小劃分內(nèi)存空間，如2KB、4KB、8KB等，當(dāng)程序申請(qǐng)的內(nèi)存最接近某個(gè)固定值時(shí)給它分配相應(yīng)大小的空間（這樣是為了減少分配次數(shù)）

• 外因：鍵值對(duì)不小不一樣和刪改操作

  鍵值對(duì)的刪改會(huì)導(dǎo)致空間的擴(kuò)容和釋放，占用額外的空間或者釋放不用的空間形成空閑空間

14.Redis并發(fā)訪問(wèn)問(wèn)題

• 加鎖
  • 系統(tǒng)并發(fā)性能降低
  • 基于單個(gè)Redis節(jié)點(diǎn)實(shí)現(xiàn)分布式鎖
    • lock_key unique_value NX PX 10000
      • unique_value 是客戶(hù)端的唯一標(biāo)識(shí)，可以用一個(gè)隨機(jī)生成的字符串來(lái)表示
      • NX選項(xiàng)表示not exist即鍵值對(duì)不存在時(shí)才設(shè)置
      • PX 10000 則表示 lock_key 會(huì)在 10s 后過(guò)期，以免客戶(hù)端在這期間發(fā)生異常而無(wú)法釋放鎖。
      • 釋放鎖時(shí)匹配unique_value避免誤釋放
  • 基于多個(gè)Redis節(jié)點(diǎn)實(shí)現(xiàn)高可靠的分布式鎖
    • redlock算法
• 原子操作
  • 單命令操作：把多個(gè)操作在Redis中實(shí)現(xiàn)成一個(gè)操作
    • RMW操作（讀取-修改-寫(xiě)回 read-modify-write）不符合原子性
    • INCR/DECR
  • Lua腳本：把多個(gè)操作寫(xiě)到一個(gè)Lua腳本中,以原子性方式執(zhí)行單個(gè)Lua腳本

15.Redis主從機(jī)制的坑

16.Redis數(shù)據(jù)傾斜問(wèn)題