共計 4311 個字符，預計需要花費 11 分鐘才能閱讀完成。
自動寫代碼機器人，免費開通
這篇文章主要介紹了 Redis 中高可用和高并發(fā)機制是什么意思，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓丸趣 TV 小編帶著大家一起了解一下。
一、高并發(fā)機制
我們知道 redis 是基于單線程的，在單機模式下能承載的也就幾萬左右吧，所以怎么提高其在大數(shù)據(jù)下幾十萬的高并發(fā)請求，通過 redis 的主從架構和讀寫分離。
1. 主從復制
redis 主從復制的配置就不強調(diào)，主要看主從復制的原理及過程：在進行 redis 的主從復制的過程中，需要一臺 master 主機作為管理員，去搭建多臺 slave 從機。當 slave 從機試圖啟動時會向 master 主機發(fā)送一個命令 PSYNC, 如果這個時候 slave 從機是重新連接的，那么會從 master 主機上把 slave 從機沒有的數(shù)據(jù)復制過去，如果是第一次連接那么會觸發(fā) full resynchronization。觸發(fā)以后 master 主機會在后臺開啟一個進程去生成一個 RDB 快照文件，同時將這個時間段的寫操作存入緩存，當這個 RDB 文件生成完畢之后會向 slave 從機發(fā)送 RDB 文件，從機拿到文件之后將其先寫入磁盤然后加載進入內(nèi)存最后 master 主機會將緩存在內(nèi)存里面的數(shù)據(jù)也同時發(fā)送給從機。如果在發(fā)生主從的網(wǎng)絡故障的情況下，有多個 slave 從機重新連接那么 master 只會重啟一份 RDB 去服務全部 slave。
斷點續(xù)傳：在 master 和 slave 里面都有一個 replica offset 里面還有一個 master id，其中 offset 就是保持在 backlog，當主從機發(fā)生網(wǎng)絡故障重連時，會去找到對應的上次 replica offset 的地方進行復制，如果沒有找到對應的 offset 那么觸發(fā) full resynchronization。
①復制的完整流程
（1）slave node 啟動，僅僅保存 master node 的信息，包括 master node 的 host 和 ip，但是復制流程沒開始
master host 和 ip 是從哪兒來的，redis.conf 里面的 slaveof 配置的
（2）slave node 內(nèi)部有個定時任務，每秒檢查是否有新的 master node 要連接和復制，如果發(fā)現(xiàn)，就跟 master node 建立 socket 網(wǎng)絡連接
（3）slave node 發(fā)送 ping 命令給 master node
（4）口令認證，如果 master 設置了 requirepass，那么 salve node 必須發(fā)送 masterauth 的口令過去進行認證
（5）master node 第一次執(zhí)行全量復制，將所有數(shù)據(jù)發(fā)給 slave node
（6）master node 后續(xù)持續(xù)將寫命令，異步復制給 slave node
②數(shù)據(jù)同步相關的核心機制
指的就是第一次 slave 連接 msater 的時候，執(zhí)行的全量復制，那個過程里面你的一些細節(jié)的機制
（1）master 和 slave 都會維護一個 offset
master 會在自身不斷累加 offset，slave 也會在自身不斷累加 offset
slave 每秒都會上報自己的 offset 給 master，同時 master 也會保存每個 slave 的 offset
這個倒不是說特定就用在全量復制的，主要是 master 和 slave 都要知道各自的數(shù)據(jù)的 offset，才能知道互相之間的數(shù)據(jù)不一致的情況
（2）backlog
master node 有一個 backlog，默認是 1MB 大小
master node 給 slave node 復制數(shù)據(jù)時，也會將數(shù)據(jù)在 backlog 中同步寫一份
backlog 主要是用來做全量復制中斷候的增量復制的
（3）master run id
info server，可以看到 master run id
如果根據(jù) host+ip 定位 master node，是不靠譜的，如果 master node 重啟或者數(shù)據(jù)出現(xiàn)了變化，那么 slave node 應該根據(jù)不同的 run id 區(qū)分，run id 不同就做全量復制
如果需要不更改 run id 重啟 redis，可以使用 redis-cli debug reload 命令
（4）psync
從節(jié)點使用 psync 從 master node 進行復制，psync runid offset
master node 會根據(jù)自身的情況返回響應信息，可能是 FULLRESYNC runid offset 觸發(fā)全量復制，可能是 CONTINUE 觸發(fā)增量復制
③全量復制
（1）master 執(zhí)行 bgsave，在本地生成一份 rdb 快照文件
（2）master node 將 rdb 快照文件發(fā)送給 salve node，如果 rdb 復制時間超過 60 秒（repl-timeout），那么 slave node 就會認為復制失敗，可以適當調(diào)節(jié)大這個參數(shù)
（3）對于千兆網(wǎng)卡的機器，一般每秒傳輸 100MB，6G 文件，很可能超過 60s
（4）master node 在生成 rdb 時，會將所有新的寫命令緩存在內(nèi)存中，在 salve node 保存了 rdb 之后，再將新的寫命令復制給 salve node
（5）client-output-buffer-limit slave 256MB 64MB 60，如果在復制期間，內(nèi)存緩沖區(qū)持續(xù)消耗超過 64MB，或者一次性超過 256MB，那么停止復制，復制失敗
（6）slave node 接收到 rdb 之后，清空自己的舊數(shù)據(jù)，然后重新加載 rdb 到自己的內(nèi)存中，同時基于舊的數(shù)據(jù)版本對外提供服務
（7）如果 slave node 開啟了 AOF，那么會立即執(zhí)行 BGREWRITEAOF，重寫 AOF
rdb 生成、rdb 通過網(wǎng)絡拷貝、slave 舊數(shù)據(jù)的清理、slave aof rewrite，很耗費時間
如果復制的數(shù)據(jù)量在 4G~6G 之間，那么很可能全量復制時間消耗到 1 分半到 2 分鐘
④增量復制
（1）如果全量復制過程中，master-slave 網(wǎng)絡連接斷掉，那么 salve 重新連接 master 時，會觸發(fā)增量復制
（2）master 直接從自己的 backlog 中獲取部分丟失的數(shù)據(jù)，發(fā)送給 slave node，默認 backlog 就是 1MB
（3）msater 就是根據(jù) slave 發(fā)送的 psync 中的 offset 來從 backlog 中獲取數(shù)據(jù)的
⑤heartbeat
主從節(jié)點互相都會發(fā)送 heartbeat 信息
master 默認每隔 10 秒發(fā)送一次 heartbeat，salve node 每隔 1 秒發(fā)送一個 heartbeat
⑥異步復制
master 每次接收到寫命令之后，現(xiàn)在內(nèi)部寫入數(shù)據(jù)，然后異步發(fā)送給 slave node
2. 讀寫分離：master 負責寫入操作，slave 負責幫 master 減輕訪問查詢量
二、高可用機制
在高并發(fā)的情況下，配備多集群一主多備，雖然可以解決高并發(fā)問題，但是主機只有一個，master 宕機那么整個無法進行寫操作，從機無法同步數(shù)據(jù)整個系統(tǒng)會處于癱瘓狀態(tài)，整就一個不可用。redis 的高可用機制哨兵機制，哨兵是 redis 集群里面的重要的組件，他負責集群監(jiān)控，信息通知，故障轉(zhuǎn)移，配置中心。
（1）集群監(jiān)控，負責監(jiān)控 redis master 和 slave 進程是否正常工作
（2）消息通知，如果某個 redis 實例有故障，那么哨兵負責發(fā)送消息作為報警通知給管理員
（3）故障轉(zhuǎn)移，如果 master node 掛掉了，會自動轉(zhuǎn)移到 slave node 上
（4）配置中心，如果故障轉(zhuǎn)移發(fā)生了，通知 client 客戶端新的 master 地址
哨兵本身是分布式的，是作為一個集群去工作的，需要互相協(xié)同工作。
當發(fā)現(xiàn) master node 宕機，會需要大部分的哨兵同意才可以，這個涉及到分布式的選舉。
哨兵機制需要保證最少 3 個節(jié)點才能保證其健壯性，如果我們在測試時只給出兩個節(jié)點，一個 master node 一個為 slave node 那么這兩個節(jié)點里面都有一個哨兵負責監(jiān)控，當其中的 master 主機發(fā)生宕機，那么需要哨兵來進行選舉，那么 master node 里面那個 s1 的哨兵已經(jīng)沒辦法工作，只能由 slave node 里面的 s2 哨兵進行選舉，那么進行選舉之后要進行故障轉(zhuǎn)移需要一個哨兵進行工作，其 majority 參數(shù)規(guī)定了需要哨兵的個數(shù)進行故障轉(zhuǎn)移，這時只有一個 S2 哨兵沒有 majority 可以進行故障轉(zhuǎn)移。所以最少需要 3 個節(jié)點來保證其健壯。
三、高可用與高并發(fā)出現(xiàn)的數(shù)據(jù)丟失問題
（1）異步復制導致的數(shù)據(jù)丟失
因為 master – slave 的復制是異步的，所以可能有部分數(shù)據(jù)還沒復制到 slave，master 就宕機了，此時這些部分數(shù)據(jù)就丟失了。
（2）腦裂導致的數(shù)據(jù)丟失
腦裂，也就是說，某個 master 所在機器突然脫離了正常的網(wǎng)絡，跟其他 slave 機器不能連接，但是實際上 master 還運行著，
此時哨兵可能就會認為 master 宕機了，然后開啟選舉，將其他 slave 切換成了 master，
這個時候，集群里就會有兩個 master，也就是所謂的腦裂，
此時雖然某個 slave 被切換成了 master，但是可能 client 還沒來得及切換到新的 master，還繼續(xù)寫向舊 master 的數(shù)據(jù)可能也丟失了，
因此舊 master 再次恢復的時候，會被作為一個 slave 掛到新的 master 上去，自己的數(shù)據(jù)會清空，重新從新的 master 復制數(shù)據(jù)。
解決異步復制和腦裂導致的數(shù)據(jù)丟失
min-slaves-to-write 1
min-slaves-max-lag 10要求至少有 1 個 slave，數(shù)據(jù)復制和同步的延遲不能超過 10 秒
如果說一旦所有的 slave，數(shù)據(jù)復制和同步的延遲都超過了 10 秒鐘，那么這個時候，master 就不會再接收任何請求了
上面兩個配置可以減少異步復制和腦裂導致的數(shù)據(jù)丟失
（1）減少異步復制的數(shù)據(jù)丟失
有了 min-slaves-max-lag 這個配置，就可以確保說，一旦 slave 復制數(shù)據(jù)和 ack 延時太長，就認為可能 master 宕機后損失的數(shù)據(jù)太多了，那么就拒絕寫請求，這樣可以把 master 宕機時由于部分數(shù)據(jù)未同步到 slave 導致的數(shù)據(jù)丟失降低的可控范圍內(nèi)
（2）減少腦裂的數(shù)據(jù)丟失
如果一個 master 出現(xiàn)了腦裂，跟其他 slave 丟了連接，那么上面兩個配置可以確保說，如果不能繼續(xù)給指定數(shù)量的 slave 發(fā)送數(shù)據(jù)，而且 slave 超過 10 秒沒有給自己 ack 消息，那么就直接拒絕客戶端的寫請求
這樣腦裂后的舊 master 就不會接受 client 的新數(shù)據(jù)，也就避免了數(shù)據(jù)丟失
上面的配置就確保了，如果跟任何一個 slave 丟了連接，在 10 秒后發(fā)現(xiàn)沒有 slave 給自己 ack，那么就拒絕新的寫請求
感謝你能夠認真閱讀完這篇文章，希望丸趣 TV 小編分享的“Redis 中高可用和高并發(fā)機制是什么意思”這篇文章對大家有幫助，同時也希望大家多多支持丸趣 TV，關注丸趣 TV 行業(yè)資訊頻道，更多相關知識等著你來學習!
向 AI 問一下細節(jié)
