涼涼！面試阿里我被Redis技術專題給弄死了~
📚我本以爲我可以像是別的博主一樣去阿里面試隨隨便便，因爲Redis，我直接被阿里大佬淦翻在地上
好了不裝了 沒過沒關係 我總結了一些這些最難的知識點！！！！然後自己總結歸類再去百度查詢了一些 最終得出這份Redis技術專題
題目開淦
Redis集羣的主從複製模型是怎樣的？
爲了是在部分節點失敗或者大部分節點無法通信的情況下集羣仍然可用，所以集羣是用了主從複製模型，每個節點都會有N-1個複製品
Redis集羣會有寫操作丟失嗎？爲什麼？
Redis並不能保證數據強一致性，這意味着在實際中集羣在特定的條件下可能會丟失寫操作
Redis集羣之間是如何複製的
異步複製
Redis如何做內存優化
儘可能使用散列表（hashes），散列表（是說列表裏面存儲的數少）使用的內存非常小，所以你應該儘可能的將你的數據模型抽象到一個散列表裏面，比如你的web系統中有一個用戶對象，不要爲這個用戶的名稱，姓氏，郵箱，密碼設置單獨的key，而是應該把這個用戶所有信息存儲到一張散列表中
【參考文檔】
Redis回收進程如何工作？
一個Client運行了新的命令，添加了新的數據，Redis會檢查內存使用情況，如果大於maxmemory的限制，則根據設定好的策略進行回收
Redis支持哪幾種常用數據類型？
- String（字符串）
- List（列表）
- Set（集合）
- Sorted Set（有序集合）
- hash（哈希表）
Redis 與 memcached 相比有哪些優勢？（主要是Redis的優勢）
- 1.memcached所有的值均是簡單的字符串，redis支持更爲豐富的數據類型。
- 2.redis的速度比memcached快很多，redis的速度比memcached快很多（有爭議，考慮到Memache多線程可以充分利用多核，在考慮6.0後的Redis支持多線程，所以存在版本的概念）。
- 3.redis可以持久化其數據redis可以持久化其數據，數據的可靠性和一致性更高。
- 4.redis單個key存儲的value可以達到1G而Memcache只有1M存儲大小。
- 5.redis對集羣情況下的高可用支持的方案很多，所以集羣情況下高可用更好。
- 6.針對於第一條的補充，包含功能場景的豐富化，比如，消息隊列、原子操作處 理（Lua腳本以及自增自減的操作）、事務機制和延時隊列機制等等功能。
- 7.採用的網絡模型非常好（epoll機制）擯棄給純內存考慮，並且採用了內部共享內存池機制（可以複用內存，惰性分配），採用單線程機制減少用戶態和內核態的切換以及線程之間上下文的切換。
Redis 集羣方案應該怎麼做？都有哪些方案？
- codis目前用的最多的集羣方案，屬於一個基於服務端操作的負載均衡機制屬於代理後端服務實例的機制，可以支持1024的集羣節點，但它支持在節點數量改變情況下，舊節點數據可恢復到新hash（CRC32算法）節點。//加入Java開發交流君樣：756584822一起吹水聊天
- twemproxy ，基本和codis一致的效果，但是對於節點變化的情況處理不是很好，所以性能方面來講依賴於twemproxy的節點的吞吐能力。
- redis cluster3.0 自帶的集羣，特點在於他的分佈式算法不是一致性hash，而是 hash槽(slot)的概念，以及自身支持節點設置從節點，並且節點之間都有引用鏈接關係幫助定位hash槽的數據，支持節點達到16384個節點。
（Redis）什麼是緩存擊穿？如何避免？
高併發的系統中，大量的請求同時查詢一個 key 時，此時這個key正好失效了，就會導致大量的請求都打到數據庫上面去。這種現象我們稱爲緩存擊穿。
📚如何避免？
- 1：在緩存失效後，通過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。比如對某個 key 只允許一個線程查詢數據和寫緩存，其他線程等待，等第一個線程查詢到了數據，然後做緩存。後面的線程進來發現已經有緩存了，就直接走緩存。
- 2：做二級緩存，A1 爲原始緩存，A2 爲拷貝緩存，A1 失效時，可以訪問 A2，A1 緩存失效時間設置爲短期，A2 設置爲長期，犧牲一致性，提高可用性
- 3：設置熱點數據永遠不過期（不推薦哦）。
Redis如何實現高可用呢？
Redis實現高可用主要有三種方式：主從複製、哨兵模式，以及 Redis 集羣。
📚主從複製
將從前的一臺 Redis 服務器，同步數據到多臺從 Redis 服務器上，即一主多從的模式，這個跟MySQL主從複製的原理一樣。
📚主從複製哨兵模式
使用 Redis 主從服務的時候，會有一個問題，就是當 Redis 的主從服務器出現故障宕機時，需要手動進行恢復，爲了解決這個問題，Redis 增加了哨兵模式（因爲哨兵模式做到了可以監控主從服務器，並且提供自動容災恢復的功能）。
📚Redis Cluster（集羣）
Redis Cluster 是一種分佈式去中心化的運行模式，是在 Redis 3.0 版本中推出的 Redis 集羣方案，它將數據分佈在不同的服務器上，以此來降低系統對單主節點的依賴，從而提高 Redis 服務的讀寫性能。
使用哨兵模式在數據上有副本數據做保證，在可用性上又有哨兵監控，一旦master宕機會選舉slave節點爲master節點，這種已經滿足了我們的生產環境需要，那爲什麼還需要使用集羣模式呢？
哨兵模式歸根節點還是主從模式，在主從模式下我們可以通過增加slave節點來擴展讀併發能力，但是沒辦法擴展寫能力和存儲能力，存儲能力只能是master節點能夠承載的上限。所以爲了擴展寫能力和存儲能力，我們就需要引入集羣模式。
【參考文檔】
[圖片上傳失敗...(image-a4063d-1621690282179)]
Redis爲何那麼快？？？
Redis的快速很多人都知道是因爲基於內存，但這只是一方面，其實redis在底層是一套很完善的多路複用事件處理機制來保證執行的高效的
線程模型
redis內部使用文件事件處理器file event handler，它包含如下幾個部分
- 多個socket
- IO多路複用程序
- 文件事件分派器
- 事件處理器（連接應答處理器，命令請求處理器，命令回覆處理器）
之所以說redis是單線程其實是指這個文件事件處理器是單線程的，它採用多路複用的方式監聽系統上多個socket，將socket上產生的事件壓入隊列中，由文件事件分派器從隊列中取出一個socket根據事件類型發給相應的事件處理器
整個處理過程如圖：
處理過程可以分爲以下幾個步驟：
- 客戶端向redis發起一個socket請求，向redis的server socket請求連接，這裏命名爲socket01
- server socket產生一個AE_READABLE事件，IO多路複用程序監聽到事件後將這個socket01壓入隊列
- 文件事件分派器從隊列中取出socket01，交給連接應答處理器
- 連接應答處理器會將socket01的AE_READABLE事件與命令請求處理器相關聯
- 假設客戶端執行set操作，這時命令請求處理器會從socket01讀取key value，在內存中完成key value的設置
- 在內存中完成設置後，會將socket01的AE_WRITEABLE事件與命令回覆處理器相關聯，然後壓入隊列中
- 事件分派器拿到socket01後，交給命令回覆處理器，由命令回覆處理器向socket01寫入本次操作的結果，比如OK，之後解除關聯
以上就是一個命令在redis中執行的過程
總結一下效率高的原因
- 內存操作
- IO多路複用機制，減少了阻塞
- 單線程避免了線程切換的開銷和競爭問題
- 最最根本的redis是用C語言寫的，本來就直接跟操作系統交互，命令執行快得飛起
最新2021整理收集的很多幹貨，包含mysql，netty，spring，線程，spring cloud、jvm、源碼、算法等詳細講解，需要獲取這些內容的朋友加Q君樣：756584822
[圖片上傳失敗...(image-614d00-1621690282179)]
最後希望大家可以給我一個三連也算是對我的一個小小的支持，我們都是CSDN一家人啊