基於這些基礎的數據結構，redis封裝了自己的對象系統，包含字符串對象string、列表對象list、哈希對象hash、集合對象set、有序集合對象zset，每種對象都用到了至少一種基礎的數據結構。
redis通過encoding屬性設置對象的編碼形式來提升靈活性和效率，基於不同的場景redis會自動做出優化。不同對象的編碼如下：
字符串對象string：int整數、embstr編碼的簡單動態字符串、raw簡單動態字符串列表對象list：ziplist、linkedlist哈希對象hash：ziplist、hashtable有序集合對象zset：ziplist、skiplistRedis為什麼快呢？redis的速度非常的快，單機的redis就可以支撐每秒10幾萬的並發，相對於mysql來說，性能是mysql的幾十倍。速度快的原因主要有幾點：
C語言實現，優化過的數據結構，基於幾種基礎的數據結構，redis做了大量的優化，性能極高那為什麼Redis6.0之後又改用多線程呢?redis使用多線程並非是完全摒棄單線程，redis還是使用單線程模型來處理客戶端的請求，只是使用多線程來處理數據的讀寫和協議解析，執行命令還是使用單線程。
這樣做的目的是因為redis的性能瓶頸在於網絡IO而非CPU，使用多線程能提升IO讀寫的效率，從而整體提高redis的性能。
知道什麼是熱key嗎？熱key問題怎麼解決？所謂熱key問題就是，突然有幾十萬的請求去訪問redis上的某個特定key，那麼這樣會造成流量過於集中，達到物理網卡上限，從而導致這臺redis的伺服器宕機引發雪崩。
針對熱key的解決方案：
加入二級緩存，提前加載熱key數據到內存中，如果redis宕機，走內存查詢什麼是緩存擊穿、緩存穿透、緩存雪崩？ 緩存擊穿緩存擊穿的概念就是單個key並發訪問過高，過期時導致所有請求直接打到db上，這個和熱key的問題比較類似，只是說的點在於過期導致請求全部打到DB上而已。
解決方案：
加鎖更新，比如請求查詢A，發現緩存中沒有，對A這個key加鎖，同時去資料庫查詢數據，寫入緩存，再返回給用戶，這樣後面的請求就可以從緩存中拿到數據了。將過期時間組合寫在value中，通過異步的方式不斷的刷新過期時間，防止此類現象。https://tva
緩存穿透緩存穿透是指查詢不存在緩存中的數據，每次請求都會打到DB，就像緩存不存在一樣。
針對這個問題，加一層布隆過濾器。布隆過濾器的原理是在你存入數據的時候，會通過散列函數將它映射為一個位數組中的K個點，同時把他們置為1。
這樣當用戶再次來查詢A，而A在布隆過濾器值為0，直接返回，就不會產生擊穿請求打到DB了。
顯然，使用布隆過濾器之後會有一個問題就是誤判，因為它本身是一個數組，可能會有多個值落到同一個位置，那麼理論上來說只要我們的數組長度夠長，誤判的概率就會越低，這種問題就根據實際情況來就好了。
緩存雪崩當某一時刻發生大規模的緩存失效的情況，比如你的緩存服務宕機了，會有大量的請求進來直接打到DB上，這樣可能導致整個系統的崩潰，稱為雪崩。雪崩和擊穿、熱key的問題不太一樣的是，他是指大規模的緩存都過期失效了。
針對雪崩幾個解決方案：
限流，如果redis宕機，可以限流，避免同時刻大量請求打崩DBRedis的過期策略有哪些？redis主要有2種過期刪除策略
惰性刪除惰性刪除指的是當我們查詢key的時候才對key進行檢測，如果已經達到過期時間，則刪除。顯然，他有一個缺點就是如果這些過期的key沒有被訪問，那麼他就一直無法被刪除，而且一直佔用內存。
定期刪除定期刪除指的是redis每隔一段時間對資料庫做一次檢查，刪除裡面的過期key。由於不可能對所有key去做輪詢來刪除，所以redis會每次隨機取一些key去做檢查和刪除。
那麼定期+惰性都沒有刪除過期的key怎麼辦？假設redis每次定期隨機查詢key的時候沒有刪掉，這些key也沒有做查詢的話，就會導致這些key一直保存在redis裡面無法被刪除，這時候就會走到redis的內存淘汰機制。
volatile-lru：從已設置過期時間的key中，移出最近最少使用的key進行淘汰volatile-ttl：從已設置過期時間的key中，移出將要過期的keyvolatile-random：從已設置過期時間的key中隨機選擇key淘汰allkeys-lru：從key中選擇最近最少使用的進行淘汰allkeys-random：從key中隨機選擇key進行淘汰noeviction：當內存達到閾值的時候，新寫入操作報錯持久化方式有哪些？有什麼區別？redis持久化方案分為RDB和AOF兩種。
RDBRDB持久化可以手動執行也可以根據配置定期執行，它的作用是將某個時間點上的資料庫狀態保存到RDB文件中，RDB文件是一個壓縮的二進位文件，通過它可以還原某個時刻資料庫的狀態。由於RDB文件是保存在硬碟上的，所以即使redis崩潰或者退出，只要RDB文件存在，就可以用它來恢復還原資料庫的狀態。
可以通過SAVE或者BGSAVE來生成RDB文件。
SAVE命令會阻塞redis進程，直到RDB文件生成完畢，在進程阻塞期間，redis不能處理任何命令請求，這顯然是不合適的。
BGSAVE則是會fork出一個子進程，然後由子進程去負責生成RDB文件，父進程還可以繼續處理命令請求，不會阻塞進程。
AOFAOF和RDB不同，AOF是通過保存redis伺服器所執行的寫命令來記錄資料庫狀態的。
AOF通過追加、寫入、同步三個步驟來實現持久化機制。
當AOF持久化處於激活狀態，伺服器執行完寫命令之後，寫命令將會被追加append到aof_buf緩衝區的末尾在伺服器每結束一個事件循環之前，將會調用flushAppendOnlyFile函數決定是否要將aof_buf的內容保存到AOF文件中，可以通過配置appendfsync來決定。always ##aof_buf內容寫入並同步到AOF文件
everysec ##將aof_buf中內容寫入到AOF文件，如果上次同步AOF文件時間距離現在超過1秒，則再次對AOF文件進行同步
no ##將aof_buf內容寫入AOF文件，但是並不對AOF文件進行同步，同步時間由作業系統決定如果不設置，默認選項將會是everysec，因為always來說雖然最安全（只會丟失一次事件循環的寫命令），但是性能較差，而everysec模式只不過會可能丟失1秒鐘的數據，而no模式的效率和everysec相仿，但是會丟失上次同步AOF文件之後的所有寫命令數據。
怎麼實現Redis的高可用？要想實現高可用，一臺機器肯定是不夠的，而redis要保證高可用，有2個可選方案。
主從架構主從模式是最簡單的實現高可用的方案，核心就是主從同步。主從同步的原理如下：
master收到sync之後，執行bgsave，生成RDB全量文件bgsave執行完畢之後，發送RDB文件到slave，slave執行master發送緩存中的寫命令到slave，slave執行這裡我寫的這個命令是sync，但是在redis2.8版本之後已經使用psync來替代sync了，原因是sync命令非常消耗系統資源，而psync的效率更高。
哨兵基於主從方案的缺點還是很明顯的，假設master宕機，那麼就不能寫入數據，那麼slave也就失去了作用，整個架構就不可用了，除非你手動切換，主要原因就是因為沒有自動故障轉移機制。而哨兵(sentinel)的功能比單純的主從架構全面的多了，它具備自動故障轉移、集群監控、消息通知等功能。
哨兵可以同時監視多個主從伺服器，並且在被監視的master下線時，自動將某個slave提升為master，然後由新的master繼續接收命令。整個過程如下：
初始化sentinel，將普通的redis代碼替換成sentinel專用代碼初始化masters字典和伺服器信息，伺服器信息主要保存ip:port，並記錄實例的地址和ID創建和master的兩個連接，命令連接和訂閱連接，並且訂閱sentinel:hello頻道每隔10秒向master發送info命令，獲取master和它下面所有slave的當前信息當發現master有新的slave之後，sentinel和新的slave同樣建立兩個連接，同時每個10秒發送info命令，更新master信息sentinel每隔1秒向所有伺服器發送ping命令，如果某臺伺服器在配置的響應時間內連續返回無效回復，將會被標記為下線狀態選舉出領頭sentinel，領頭sentinel需要半數以上的sentinel同意領頭sentinel從已下線的的master所有slave中挑選一個，將其轉換為master將原來的master設置為新的master的從伺服器，當原來master重新回復連接時，就變成了新master的從伺服器sentinel會每隔1秒向所有實例（包括主從伺服器和其他sentinel）發送ping命令，並且根據回復判斷是否已經下線，這種方式叫做主觀下線。當判斷為主觀下線時，就會向其他監視的sentinel詢問，如果超過半數的投票認為已經是下線狀態，則會標記為客觀下線狀態，同時觸發故障轉移。
能說說redis集群的原理嗎？如果說依靠哨兵可以實現redis的高可用，如果還想在支持高並發同時容納海量的數據，那就需要redis集群。redis集群是redis提供的分布式數據存儲方案，集群通過數據分片sharding來進行數據的共享，同時提供複製和故障轉移的功能。
節點一個redis集群由多個節點node組成，而多個node之間通過cluster meet命令來進行連接，節點的握手過程：
A根據收到的IP位址和埠號，向B發送一條meet消息A知道B收到了meet消息，返回一條ping消息，握手成功最後，節點A將會通過gossip協議把節點B的信息傳播給集群中的其他節點，其他節點也將和B進行握手 槽slotredis通過集群分片的形式來保存數據，整個集群資料庫被分為16384個slot，集群中的每個節點可以處理0-16384個slot，當資料庫16384個slot都有節點在處理時，集群處於上線狀態，反之只要有一個slot沒有得到處理都會處理下線狀態。通過cluster addslots命令可以將slot指派給對應節點處理。
slot是一個位數組，數組的長度是16384/8=2048，而數組的每一位用1表示被節點處理，0表示不處理，如圖所示的話表示A節點處理0-7的slot。
當客戶端向節點發送命令，如果剛好找到slot屬於當前節點，那麼節點就執行命令，反之，則會返回一個MOVED命令到客戶端指引客戶端轉向正確的節點。（MOVED過程是自動的）
如果增加或者移出節點，對於slot的重新分配也是非常方便的，redis提供了工具幫助實現slot的遷移，整個過程是完全在線的，不需要停止服務。
故障轉移如果節點A向節點B發送ping消息，節點B沒有在規定的時間內響應pong，那麼節點A會標記節點B為pfail疑似下線狀態，同時把B的狀態通過消息的形式發送給其他節點，如果超過半數以上的節點都標記B為pfail狀態，B就會被標記為fail下線狀態，此時將會發生故障轉移，優先從複製數據較多的從節點選擇一個成為主節點，並且接管下線節點的slot，整個過程和哨兵非常類似，都是基於Raft協議做選舉。
了解Redis事務機制嗎？redis通過MULTI、EXEC、WATCH等命令來實現事務機制，事務執行過程將一系列多個命令按照順序一次性執行，並且在執行期間，事務不會被中斷，也不會去執行客戶端的其他請求，直到所有命令執行完畢。事務的執行過程如下：
如果客戶端正處於事務狀態，則會把事務放入隊列同時返回給客戶端QUEUED，反之則直接執行這個命令當收到客戶端EXEC命令時，WATCH命令監視整個事務中的key是否有被修改，如果有則返回空回復到客戶端表示失敗，否則redis會遍歷整個事務隊列，執行隊列中保存的所有命令，最後返回結果給客戶端WATCH的機制本身是一個CAS的機制，被監視的key會被保存到一個鍊表中，如果某個key被修改，那麼REDIS_DIRTY_CAS標誌將會被打開，這時伺服器會拒絕執行事務。
長按掃碼添加「Python小助手」
▼點擊成為社區會員 喜歡就點個在看吧