準備
1.尋址
磁盤尋址是毫秒級別
內(nèi)存尋址是納秒級別
所以內(nèi)存比磁盤快刹前。所以redis比mysql快
其次两入，磁盤是有帶寬限制讀的。
2.I/O
i/o就是在讀取數(shù)據(jù)溉箕。然后任何IO過程中都包含兩個步?：第一是等待；第二是拷貝悦昵。主要目的就是將數(shù)據(jù)從內(nèi)核復(fù)制到用戶空間
磁盤有磁道和扇區(qū)约巷，一扇區(qū)512字節(jié)，扇區(qū)小會導(dǎo)致索引成本變大旱捧。所以操作系統(tǒng)讀取磁盤時，無論讀多少都是最少4k從磁盤讀取。
隨著文件變大枚赡，讀取速度由于硬盤I/O的限制會導(dǎo)致讀取速度變慢氓癌。
問：
數(shù)據(jù)庫表數(shù)據(jù)很大，增刪改都會變慢贫橙。那么查詢會變慢嗎贪婉？
答：當個別查詢時，不會受影響卢肃。但是當并發(fā)時疲迂，會受帶寬的影響。因為當打滿了帶寬莫湘，每一個查詢都會等待前面的查詢完
3.五種I/O模型
（這里只記三種）
- BIO（blocking I/O：同步阻塞i0）：發(fā)送讀取請求尤蒿，內(nèi)核準備，拷貝幅垮，返回數(shù)據(jù)腰池。如果數(shù)據(jù)未準成功，則一直等待忙芒。（優(yōu)點：只適用于數(shù)據(jù)小示弓，并發(fā)低。缺點：非常耗時呵萨，時間利用率低）奏属。（打王者等人，等到人就開始游戲）
- NIO（noblocking I/O：同步非阻塞i0）:發(fā)送讀取請求潮峦，內(nèi)核準備囱皿，拷貝，返回數(shù)據(jù)跑杭。如果數(shù)據(jù)未準備好铆帽，進程就會去做別的事情，然后輪詢?nèi)ゲ榭磾?shù)據(jù)是否準備好德谅。（優(yōu)點：提高了時間利用率爹橱。缺點：輪詢對cpu來說是巨大的浪費，占用大量cpu的時間片）（打王者等人窄做，如果沒等到愧驱，則切屏去看抖音。期間去輪詢問是否準備好椭盏，等到確認準備好组砚，那么就開始游戲）
- I/O multiplexing（多路復(fù)用io）：將多個讀取請求注冊在同一管道上。管道與內(nèi)核交互掏颊，當管道種的某一個請求的數(shù)據(jù)準備好后糟红，就將數(shù)據(jù)拷貝到用戶空間艾帐。（原理：將多個進程注冊到select或者epoll上，然后select會調(diào)用進程阻塞盆偿，當任意一個io準備好數(shù)據(jù)后柒爸，就返回）（就是多準備幾個手機打王者，然后等不同的幾個人事扭，捎稚，當有一個人準備好了，那么就開始游戲）
4.select和epoll的區(qū)別
epoll和select都是多路復(fù)用下的一種機制求橄，多路復(fù)用I/O就是通過一種機制今野，可以監(jiān)視多個文件描述符，一旦某個文件描述符就緒罐农，就通知程序該文件描述符可以進行讀寫操作条霜。
select：每次將fd集合（請求集合）拷貝到內(nèi)核，然后遍歷fd調(diào)用對應(yīng)的poll方法啃匿，返回可讀寫的演示碼來判斷是否資源就緒蛔外。
epoll：epoll也需要拷貝fd，但是在整個過程中只會拷貝一次溯乒。等等夹厌。。裆悄。矛纹。
基礎(chǔ)
redis介紹
redis是key-value數(shù)據(jù)庫。
redis特性（為什么那么快）
- 完全基于內(nèi)存
- 數(shù)據(jù)結(jié)構(gòu)簡單：string,list,set,zset,hash
- redis是單線程的光稼，避免了多請求的切換或南，不用考慮鎖對性能的消耗。
- 使用了多路復(fù)用的io機制（相比于普通的io機制艾君，多路復(fù)用更快速）
- C語言實現(xiàn)
redis是單線程嗎
redis在讀寫的時候是單線程采够，但是在其他功能，比如持久化機制冰垄，異步刪除蹬癌，集群的數(shù)據(jù)同步，這些都是額外的線程執(zhí)行
redis的數(shù)據(jù)類型
代碼實例：
- String：二進制安全虹茶∈判剑可以包含任何數(shù)據(jù)，字符蝴罪，數(shù)字董济。一個鍵可存512m。應(yīng)用場景：常規(guī)計數(shù)要门，點贊數(shù)虏肾，分布式鎖廓啊。
- hash：鍵值對。存儲對象询微，直接可以拿到對象屬性崖瞭。應(yīng)用場景：存儲用戶數(shù)據(jù)。
- list：鏈表撑毛。順序，存儲唧领。應(yīng)用場景：消息隊列藻雌，文章列表
- set：哈希表實現(xiàn)，不重復(fù)斩个，不順序胯杭。應(yīng)用場景：共同好友，利用唯一性做到訪問網(wǎng)站的獨立ip
-
sortSet：在set中加入一個權(quán)重參數(shù)score受啥，score有序排列做个。應(yīng)用場景：排行榜，帶權(quán)重的消息隊列
redis-hash.png
redis的消息發(fā)布訂閱
什么是緩存穿透
是針對數(shù)據(jù)庫和緩存中都沒有的數(shù)據(jù)滚局。有些惡意的key不命中緩存直接打到數(shù)據(jù)庫居暖，數(shù)據(jù)庫也沒有這樣的數(shù)據(jù)。然后就被大量的這種key進行攻擊藤肢。
避免：1.緩存那些返回值為空的key太闺。2.過濾那些一定不正確的key（布隆過濾器）
什么是緩存擊穿
針對緩存中沒有但數(shù)據(jù)庫有的數(shù)據(jù)。當熱點數(shù)據(jù)key失效后嘁圈，瞬間涌入大量的請求來請求同一個key省骂。然后沒來得及緩存，導(dǎo)致數(shù)據(jù)庫壓力過大最住。
避免：1.設(shè)置熱點數(shù)據(jù)永不過期钞澳。2.緩存預(yù)熱
什么是緩存雪崩
針對緩存中沒有但數(shù)據(jù)庫有的數(shù)據(jù)。短時間涨缚，大量的key過期轧粟，導(dǎo)致請求全部打在了數(shù)據(jù)庫上。
避免：1.設(shè)置緩存時間分散仗岖。
redis的緩存失效策略
- 惰性刪除：當發(fā)現(xiàn)命中的key失效時就刪除
- 定期刪除：每隔一段時間就隨機抽取一批key逃延，如果失效就刪除
redis的持久化機制
- aof：aof是將每一條（寫刪）指令都記錄，然后宕機后恢復(fù)
- rdb：是每隔一段時間就將數(shù)據(jù)快照轧拄。過程（bgsave）：fork一個子進程揽祥，先將數(shù)據(jù)寫入臨時文件，然后替換之前的文件檩电，用二進制壓縮存儲拄丰。整個過程中主進程不進行任何io操作
aof和rdb的優(yōu)缺點
rdb：適合大規(guī)模數(shù)據(jù)恢復(fù)府树，但是對數(shù)據(jù)的完整性不高。在一定間隔做一次備份料按，那么就會丟失最后一次快照更改數(shù)據(jù)奄侠。但性能比較好
aof：性能較差但是數(shù)據(jù)完整性比較好
redis的混合持久化機制
混合持久化機制。
rdb會丟失最后一次數(shù)據(jù)载矿，aof備份全部操作命令的文件又太大垄潮。那么，當宕機時闷盔，先執(zhí)行rdb弯洗，再rof上一次rdb到宕機時的數(shù)據(jù)，那么就可以完整的利用兩者的優(yōu)點逢勾。
redis牡整，mysql如何保證雙寫一致性
一般使用延遲雙刪。寫數(shù)據(jù)時溺拱，先刪除redis逃贝，然后更新數(shù)據(jù)庫，再延遲刪除redis
- 第二次刪除延遲是因為迫摔，更新數(shù)據(jù)庫需要時間沐扳，不延遲，可能數(shù)據(jù)庫沒更新就已經(jīng)執(zhí)行刪除操作了
- 第二次刪除攒菠，可能會有請求在第一次刪和更新數(shù)據(jù)庫中間發(fā)生迫皱，所以保證數(shù)據(jù)的統(tǒng)一需要進行二次刪除
redis的使用場景
- 緩存
- 隊列：對list進行pop和push操作就可以模擬出隊列
- 排行榜、計數(shù)器：
- 發(fā)布訂閱（可以做到聊天）
- 分布式鎖
redis集群
redis的主從復(fù)制
解決問題：主從復(fù)制的出現(xiàn)是因為辖众，一臺redis滿足不了大量的讀寫請求卓起。
如何解決：讀寫分離，將讀操作集中在從服務(wù)器上凹炸，寫操作在主服務(wù)器上戏阅。(由于結(jié)構(gòu)原因，從無法進行寫操作)
命令：
docker network create --subnet 192.169.0.0/16 --gateway 192.169.0.1 redis-net
docker pull reids
docker run -itd --name redis-master -p 6379:6379 --net redis-net --ip 192.169.0.2 redis
docker run -itd --name redis-slave1 -p 6380:6379 --net redis-net --ip 192.169.0.3 redis redis-server --slaveof 192.169.0.2 6379
docker run -itd --name redis-slave2 -p 6381:6379 --net redis-net --ip 192.169.0.4 redis redis-server --slaveof 192.169.0.2 6379
docker exec -it redis-master redis-cli info replication
docker exec -it redis-master redis-cli
docker exec -it redis-slave1 redis-cli
redis哨兵模式及故障轉(zhuǎn)移
解決問題：當master（主服務(wù)器）掛了啤它。redis就無法使用了奕筐。
如何解決：首先哨兵模式，將監(jiān)控你的master節(jié)點变骡，當其判斷主節(jié)點掛了离赫，那么就會從投票選舉出一個從節(jié)點來作為主節(jié)點。
哨兵模式的基本原理：當判斷主節(jié)點下線的哨兵達到一半以上塌碌，那么就會判斷master掛了渊胸。索引哨兵一定要大于三個及以上。每個哨兵維護了3個定時任務(wù)（1.確定主從關(guān)系台妆，發(fā)送info命令獲取最新的主從結(jié)構(gòu)翎猛。2.發(fā)布訂閱獲取其他哨兵的狀態(tài)胖翰。3.其他節(jié)點發(fā)送ping命令進行心跳檢測，判斷其是否下線）切厘。
故障轉(zhuǎn)移原理：1.過濾不健康從節(jié)點萨咳。 2.選擇復(fù)制偏移量最大的從節(jié)點。
命令：
