阿里、騰訊面試中總結 11個 高頻 Redis 面試題

⭐高頻面試題：

1. Redis持久化機制
2. 緩存雪崩、緩存穿透、緩存預熱、緩存更新、緩存降級等問題
3. 熱點數據和冷數據是什麼
4. Memcache與Redis的區別都有哪些？
5. 單線程的redis為什麼這麼快
6. redis的數據類型，以及每種數據類型的使用場景
7. redis的過期策略以及內存淘汰機制
8. Redis 為什麼是單線程的
9. Redis 常見性能問題和解決方案？
10. 為什麼Redis的操作是原子性的，怎麼保證原子性的？
11. Redis事務

12.TODO...........

⭐Redis系列高頻面試題解析

⭐1. Redis持久化機制

Redis是一個支持持久化的內存數據庫，通過持久化機制把內存中的數據同步到硬盤文件來保證數據持久化。

當Redis重啟後通過把硬盤文件重新加載到內存，就能達到恢復數據的目的。實現：單獨創建fork()一個子進程

，將當前父進程的數據庫數據複製到子進程的內存中，然後由子進程寫入到臨時文件中，

持久化的過程結束了，再用這個臨時文件替換上次的快照文件，然後子進程退出，內存釋放。

RDB：

RDB是Redis默認的持久化方式。

按照一定的時間週期策略把內存的數據以快照的形式保存到硬盤的二進制文件。即Snapshot快照存儲，

對應產生的數據文件為dump.rdb，通過配置文件中的save參數來定義快照的週期。（快照可以是其所表示的數據的一個副本，也可以是數據的一個複製品。）

• RDB持久化缺點

無法做到實時持久化，具有較大可能丟失數據

存儲數量較大時，效率較低，I／O性能較低

基於fork創建子進程，內存產生額外消耗

宕機帶來的數據丟失風險

AOF：

Redis會將每一個收到的寫命令都通過Write函數追加到文件最後，類似於MySQL的binlog。

當Redis重啟是會通過重新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。

• AOF 優點
• AOF 可以更好的保護 數據不丟失，一般 AOF 會每隔 1 秒，最多丟失 1 秒鐘的數據。
• 寫入性能非常高，而且文件不容易破損
• 適合做災難性的誤刪除的緊急恢復。
• AOF 缺點

對於同一份數據來說，AOF 日誌文件通常比 RDB 數據快照文件更大。

恢復速度較慢

• 當兩種方式同時開啟時，數據恢復Redis會優先選擇AOF恢復。

RDB 與 AOF 如何選擇

對數據非常敏感，建議使用默認的AOF持久化方案

AOF策略使用everysec，每秒fsync一次，該策略仍可保持很好性能，出現問題最多丟失一秒內的數據

數據可以做到階段內無丟失，且恢復較快，階段點數據恢復通常使用RDB方案

綜合：

如果不能承受分鐘內的數據丟失，對業務數據非常敏感，選用AOF

如果能承受分鐘內的數據丟失，且追求大數據集的恢復速度選用RDB，RDB 非常適合災難恢復。

雙保險策略，同時開啟RDB和AOF，重啟後Redis優先使用AOF來恢復數據，降低丟失數據量

⭐2. 緩存雪崩、緩存穿透、緩存預熱、緩存更新、緩存降級等問題

緩存雪崩

我們可以簡單的理解為：由於原有緩存失效，新緩存未到期間(例如：我們設置緩存時採用了相同的過期時間，在同一時刻出現大面積的緩存過期)，所有原本應該訪問緩存的請求都去查詢數據庫了，而對數據庫CPU和內存造成巨大壓力，嚴重的會造成數據庫宕機。從而形成一系列連鎖反應，造成整個系統崩潰。

• 解決方案：
  大多數系統設計者考慮用加鎖（ 最多的解決方案）或者隊列的方式保證來保證不會有大量的線程對數據庫一次性進行讀寫，從而避免失效時大量的併發請求落到底層存儲系統上。還有一個簡單方案就是講緩存失效時間分散開。

緩存穿透

緩存穿透是指用戶查詢數據，在數據庫沒有，自然在緩存中也不會有。這樣就導致用戶查詢的時候，在緩存中找不到，每次都要去數據庫再查詢一遍，然後返回空（相當於進行了兩次無用的查詢）。這樣請求就繞過緩存直接查數據庫，這也是經常提的緩存命中率問題。

• 解決方案：

最常見的則是採用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。

另外也有一個更為簡單粗暴的方法，如果一個查詢返回的數據為空（不管是數據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘。

通過這個直接設置的默認值存放到緩存，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問數據庫，這種辦法最簡單粗暴。5TB的硬盤上放滿了數據，請寫一個算法將這些數據進行排重。

如果這些數據是一些32bit大小的數據該如何解決？如果是64bit的呢？對於空間的利用到達了一種極致，那就是Bitmap和布隆過濾器(Bloom Filter)。

Bitmap： 典型的就是哈希表缺點是，Bitmap對於每個元素只能記錄1bit信息，如果還想完成額外的功能，恐怕只能靠犧牲更多的空布隆過濾器（推薦）就是引入了k(k>1)k(k>1)個相互獨立的哈希函數，保證在給定的空間、誤判率下，完成元素判重的過程。

它的優點是空間效率和查詢時間都遠遠超過一般的算法，缺點是有一定的誤識別率和刪除困難。Bloom-Filter算法的核心思想就是利用多個不同的Hash函數來解決“衝突”。Hash存在一個衝突（碰撞）的問題，用同一個Hash得到的兩個URL的值有可能相同。

為了減少衝突，我們可以多引入幾個Hash，如果通過其中的一個Hash值我們得出某元素不在集合中，那麼該元素肯定不在集合中。只有在所有的Hash函數告訴我們該元素在集合中時，才能確定該元素存在於集合中。這便是Bloom-Filter的基本思想。

Bloom-Filter一般用於在大數據量的集合中判定某元素是否存在。

緩存預熱

緩存預熱這個應該是一個比較常見的概念，相信很多小夥伴都應該可以很容易的理解，緩存預熱就是系

統上線後，將相關的緩存數據直接加載到緩存系統。這樣就可以避免在用戶請求的時候，先查詢數據

庫，然後再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！

• 解決思路

（1）直接寫個緩存刷新頁面，上線時手工操作下；

（2）數據量不大，可以在項目啟動的時候自動進行加載；

（3）定時刷新緩存；

（4）緩存更新

除了緩存服務器自帶的緩存失效策略之外（Redis默認的有6中策略可供選擇），我們還可以根據具體的業務需求進行自定義的緩存淘汰，常見的策略有兩種：

（1）定時去清理過期的緩存；

（2）當有用戶請求過來時，再判斷這個請求所用到的緩存是否過期，過期的話就去底層系統得到新數據並更新緩存。

兩者各有優劣，第一種的缺點是維護大量緩存的key是比較麻煩的，第二種的缺點就是每次用戶請求過來都要判斷緩存失效，邏輯相對比較複雜！具體用哪種方案，大家可以根據自己的應用場景來權衡。

緩存降級

當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵數據進行自動降級，也可以配置開關實現人工降級。降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。

以參考日誌級別設置預案：

（1）一般：比如有些服務偶爾因為網絡抖動或者服務正在上線而超時，可以自動降級；

（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，併發送告警；

（3）錯誤：比如可用率低於90%，或者數據庫連接池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；

（4）嚴重錯誤：比如因為特殊原因數據錯誤了，此時需要緊急人工降級。服務降級的目的，是為了防止Redis服務故障，導致數據庫跟著一起發生雪崩問題。因此，對於不重要的緩存數據，可以採取服務降級策略，例如一個比較常見的做法就是，Redis出現問題，不去數據庫查詢，而是直接返回默認值給用戶。

⭐3. 熱點數據和冷數據是什麼

熱點數據，緩存才有價值對於冷數據而言，大部分數據可能還沒有再次訪問到就已經被擠出內存，不僅佔用內存，而且價值不場景。對於熱點數據， 比如我們的某IM產品，生日祝福模塊，當天的壽星列表，緩存以後可能讀取數十萬次。

再舉個例子，某導航產品，我們將導航信息，緩存以後可能讀取數百萬次。數據更新前至少讀取兩次，緩存才有意義。 這個是最基本的策略，如果緩存還沒有起作用就失效了，那就沒有太大價值了。

那存不存在，修改頻率很高，但是又不得不考慮緩存的場景呢？有！比如，這個讀取接口對數據庫的壓力很大，但是又是熱點數據， 這個時候就需要考慮通過緩存手段，減少數據庫的壓力，

比如我們的某助手產品的，點贊數，收藏數，分享數等是非常典型的熱點數據，但是又不斷變化， 此時就需要將數據同步保存到Redis緩存，減少數據庫壓力。

⭐4. Memcache與Redis的區別都有哪些？

1、存儲方式 Memecache把數據全部存在內存之中，斷電後會掛掉，數據不能超過內存大小。 Redis有部份存在硬盤上，redis可以持久化其數據

2、數據支持類型 memcached所有的值均是簡單的字符串，redis作為其替代者，支持更為豐富的數據類型 ，提供list，set，zset，hash等數據結構的存儲

3、使用底層模型不同 它們之間底層實現方式 以及與客戶端之間通信的應用協議不一樣。 Redis直接自己構建了VM 機制 ，因為一般的系統調用系統函數的話，會浪費一定的時間去移動和請求。

4、 value 值大小不同：Redis 最大可以達到 1gb；memcache 只有 1mb。

5、redis的速度比memcached快很多6、Redis支持數據的備份，即master-slave模式的數據備份。

⭐5. 單線程的redis為什麼這麼快

1、純內存操作

2、單線程操作，避免了頻繁的上下文切換

3、採用了非阻塞I/O多路複用機制

⭐6. redis的數據類型，以及每種數據類型的使用場景（5種）

1、String這個其實沒啥好說的，最常規的set/get操作，value可以是String也可以是數字。一般做一些複雜的計數功能的緩存。

2、hash這裡value存放的是結構化的對象，比較方便的就是操作其中的某個字段。博主在做單點登錄的時候，就是用這種數據結構存儲用戶信息，以cookieId作為key，設置30分鐘為緩存過期時間，能很好的模擬出類似session的效果。

3、list使用List的數據結構，可以做簡單的消息隊列的功能。另外還有一個就是，可以利用lrange命令，做基於redis的分頁功能，性能極佳，用戶體驗好。本人還用一個場景，很合適—取行情信息。就也是個生產者和消費者的場景。LIST可以很好的完成排隊，先進先出的原則。

4、set因為set堆放的是一堆不重複值的集合。所以可以做全局去重的功能。為什麼不用JVM自帶的Set進行去重？因為我們的系統一般都是集群部署，使用JVM自帶的Set，比較麻煩，難道為了一個做一個全局去重，再起一個公共服務，太麻煩了。另外，就是利用交集、並集、差集等操作，可以計算共同喜好，全部的喜好，自己獨有的喜好等功能。

5、sorted set

⭐7. redis的過期策略以及內存淘汰機制

redis採用的是定期刪除+惰性刪除策略。

為什麼不用定時刪除策略?

定時刪除,用一個定時器來負責監視key,過期則自動刪除。雖然內存及時釋放，但是十分消耗CPU資源。

在大併發請求下，CPU要將時間應用在處理請求，而不是刪除key,因此沒有采用這一策略.

定期刪除+惰性刪除是如何工作的呢?

• 定期刪除

redis默認每個100ms檢查，是否有過期的key,有過期key則刪除。需要說明的是，redis不是每個100ms將所有的key檢查一次，而是隨機抽取進行檢查(如果每隔100ms,全部key進行檢查，redis豈不是卡死)。

為什麼要隨機呢？你想一想假如 redis 存了幾十萬個 key ，每隔100ms就遍歷所有的設置過期時間的 key 的話，就會給 CPU 帶來很大的負載！

因此，如果只採用定期刪除策略，會導致很多key到時間沒有刪除。於是，惰性刪除派上用場。

也就是說在你獲取某個key的時候，redis會檢查一下，這個key如果設置了過期時間那麼是否過期了？

如果過期了此時就會刪除。

惰性刪除 ：定期刪除可能會導致很多過期 key 到了時間並沒有被刪除掉。所以就有了惰性刪除。假如你的過期 key，靠定期刪除沒有被刪除掉，還停留在內存裡，除非你的系統去查一下那個 key，才會被redis給刪除掉。

採用定期刪除+惰性刪除就沒其他問題了麼?

不是的，但是僅僅通過設置過期時間還是有問題的。我們想一下：如果定期刪除漏掉了很多過期 key，然後你也沒及時去查，也就沒走惰性刪除，此時會怎麼樣？如果大量過期key堆積在內存裡，導致redis內存塊耗盡了。怎麼解決這個問題呢？

redis 內存淘汰機制。

⭐redis數據淘汰機制

當內存到達最大內存限制時進行的數據淘汰策略

1. 新寫入操作會報錯。（Redis 默認策略）
2. 在鍵空間中，移除最近最少使用的 Key。（LRU推薦使用）
3. 在鍵空間中，隨機移除某個 Key。
4. 在設置了過期時間的鍵空間中，移除最近最少使用的 Key。這種情況一般是把 Redis 既當緩存，又做持久化存儲的時候才用。
5. 在設置了過期時間的鍵空間中，隨機移除某個 Key。
6. 在設置了過期時間的鍵空間中，有更早過期時間的 Key 優先移除。

• LRU 算法實現：1.通過雙向鏈表來實現，新數據插入到鏈表頭部；2.每當緩存命中（即緩存

數據被訪問），則將數據移到鏈表頭部；3.當鏈表滿的時候，將鏈表尾部的數據丟棄。

LinkedHashMap：HashMap 和雙向鏈表合二為一即是 LinkedHashMap。HashMap 是無序

的，LinkedHashMap 通過維護一個額外的雙向鏈表保證了迭代順序。該迭代順序可以是插

入順序（默認），也可以是訪問順序。

• 拓展：

Redis的LRU具體實現

傳統的LRU是使用棧的形式，每次都將最新使用的移入棧頂，但是用棧的形式會導致執行select *的時候大量非熱點數據佔領頭部數據，

所以需要改進。Redis每次按key獲取一個值的時候，都會更新value中的lru字段為當前秒級別的時間戳。Redis初始的實現算法很簡單，

隨機從dict中取出五個key,淘汰一個lru字段值最小的。在3.0的時候，又改進了一版算法，首先第一次隨機選取的key都會放入一個pool中(pool的大小為16),

pool中的key是按lru大小順序排列的。接下來每次隨機選取的keylru值必須小於pool中最小的lru才會繼續放入，直到將pool放滿。

放滿之後，每次如果有新的key需要放入，需要將pool中lru最大的一個key取出。淘汰的時候，直接從pool中選取一個lru最小的值然後將其淘汰。

上代碼：

在redis.conf中有一行配置

<code>maxmemory-policy volatile-lru
複製代碼/<code>

複製代碼該配置就是配內存淘汰策略的(什麼，你沒配過？好好反省一下自己)

volatile-lru：從已設置過期時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰

volatile-ttl：從已設置過期時間的數據集（server.db[i].expires）中挑選將要過期的數據淘汰

volatile-random：從已設置過期時間的數據集（server.db[i].expires）中任意選擇數據淘汰

allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰

allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰

no-enviction（驅逐）：禁止驅逐數據，新寫入操作會報錯

補充：如果沒有設置 expire 的key, 不滿足先決條件(prerequisites); 那麼 volatile-lru, volatile-random 和volatile-ttl 策略的行為, 和 noeviction(不刪除) 基本上一致。

⭐8. Redis 為什麼是單線程的

因為Redis是基於內存的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器內存的大小 或者網絡帶寬。既然單線程容易實現，而且CPU不會成為瓶頸，那就順理成章地採用單線程的

方案了（畢竟採用多線程會有很多麻煩！）

Redis利用隊列技術將併發訪問變為串行訪問

1、絕大部分請求是純粹的內存操作（非常快速）

2、採用單線程,避免了不必要的上下文切換和競爭條件

3、非阻塞IO優點：

1）速度快，因為數據存在內存中，類似於HashMap，HashMap的優勢就是查找和操作的時間複雜度都是O(1)

2）支持豐富數據類型，支持string，list，set，sorted set，hash

3）支持事務，操作都是原子性，所謂的原子性就是對數據的更改要麼全部執行，要麼全部不執行

4）豐富的特性：可用於緩存，消息，按key設置過期時間，過期後將會自動刪除如何解決

redis的併發競爭key問題同時有多個子系統去set一個key。這個時候要注意什麼呢？

不推薦使用redis的事務機制。

因為我們的生產環境，基本都是redis集群環境，做了數據分片操作。你一個事務中有涉及到

多個key操作的時候，這多個key不一定都存儲在同一個redis-server上。因此，redis的

事務機制，十分雞肋。

(1)如果對這個key操作，不要求順序： 準備一個分佈式鎖，大家去搶鎖，搶到鎖就做set操作即可作了。以此類推。

(2) 利用隊列，將set方法變成串行訪問也可以redis遇到高併發，如果保證讀寫key的一致性對redis的操作都是具有原子性的,是線程安全的操作,你不用考慮併發問題,redis內部已經幫你處理好併發的問題了

⭐9. Redis 常見性能問題和解決方案？

1、Master 最好不要做任何持久化工作，如 RDB 內存快照和 AOF 日誌文件

2、 如果數據比較重要，某個 Slave 開啟 AOF 備份數據，策略設置為每秒同步一次

3、為了主從複製的速度和連接的穩定性， Master 和 Slave 最好在同一個局域網內

4、儘量避免在壓力很大的主庫上增加從庫

5、主從複製不要用圖狀結構，用單向鏈表結構更為穩定，即： Master

⭐10. 為什麼Redis的操作是原子性的，怎麼保證原子性的？

對於Redis而言，命令的原子性指的是：一個操作的不可以再分，操作要麼執行，要麼不執行。

Redis的操作之所以是原子性的，是因為Redis是單線程的。

Redis本身提供的所有API都是原子操作，Redis中的事務其實是要保證批量操作的原子性。

多個命令在併發中也是原子性的嗎？不一定， 將get和set改成單命令操作，incr 。使用Redis的事務，或者使用Redis+Lua==的方式實現.

⭐11. Redis事務

Redis事務功能是通過MULTI、EXEC、DISCARD和WATCH 四個原語實現的Redis會將一個事務中的所有命令序列化，然後按順序執行。

1、redis 不支持回滾“Redis 在事務失敗時不進行回滾，而是繼續執行餘下的命令”， 所以 Redis 的內部可以保持簡單且快速。

2、如果在一個事務中的命令出現錯誤，那麼所有的命令都不會執行；3、如果在一個事務中出現運行錯誤，那麼正確的命令會被執行。

• （1）MULTI命令用於開啟一個事務，它總是返回OK。 MULTI執行之後，客戶端可以繼續向服務器發送任意多條命令，這些命令不會立即被執行，而是被放到一個隊列中，當EXEC命令被調用時，所有隊列中的命令才會被執行。
• （2）EXEC：執行所有事務塊內的命令。返回事務塊內所有命令的返回值，按命令執行的先後順序排列。當操作被打斷時，返回空值 nil 。
• （3）通過調用DISCARD，客戶端可以清空事務隊列，並放棄執行事務， 並且客戶端會從事務狀態中退出。
• （4）WATCH 命令可以為 Redis 事務提供 check-and-set （CAS）行為。 可以監控一個或多個鍵，一旦其中有一個鍵被修改（或刪除），之後的事務就不會執行，監控一直持續到EXEC命令。

這是一條分割線-------------------------------------------------------------- 這是一條分割線

TODO(20200408)

⭐應用場景

1. 緩存
2. 共享Session
3. 消息隊列系統
4. 分佈式鎖

⭐zset跳錶的數據結構

增加了向前指針的鏈表叫作跳錶跳錶是一個隨機化的數據結構，實質就是一種可以進行二分查找的有序鏈表。跳錶在原有的有序鏈表上面增加了多級索引，通過索引來實現快速查找。跳錶不僅能提高搜索性能，同時也可以提高插入和刪除操作的性能。

• 原理：

跳錶在原有的有序鏈表上面增加了多級索引，通過索引來實現快速查找。首先在最高級索引上查找最後一個小於當前查找元素的位置，然後再跳到次高級索引繼續查找，直到跳到最底層為止，這時候以及十分接近要查找的元素的位置了(如果查找元素存在的話)。

由於根據索引可以一次跳過多個元素，所以跳查找的查找速度也就變快了。

• 為什麼使用跳躍表

首先，因為 zset 要支持隨機的插入和刪除，所以它 不宜使用數組來實現，關於排序問題，我們也很容易就想到 紅黑樹/ 平衡樹 這樣的樹形結構，為什麼 Redis 不使用這樣一些結構呢？

1. 性能考慮： 在高併發的情況下，樹形結構需要執行一些類似於 rebalance 這樣的可能涉及整棵樹的操作，相對來說跳躍表的變化只涉及局部 (下面詳細說)；
2. 實現考慮： 在複雜度與紅黑樹相同的情況下，跳躍表實現起來更簡單，看起來也更加直觀；

⭐redis 設置過期時間

Redis中有個設置時間過期的功能，即對存儲在 redis 數據庫中的值可以設置一個過期時間。作為一個緩存數據庫，這是非常實用的。如我們一般項目中的 token 或者一些登錄信息，

尤其是短信驗證碼都是有時間限制的，按照傳統的數據庫處理方式，一般都是自己判斷過期，這樣無疑會嚴重影響項目性能。

我們 set key 的時候，都可以給一個 expire time，就是過期時間，通過過期時間我們可以指定這個 key 可以存活的時間。

如果假設你設置了一批 key 只能存活1個小時，那麼接下來1小時後，redis是怎麼對這批key進行刪除的？(數據過期策略)

⭐怎麼保證緩存和數據庫數據的一致性？

分佈式環境下非常容易出現緩存和數據庫間數據一致性問題，針對這一點，如果項目對緩存的要求是強一致性的，那麼就不要使用緩存。

我們只能採取合適的策略來降低緩存和數據庫間數據不一致的概率，而無法保證兩者間的強一致性。

• 合理設置緩存的過期時間。
• 新增、更改、刪除數據庫操作時同步更新 Redis，可以使用事務機制來保證數據的一致性。
• 緩存失敗時增加重試機制。

⭐redis 怎麼實現分佈式鎖？

Redis 分佈式鎖其實就是在系統裡面佔一個“坑”，其他程序也要佔“坑”的時候，佔用成功了就可以繼續執行，失敗了就只能放棄或稍後重試。

佔坑一般使用 setnx(set if not exists)指令，只允許被一個程序佔有，使用完調用 del 釋放鎖

也可以配合EXPIRE key seconds自動釋放鎖

設置key的生存時間,當key過期時(生存時間為0) ,會被自動刪除

缺陷 ：原子性沒有得到滿足，所以不建議。

⭐實際項目中使用緩存有遇到什麼問題或者會遇到什麼問題你知道嗎？

緩存和數據庫數據一致性問題

主從複製

作用：

讀寫分離：master寫、slave讀，提高服務器的讀寫負載能力

負載均衡：基於主從結構，配合讀寫分離，由slave分擔master負載，並根據需求的變化，改變slave的數量，通過多個從節點分擔數據讀取負載，大大提高Redis服務器併發量與數據吞吐量

故障恢復：當master出現問題時，由slave提供服務，實現快速的故障恢復

數據冗餘：實現數據熱備份，是持久化之外的一種數據冗餘方式

高可用基石：基於主從複製，構建哨兵模式與集群，實現Redis的高可用方案

過程：

• 從節點執行 slaveof IP，port 發送指令
• 主節點響應
• 從節點保存主節點信息（IP，port），建立和主節點的 Socket 連接。
• 從節點發送 Ping 信號，主節點返回 Pong，確定兩邊能互相通信。
• 連接建立後，主節點將所有數據發送給從節點（數據同步）。
• 主節點把當前的數據同步給從節點後，便完成了複製的建立過程。接下來，主節點就會持續的把寫命令發送給從節點，保證主從數據一致性。

複製/數據同步過程分為兩個階段

1. 全量複製： slave接收到master生成的RDB文件，先清空自身的舊數據，然後執行RDB恢復過程，然後告知master已經恢復完畢。
2. 部分複製（增量複製） 主節點發送數據給從節點過程中，主節點還會進行一些寫操作，這時候的數據存儲在複製緩衝區中。master把自己之前創建的複製緩衝區的數據發送到slave，slave接收到aof指令後執行重寫操作，恢復數據。

主從複製會存在以下問題：

• 一旦主節點宕機，從節點晉升為主節點，同時需要修改應用方的主節點地址，還需要命令所有從節點去複製新的主節點，整個過程需要人工干預。
• 主節點的寫能力受到單機的限制。
• 主節點的存儲能力受到單機的限制。

哨兵：

哨兵(sentinel) 是一個分佈式系統，用於對主從結構中的每臺服務器進行監控，當出現故障時通過投票機制選擇新的master並將所有slave連接到新的master。

作用：

• 監控

不斷的檢查master和slave是否正常運行。master存活檢測、master與slave運行情況檢測

• 通知（提醒）

當被監控的服務器出現問題時，向其他（哨兵間，客戶端）發送通知。

• 自動故障轉移

斷開master與slave連接，選取一個slave作為master，將其他slave連接到新的master，並告知客戶端新的服務器地址

作者：『十二』鏈接：https://juejin.im/post/5e8e81a25188257375468105

感悟

從正式成為一名程序員的那天起，註定要進行沒有止境的學習，想要進階高級或者專家，就要堅持每天都高效的學習，不要給自己的懶惰找藉口，“什麼我也想學習可是又沒有資源”，這次我給你整理好了，我看你還有啥理由！私信回覆【666】送你

閱讀更多 程序員內點事 的文章

關鍵字: 中央處理器 騰訊 數據庫