一、基礎知識面試
1.說說你對Redis的理解
Redis是一個基於Key-Value儲存結構的開源記憶體資料庫，也是一種NoSQL資料庫。
它支援多種資料型別，包括String、Map、Set、ZSet和List，以滿足不同應用場景的需求。
Redis以記憶體儲存和最佳化的資料結構為基礎，提供了快速的讀寫效能和高效的資料訪問。常被用作應用與資料庫之間的快取元件，提升資料IO效率。
此外，Redis支援主從複製、哨兵機制和叢集方式，實現高可用性和水平擴充套件。
總而言之，Redis是一款功能強大、靈活且可靠的資料庫解決方案，適用於各種企業級應用開發場景。
2.你是如何解決熱Key問題的
熱 Key 問題是指在快取系統中，某些特定的快取key受到高頻訪問，導致對這些熱門資料的讀取/寫入操作集中在少數幾個快取節點上，使得這些節點的負載過高，而其他節點負載較輕甚至空閒。這會造成系統效能不均衡，可能導致部分請求響應變慢或服務不可用。
解決熱 Key 問題有這些方案：
-
快取預熱：在系統啟動或業務低峰期，透過批次載入或預先訪問熱門資料，將這些熱門資料提前載入到快取中。這樣可以避免大量請求同時湧入導致的熱點問題，提高系統的穩定性和效能。
-
動態雜湊：將快取節點組織成一個雜湊環，根據快取鍵的雜湊值將資料分散儲存在多個節點上。透過增加快取節點的數量，讓請求更均勻地分佈在各個節點上，減輕熱 Key 對單個節點的壓力。當節點數量發生變化時，可以透過一致性雜湊演算法進行平滑遷移，避免資料大規模遷移帶來的負載過高。
-
資料分片：將資料按特定規則（如資料範圍、業務維度等）分成多個片段，分別儲存在不同的快取節點上。這樣可以使熱 Key 所在的資料儘量均勻地分佈在多個節點上，減輕單個節點的壓力。
透過綜合使用以上解決方案，有效地應對熱 Key 問題，提高快取系統的效能和穩定性。
3.一個REDIS例項最多能存放多少KEYS
Redis 的每個例項最多可以存放約 2^32 - 1 個keys，即大約 42 億個keys。這是由 Redis 內部使用的雜湊表實現決定的，它使用 32 位有符號整數作為索引。Redis 使用的雜湊函式和負載因子等因素也會影響實際可存放鍵的數量。
需要注意的是，儘管 Redis 允許儲存數量龐大的鍵，但在實踐中，儲存過多的鍵可能會導致效能下降和記憶體消耗增加。因此，在設計應用程式時，需要根據實際需求和硬體資源來合理規劃鍵的數量，避免過度使用 Redis 例項造成負擔。如果需要儲存更多的鍵值對，可以考慮使用 Redis 叢集或分片技術，以擴充套件整體儲存容量。
4.Redis為什麼這麼快
Redis之所以快速的原因主要包括以下幾點：
-
記憶體儲存：Redis將資料儲存在記憶體中，實現了快速的讀寫操作。
-
單執行緒模型：Redis採用單執行緒處理請求，避免了多執行緒的競爭和上下文切換開銷。
-
高效的資料結構：Redis內部使用了高效的資料結構，如雜湊表、跳躍表等，提供了快速的資料訪問和操作。
-
非同步IO：Redis利用非同步IO來處理網路請求，能夠同時處理多個請求，提高併發效能。
-
事件驅動架構：Redis基於事件驅動的模型，透過事件迴圈機制處理請求和操作，提高系統的效率。
-
最佳化的操作：Redis對常用操作進行了最佳化，如批次操作和管道技術，減少了網路通訊開銷。
綜上所述，Redis之所以快速在於記憶體儲存、單執行緒模型、高效的資料結構、非同步IO、事件驅動架構和最佳化的操作等因素的綜合作用。這使得Redis能夠以高效能和高響應速度處理各類資料操作請求。
5.Redis為什麼把所有資料都放記憶體
Redis將所有資料放到記憶體中的主要原因是為了提供高效能的讀寫操作。
以下是幾個主要的原因：
-
高速讀寫：記憶體訪問速度快，相比於磁碟和資料庫，記憶體操作速度更快，能夠更迅速地響應讀寫請求。將資料儲存在記憶體中可以大大縮短讀寫的延遲，提高系統的響應速度和吞吐量。
-
簡單資料結構：Redis使用簡單的資料結構來儲存資料，如字串、列表、雜湊、集合和有序集合等。這些資料結構直接對映到記憶體，不需要進行復雜的資料轉換和序列化操作，提高了讀寫效率。
-
資料持久化：儘管Redis將資料儲存在記憶體中，但它也支援資料的持久化。透過使用RDB快照和AOF日誌兩種方式，Redis可以將記憶體中的資料定期或實時寫入磁碟，以保證資料的永續性和安全性。
需要注意的是，由於記憶體容量有限，Redis的記憶體管理也是需要考慮的。透過設定合適的資料過期策略、記憶體淘汰策略和最大記憶體限制等措施，可以在保證高效能的同時，有效地管理記憶體使用。同時，Redis也可以透過叢集和分片等方式來擴充套件記憶體容量和提高系統的可用性和效能。
6.怎麼實現Redis的高可用？
要實現Redis的高可用性，可以採取以下幾個關鍵步驟和措施：
-
主從複製：透過設定主從複製，將主節點的資料同步到多個從節點上。主節點負責處理寫操作，並將寫操作的日誌複製給從節點，從節點則負責處理讀請求。如果主節點發生故障，可以將一個從節點升級為新的主節點，從而實現故障轉移和高可用。
-
哨兵機制：使用Redis 哨兵來監控主節點和從節點的狀態。哨兵是一組獨立執行的程序，它會監控Redis例項的健康狀態，並在主節點出現故障時自動進行故障轉移。它還能夠監控從節點，並在需要時將其提升為主節點。
-
叢集模式：Redis 叢集是一種分散式方案，可以將多個Redis節點組成一個邏輯叢集，提供資料分片和自動故障恢復。每個節點負責儲存和處理部分資料，透過節點間的資料分片和分散式演算法保證資料的可用性和負載均衡。當叢集中的某個節點出現故障時，叢集會自動進行故障轉移和恢復。
7.Redis是單執行緒還是多執行緒
Redis 採用的是單執行緒模型。通常說得單執行緒，主要指的是 Redis 對外提供的鍵值儲存服務的主要流程是單執行緒的，即網路 I/O 和資料讀寫是由單個執行緒來完成的。這樣設計可以避免多執行緒之間的競爭條件和鎖開銷，提高了訪問共享資料的效率。
然而，除了對外提供的鍵值儲存服務，Redis 在某些功能上會使用額外的執行緒來執行，比如持久化、非同步刪除和叢集資料同步等。這些功能需要在後臺執行，不參與主要的網路 I/O 和資料處理。因此，嚴格來說，Redis 並不是完全單執行緒。
8.為什麼Redis 單執行緒模型效率也能那麼高
儘管Redis採用了單執行緒模型，但其效率仍然非常高。以下是一些原因：
-
非阻塞IO：Redis使用了事件驅動的非阻塞IO機制。它透過事件迴圈處理來自客戶端的請求，在等待資料IO時並不會阻塞主執行緒，而是繼續處理其他請求。這種機制允許Redis以高效地方式處理大量的併發連線。
-
記憶體操作：Redis主要將資料儲存在記憶體中，並且由於單執行緒模型的存在，在記憶體操作的情況下，Redis可以透過簡單的指標操作來實現快速讀寫，而不需要考慮複雜的資料同步和競爭條件。
-
單執行緒避免的開銷：與多執行緒模型相比，單執行緒模型避免了執行緒間的上下文切換、鎖競爭和資源管理開銷。這使得Redis可以更高效地使用CPU資源，並減少了大量與執行緒相關的開銷。
需要注意的是，Redis單執行緒模型適合於處理大量的短期操作和快速響應的場景，但在處理長時間執行的計算密集型任務時可能會有效能上的不足。為了提高處理能力和併發性，可以使用Redis的叢集模式、多例項部署或將計算密集型任務委託給其他更適合的工具或語言來處理。
9.說說 Redis 的資料型別
Redis支援五種主要的資料型別：
-
String：String是最常用的資料型別，在Redis中以二進位制安全的方式儲存字串值。它可以包含任何型別的資料，比如文字、整數或二進位制資料。
-
Hash：Hash是一個鍵值對的集合，其中每個鍵都與一個值相關聯。在Redis中，Hash可以用於儲存和操作物件，每個鍵值對相當於物件的欄位和值。
-
List：List是一個按照插入順序排序的字串元素集合。集合中的元素可以重複，可以從列表的兩端進行插入和刪除操作，可用於實現佇列、棧等資料結構。
-
Set：Set是一個無序、唯一的字串集合，不允許重複的成員。可以對集合執行新增、刪除和判斷成員是否存在等操作，也支援集合間的交集、並集和差集運算。
-
Sorted Set：Sorted Set是一個有序的字串集合，每個成員都關聯著一個分數。集合中的成員根據分數的大小進行排序，可以進行範圍查詢和按分數排名操作。
除了這些主要的資料型別，Redis還提供了其他一些特殊的資料結構和功能，如HyperLogLog用於基數統計、Geo用於地理位置資訊儲存、Pub/Sub用於釋出與訂閱等。
透過這些不同的資料型別，Redis可以靈活地儲存和操作各種型別的資料，滿足不同應用場景下的需求。
10.使用 Redis 有哪些好處
使用Redis的好處包括：
-
快取功能：作為高效能快取系統，Redis能夠將熱門資料儲存在記憶體中，提升資料訪問速度和減輕資料庫負載。
-
高效能：Redis採用記憶體儲存和高效資料結構，具備快速讀寫速度，適用於處理大量請求和實時資料需求。
-
多樣化資料型別：Redis支援多種資料型別，如字串、雜湊、列表、集合和有序集合，滿足各種資料儲存和操作需求。
-
支援持久化：Redis支援資料持久化，可將資料寫入磁碟，確保資料的可靠性和持久儲存。
-
支援分散式：Redis提供叢集和分片機制，實現資料分佈和水平擴充套件，提供高可用性和可擴充套件性。
-
簡單易用：Redis具有簡潔的命令介面，易於使用和管理，同時提供豐富的內建命令和客戶端庫。
總之，Redis以其高效能、多樣化資料型別、持久化支援、快取功能、分散式支援和簡單易用等特點，成為廣泛應用於各種場景的資料儲存解決方案。
11.說說你對Redis操作原子性的理解
Redis 的操作是原子性的，這是因為 Redis 的每個命令都是以單執行緒的方式執行的，整個命令的執行過程是不可中斷的，要麼全部執行成功，要麼全部執行失敗。
在 Redis 中，每個命令都會被轉換成一個或多個底層操作，這些操作會基於資料結構的特定實現來執行。比如，對於字串型別，獲取一個鍵值對、設定一個鍵值對等操作都是原子性的。在執行這些底層操作時，Redis 會使用一些技術來保證原子性，主要包括以下兩點：
-
Redis 使用單執行緒模型，避免了多執行緒之間的競爭條件和鎖開銷，從而保證了操作的原子性。
-
Redis 在執行一些複雜的操作時，比如事務、Lua 指令碼等，會將多個底層操作打包成一個原子性操作，這些底層操作要麼全部執行成功，要麼全部執行失敗。在事務和 Lua 指令碼中，Redis 同時支援回滾操作，即當一些命令執行成功，後面的命令出錯時，Redis 可以自動撤銷已經執行的命令。
因此，Redis 的操作是原子性的，這得益於 Redis 單執行緒模型和底層操作的實現方式。這種原子性操作保證了 Redis 能夠提供高效和可靠的服務。
12.說說Redis的持久化機制
Redis有兩種持久化機制：RDB和AOF。
-
RDB是一種快照持久化的方式，它會將Redis在某個時間點的資料狀態以二進位制的方式儲存到硬碟上的一個檔案中。RDB持久化可以透過配置定時或手動觸發，也可以設定自動觸發的條件。RDB的優點是生成的檔案比AOF檔案更小，恢復速度也更快，適合用於備份和災難恢復。
-
AOF是一種追加日誌持久化方式，它會將Redis執行的寫命令追加到一個檔案的末尾。當Redis重啟時，它會重新執行這些寫命令來恢復資料狀態。AOF提供了更可靠的持久化方式，因為它可以保證每個寫操作都被記錄下來，並且不會發生資料丟失的情況。AOF檔案可以根據配置進行同步寫入硬碟的頻率，包括每秒同步、每寫入命令同步和禁用同步三種模式。
在使用持久化機制時，可以選擇同時使用RDB和AOF，也可以只使用其中一種。同時使用兩種方式時，Redis在重啟時會先載入AOF檔案來恢復資料，如果AOF檔案不存在或損壞，則會嘗試載入RDB檔案。因此，AOF具有更高的優先順序。
總結
-
推薦兩者均開啟
-
如果對資料不敏感，可以選單獨用RDB
-
不建議單獨用AOF，因為可能會出現Bug
-
如果只是做純記憶體快取，可以都不用
13.MySQL 和 Redis 資料保持一致
MySQL 和 Redis 的關係：MySQL 是資料庫，用來持久化資料，一定程度上保證資料的可靠性；Redis 是用來當快取，用來提升資料訪問的效能。
1、快取不一致是如何產生的
通常快取不一致是發生在資料有變更的時候。因為每次資料變更你需要同時運算元據庫和快取，而他們又屬於不同的系統，無法做到同時操作成功或失敗，總會有一個時間差。在併發讀寫的時候可能就會出現快取不一致的問題（理論上透過分散式事務可以保證這一點，不過實際上基本上很少有人這麼做）。
2、快取更新的幾種設計
快取更新的設計方法大概有以下四種：
-
先刪除快取，再更新資料庫（這種方法在併發下最容易出現長時間的髒資料，不可取）
-
先更新資料庫，刪除快取（Cache Aside Pattern）
-
只更新快取，由快取自己同步更新資料庫（Read/Write Through Pattern）
-
只更新快取，由快取自己非同步更新資料庫（Write Behind Cache Pattern）
14.說說Redis的過期策略
Redis的過期策略主要有三種：惰性刪除、定期刪除和定期淘汰。
-
惰性刪除： 惰性刪除是Redis預設的過期鍵刪除策略。當客戶端嘗試訪問一個已過期的鍵時，Redis會立即將該鍵刪除，並返回空值。這種策略的優點是刪除操作是在需要時進行，減少了不必要的刪除開銷。但是，如果大量過期鍵在一次性被訪問之前沒有被訪問過，這些鍵會一直佔據記憶體空間。
-
定期刪除：Redis會每隔一段時間執行一次檢查，刪除那些已過期的鍵。預設情況下，Redis每秒執行10次檢查。定期刪除透過釋放過期鍵所佔據的記憶體空間，使得記憶體能夠及時被回收。但這種方式可能會導致記憶體佔用較高，因為Redis並不保證在每次定期刪除操作中都會刪除足夠數量的過期鍵。
-
定期淘汰： 定期淘汰是Redis 4.0版本引入的一種新的過期策略。與定期刪除不同的是，定期淘汰不僅刪除已過期的鍵，而且會主動查詢並淘汰一些尚未過期但是由於記憶體不足而需要釋放的鍵。透過定期淘汰，Redis可以更主動地管理記憶體，避免因為記憶體持續增長而導致系統效能下降。
總的來說，我們需要根據實際需求和業務場景選擇最適合的過期策略，以平衡記憶體使用和系統效能。
15.說說Redis的記憶體淘汰策略
Redis中的記憶體淘汰策略用於在記憶體不足時選擇要淘汰的鍵，以釋放記憶體空間。以下是幾種常見的記憶體淘汰策略：
-
LRU（最近最少使用）： LRU是Redis預設的記憶體淘汰策略。根據最近使用的時間戳來判斷鍵的熱度，將最久未被使用的鍵淘汰出去。這種策略保留了最近較常訪問的鍵，適合於熱點資料的場景。
-
LFU（最不經常使用）： LFU根據鍵被訪問的頻率來判斷熱度，淘汰訪問頻率最低的鍵。這種策略適用於訪問模式穩定但不同鍵的訪問頻率差異明顯的場景。
-
Random（隨機淘汰）： 隨機淘汰策略是一種基於機率的淘汰方法，隨機選擇一個鍵進行淘汰。這種策略簡單高效，但可能導致較高的快取命中率下降。
-
TTL（生存時間）： TTL策略基於鍵的過期時間，淘汰剩餘生存時間最短的鍵。適用於關注資料實效性的場景。
-
Maxmemory Policy（最大記憶體策略）： Redis提供了幾種最大記憶體策略，包括noeviction（禁止淘汰）、allkeys-lru、allkeys-random等。這些策略是在達到設定的最大記憶體限制後，對寫操作返回錯誤，避免繼續寫入導致系統崩潰。
在Redis中，可以透過配置檔案或動態命令來設定記憶體淘汰策略。根據具體的業務需求和資料訪問模式，選擇合適的記憶體淘汰策略以提高快取的效率和效能。
16.Redis有哪些常用應用場景
Redis的常用應用場景主要包括：
-
快取：作為高效能快取層，提供快速資料訪問。
-
分散式會話管理：實現跨伺服器的會話共享。
-
訊息佇列：用作中介軟體實現非同步通訊和任務佇列。
-
實時排行榜/計數器：用有序集合實現實時排名和計數功能。
-
地理位置資訊儲存與查詢：支援儲存地理位置資訊並進行位置查詢。
-
實時資料分析：儲存實時生成的資料，進行快速統計和分析。
需要注意根據具體場景合理使用，充分考慮記憶體容量和資料持久化等因素。同時，Redis也可與其他儲存系統結合使用構建複雜應用架構。
17.什麼是快取擊穿、快取穿透、快取雪崩
快取擊穿、快取穿透和快取雪崩是與快取相關的一些常見問題，具體定義如下：
-
快取擊穿：指當一個快取鍵（key）對應的資料在快取中不存在，同時又有大量併發請求訪問該快取鍵時，這些請求會直接繞過快取，查詢資料庫或其他儲存系統，導致資料庫壓力增大。快取擊穿通常在快取過期後發生。
-
快取穿透：指當一個查詢請求訪問一個不存在於快取中且也不存在於資料庫中的資料時，這個請求會無效地繼續訪問資料庫，而不會被快取。如果駭客故意傳送大量非法請求，則快取層無法起到過濾作用，可能導致資料庫負載過大。
-
快取雪崩：指當快取集中在某個時間點失效或由於某個原因發生故障，導致大量的請求直接打到後端資料庫，造成資料庫瞬時壓力過大，甚至引起資料庫崩潰。在快取雪崩期間，系統效能急劇下降，無法正常提供服務。
為了應對以上問題，可以採取以下措施：
-
對熱點資料採用永不過期策略，避免快取擊穿。
-
在快取層進行空值快取，即將查詢結果為空的資料也快取一段時間，避免快取穿透。
-
設定合理的快取過期時間，並使用分散式快取的多節點部署，避免快取雪崩。
-
引入限流、熔斷等機制，控制併發訪問量，保護後端系統。
-
對重要資料做冷備份，確保即使快取失效或故障，仍能從其他系統中恢復資料。
18.REDIS 叢集的原理是什麼
Redis 叢集透過資料分片和主從複製實現了橫向擴充套件和高可用性。它將資料劃分為 16384 個雜湊槽，並將這些槽均勻地分配到多個節點上。每個節點負責處理一部分槽的資料，實現了資料的分散儲存和負載均衡。
在叢集中，每個雜湊槽有一個主節點和多個從節點。主節點負責處理讀寫請求，而從節點則透過主從複製機制複製主節點的資料，提供資料的冗餘備份和故障恢復功能。
當主節點發生故障時，叢集會自動進行故障轉移。它會選舉一個從節點升級為新的主節點，保證服務的持續可用性。同時，叢集管理節點負責監控節點的狀態，並協調故障轉移過程。
客戶端在與 Redis 叢集互動時，根據鍵的雜湊值將請求傳送到相應的節點。客戶端還可以透過叢集管理節點獲取整個叢集的拓撲資訊，瞭解哪些鍵儲存在哪個節點上。
透過資料分片和主從複製，Redis 叢集實現了資料水平切分、負載均衡和高可用性。它允許資料規模和吞吐量的線性擴充套件，並能自動處理節點故障。叢集管理節點協調叢集狀態，客戶端透過雜湊槽對映與叢集互動，從而實現了一個穩定和可靠的 Redis 分散式系統。
19.REDIS叢集方案什麼情況下會導致整個叢集不可用
Redis 叢集在以下情況下可能導致整個叢集不可用：
-
多個主節點同時故障：如果多個主節點同時發生故障，而且它們的從節點無法正常升級為新的主節點，那麼整個叢集將無法提供讀寫服務。
-
叢集管理節點故障：叢集管理節點負責監控叢集狀態和協調故障轉移操作。如果叢集管理節點發生故障，並且無法及時恢復或替換，那麼叢集將失去管理和協調能力，可能導致叢集不可用。
-
網路分割槽：如果叢集中的節點之間發生網路分割槽，即無法互相通訊，那麼可能會引起腦裂（split-brain）問題。在這種情況下，每個分割槽內的節點可能會認為自己是合法的 Redis 叢集，導致資料衝突和不一致性，最終導致整個叢集無法正常工作。
-
配置錯誤：如果 Redis 叢集的配置出現錯誤或者某些節點的配置不一致，可能導致叢集無法正常執行。
-
記憶體不足：如果叢集中的某個節點的記憶體不足以容納當前處理的資料量，可能會導致該節點效能下降甚至崩潰，從而影響整個叢集的可用性。
為避免整個叢集不可用，建議採取以下措施：
-
配置正確的主從複製和故障轉移機制，確保每個主節點都有足夠的從節點，並定期進行故障轉移測試。
-
部署多個獨立的叢集管理節點，以確保高可用性和決策一致性。
-
定期檢查和監控叢集配置，確保各個節點之間的配置一致性。
-
實施網路分割槽容忍策略，例如使用網路拓撲結構和分散式一致性協議，以減少腦裂問題的發生。
-
監控叢集節點的記憶體使用情況，及時擴容或最佳化記憶體管理，避免記憶體不足問題。
綜上所述，要確保 Redis 叢集的高可用性和穩定性，需要合理設計和配置叢集架構，並採取適當的監控和容錯措施來應對潛在的故障情況。
20.REDIS叢集會有寫操作丟失嗎？為什麼
在Redis叢集中，由於採用了主從複製模型的非同步複製機制，寫操作有一定的丟失風險。
當客戶端向主節點傳送寫操作時，主節點會立即返回成功響應，而不等待所有從節點執行復制。如果主節點在執行完寫操作後出現故障或網路問題，導致從節點無法及時接收到複製操作，那麼這些未複製的寫操作將會丟失。
為了減少寫操作丟失的可能性，可以採取以下措施：
-
定期監測叢集狀態，確保主從節點之間的複製正常進行；
-
設定合理的持久化策略，將資料寫入磁碟或使用AOF模式以便資料恢復；
-
在應用程式層實施資料確認機制，檢查寫操作是否成功。
需要注意的是，Redis叢集的主從複製模型無法完全消除寫操作丟失的風險，但透過配置和監控的合理手段，可以最大限度地降低寫操作丟失的可能性，保障資料的安全性和可靠性。
21.說說你對PIPELINE的理解
PIPELINE 是 Redis 提供的最佳化命令執行的機制，透過減少網路往返次數和批次處理命令來提高效能。 它將多個命令打包傳送給伺服器，減少了網路延遲，提升了吞吐量。 使用 PIPELINE 還可以降低伺服器資源消耗，提高整體效率。適用於需要連續執行多個命令或批次操作的場景，特別適合延遲敏感或大量請求的應用程式。 總之，PIPELINE 是一種高效的方式來最佳化 Redis 命令執行，提升效能和效果。
22.什麼是Redis哨兵機制
Redis 哨兵是一種用於高可用性的解決方案，它可以監控 Redis 主從複製模式下的主節點和從節點，發現節點故障，並自動進行故障轉移，保證 Redis 系統的穩定性和可靠性。
Redis 哨兵機制由多個相互獨立的程序組成，這些程序使用 TCP/IP 協議相互通訊，實現 Redis 節點的監控和故障轉移。哨兵機制的關鍵程序包括：
-
sentinel：主程序，用於監控 Redis 節點的狀態，並執行故障轉移操作。
-
monitor：哨兵程序，用於監控 Redis 的主節點和從節點是否正常工作，並在需要時通知其他哨兵程序和客戶端。
-
judge：哨兵程序，用於對節點的健康狀況進行評估，並根據預定義的閾值決定是否要將一個不健康的節點標記為“主觀下線”。
-
failover：哨兵程序，負責執行故障轉移操作，將主節點故障時選舉出來的從節點晉升為新的主節點，並通知其他 Redis 節點更新配置資訊。
透過上述哨兵程序的協同工作，Redis 哨兵機制可以實現自動化的故障轉移，使得 Redis 的高可用性得到有效保障。在實際應用中，可以透過配置多個哨兵程序，使其互相監控和備份，從而進一步提高 Redis 系統的可靠性和穩定性。
23.說說你對快取雙寫不一致的理解
快取雙寫不一致是指在使用快取的架構中，當資料更新時，由於快取和資料庫的寫操作沒有同步進行，導致資料在快取和資料庫之間出現不一致的情況。
以下是對快取雙寫不一致的一般理解：
-
更新順序問題：當應用程式更新了資料庫中的資料，但在更新快取之前發生了錯誤或異常，導致快取中的資料仍然是舊值。這種情況下，資料庫中的資料已經被修改，但快取中的資料仍然是舊的，導致快取和資料庫之間存在不一致。
-
快取失效問題：當資料庫中的資料發生變化，併成功更新後，快取中的資料卻沒有及時更新或失效了。這可能是由於快取的過期策略、快取維護、網路延遲等原因導致的。此時，從快取讀取的資料將是舊值，與資料庫中的新值不一致。
-
併發更新問題：當多個應用程式同時更新相同的資料時，快取和資料庫的更新操作可能不是原子性的。如果兩個更新操作同時進行，可能會導致快取和資料庫在更新時發生衝突，導致不一致的結果。
為了解決快取雙寫不一致的問題，可以考慮以下方法：
-
快取更新策略：在更新資料庫的同時，立即更新快取，確保快取中的資料與資料庫中的資料保持一致。可以使用同步或非同步方式進行。
-
資料庫與快取的事務性操作：透過資料庫事務和快取的原子性操作來保證更新的一致性。
-
更新通知機制：透過釋出-訂閱（Pub/Sub）模式，或使用訊息佇列等機制來通知快取節點更新資料，確保快取的實時性。
-
使用強一致性快取：如 Redis 的事務和 pipeline 特性，可以確保對快取的多個操作按順序執行，減少不一致的機率。
-
定期重新整理快取：透過定期重新整理快取，保證快取中的資料不會過期太久，降低不一致性發生的機率。
綜上所述，快取雙寫不一致是在使用快取時常見的問題，透過合理的快取更新策略、事務性操作、更新通知機制等措施，可以有效地減少不一致的發生。
24.Redis 事務支援 ACID 麼？
原子性(Atomicity)：一個事務的多個操作必須完成，或者都不完成。
一致性(Consistency)：事務執行結束後，資料庫的完整性約束沒有被破壞，事務執行的前後順序都是合法資料狀態。
隔離性(Isolation)：事務內部的操作與其他事務是隔離的，併發執行的各個事務之間不能互相干擾。
永續性(Durability)：事務一旦提交，所有的修改將永久的儲存到資料庫中，即使系統崩潰重啟後資料也不會丟失。
25.主從複製的作用
-
① 讀寫分離：master 寫、slave 讀，提高伺服器的讀寫負載能力。
-
② 負載均衡：基於主從結構、配合讀寫分離，由 slave 分擔 master 負載，並根據需求的變化，改變 slave 的數量，透過多個從節點分擔資料讀取負載，大大提高 Redis 伺服器併發量和資料吞吐量。
-
③ 故障恢復：當 master 出現問題的時候，由 slave 提供服務，實現快速的故障恢復。
-
④ 資料冗餘：實現資料熱備份，是持久化之外的一種資料冗餘方式。
-
⑤ 高可用基石：基於主從複製，構建哨兵模式和叢集，實現 Redis 的高可用方案。
26.哨兵作用
-
① 監控：
-
-
不斷的檢查 master 和 slave 是否正常執行。
-
-
-
master 存活檢測、master 和 slave 執行情況檢測。
-
-
② 通知（提醒）：當被監控的伺服器出現問題的時候，向其他（哨兵間、客戶端）傳送通知。
-
③ 自動故障轉移：斷開 master 和 slave 之間的連線，選取一個 slave 作為 master ，將其它 slave 連線到新的 master 上，並告知客戶端新的伺服器地址。
總結
-
監控：同步資訊。
-
通知：保持聯通。
-
故障轉移：
-
-
發現問題。
-
-
-
競選負責人。
-
-
-
優選新 master 。
-
-
-
新 master 上任，其他 slave 切換 master ，原來的 master 作為 slave 故障恢復後連線。
-
27.叢集作用
-
-
① 分散單臺伺服器的訪問壓力，實現負載均衡。
-
-
-
② 分散單臺伺服器的儲存壓力，實現可擴充套件性。
-
-
-
③ 降低單臺伺服器當機帶來的業務災難。
-
28.分散式鎖應該具備哪些條件？
一個最基本的分散式鎖需要滿足：
-
互斥：任意一個時刻，鎖只能被一個執行緒持有。
-
高可用：鎖服務是高可用的，當一個鎖服務出現問題，能夠自動切換到另外一個鎖服務。並且，即使客戶端的釋放鎖的程式碼邏輯出現問題，鎖最終一定還是會被釋放，不會影響其他執行緒對共享資源的訪問。這一般是透過超時機制實現的。
-
可重入：一個節點獲取了鎖之後，還可以再次獲取鎖。
除了上面這三個基本條件之外，一個好的分散式鎖還需要滿足下面這些條件：
-
高效能：獲取和釋放鎖的操作應該快速完成，並且不應該對整個系統的效能造成過大影響。
-
非阻塞