1 redis單機（單節(jié)點）部署缺點

（1）數(shù)據(jù)丟失問題：redis是內(nèi)存存儲，服務重啟可能會丟失數(shù)據(jù)

（2）并發(fā)能力問題：redis單節(jié)點（單機）部署在并發(fā)量不大的話，也是可以滿足要求的，并發(fā)量最多幾萬，無法承受更高的并發(fā)。

（3）故障恢復問題：如果redis單節(jié)點故障中斷，那么會影響應用的使用。

（4）存儲能力問題：內(nèi)存存儲無法和磁盤存儲做比較，不能滿足海量數(shù)據(jù)的要求。

2 redis（是單線程的）集群（分布式緩存redis）

2.1 解決redis單機部署的缺點

（1）解決數(shù)據(jù)丟失問題：redis的持久化RDB和AOF

（2）解決并發(fā)能力問題：搭建redis主從集群，實現(xiàn)讀寫分離

（3）解決故障恢復問題：搭建redis哨兵，實現(xiàn)健康監(jiān)測和自動恢復

（4）存儲能力問題：搭建redis分片集群

2.2 redis的RDB和AOF持久化

1 RDB（redis database backup）

將內(nèi)存中的數(shù)據(jù)都記錄到磁盤中，重啟后，可讀RDB（快照）文件進行數(shù)據(jù)恢復。快照文件位置：默認保存在redis運行命令執(zhí)行的目錄下。

redis客戶端命令：

redis-cli

>save命令：

執(zhí)行一次RDB操作，主進程來執(zhí)行RDB，會阻塞進程。

>bgsave命令：

后臺啟動，（fork主進程得到子進程）子進程執(zhí)行RDB，避免主進程受影響。

特殊：如果redis是自己手動停止的，redis停機時會執(zhí)行一次RDB

2 RDB的fork原理

Bgsave開始時會fork主進程得到子進程，子進程共享主進程的內(nèi)存數(shù)據(jù)，完成fork后讀取內(nèi)存數(shù)據(jù)并寫入RDB文件。主進程執(zhí)行fork時，也是阻塞的，只能用來執(zhí)行fork。

fork就是復制頁表（linux的進程和物理內(nèi)存（內(nèi)存條）之間映射的虛擬內(nèi)存），Linux中進程不能直接操作物理內(nèi)存（內(nèi)存條） 需要在中間借助一個虛擬內(nèi)存來映射操作物理內(nèi)存。

fork操作的范圍：

不包括：子進程寫新的RDB文件（替換舊的RDB文件）的過程，fork操作只會復制頁表（就是進程和物理內(nèi)存的映射關(guān)系表） 生成1個子進程。

思考：

• 如果在fork完一個子進程后，子進程生成RDB文件過程中，有請求來修改（寫）操作，那么會操作哪一部分？
• 當主進程執(zhí)行讀操作時，訪問共享內(nèi)存。
• 當主進程執(zhí)行寫操作時，則會拷貝一份數(shù)據(jù)，執(zhí)行寫操作，（只能寫這個拷貝的副本數(shù)據(jù)）。后續(xù)的讀請求就會訪問這個副本數(shù)據(jù)。

RDB的缺點

RDB執(zhí)行時間（間隔）長，2次RDB之間寫入數(shù)據(jù)有丟失風險。 如果執(zhí)行間隔短的話（2-3秒一次），那么太耗性能。

AOF持久化

append only file 追加文件

1 介紹

為了彌補RDB的缺點，redis處理的每一個寫命令都會記錄在AOF文件中（RDB是每次都重新讀全部內(nèi)存數(shù)據(jù)），可以看過是命令日志文件。

2 AOF文件體積大的處理方法（將AOF文件中的命令進行重寫，相當于將重復命令合成一個（多個set同一個key 可合為1個最后的key操作命令））

（1）手動

redis-cli連接redis客戶端，執(zhí)行bgrewirterof命令，用最少的命令達到相同的效果。

（2）自動（在配置文件中添加）

redis也會在觸發(fā)閾值時自動重寫AOF文件，可在redis.conf文件中配置

RDB和AOF持久化的比較

對數(shù)據(jù)安全性比較高并且數(shù)據(jù)完整的話：推薦AOF持久化

宕機回復速度要求高的話：推薦RDB持久化

2.3 redis主從集群，實現(xiàn)讀寫分離（解決并發(fā)能力問題）

由于redis大多都是讀多寫少，所以不做成傳統(tǒng)的集群。單節(jié)點的redis的并發(fā)能力是有上限的，要進一步提高redis的并發(fā)能力，需要搭建主從集群，實現(xiàn)讀寫分離。至少需要3個節(jié)點，一主兩從，讀操作找從節(jié)點進行讀取，寫操作找主節(jié)點進行寫操作。

另外，主節(jié)點master會向兩臺slave/replica從節(jié)點中同步數(shù)據(jù)。可以解決高并發(fā)讀（因為有多個slave節(jié)點）和高可用性（主從集群的哨兵模式）的問題，但是redis主從集群解決不了高并發(fā)寫（因為只有一個master）和存儲海量數(shù)據(jù)（整體的存儲數(shù)據(jù)量取決于一個redis節(jié)點的master的容量，每個節(jié)點數(shù)據(jù)保持和master節(jié)點數(shù)據(jù)一致）的問題。

搭建主從集群

1 在3臺機器上分別安裝3個redis

編輯每個redis的redis.conf文件

# redis實例的聲明ip
redis-announce-ip 所在主機的ip

2 配置主從關(guān)系

前提：3個redis實例還沒有關(guān)系

（1）臨時模式（使用命令配置主從，但重啟redis后失效）

redis5.0之前可使用slaveof命令，redis5.0之后新增replicaof命令（和slaveof命令效果一致）

使用redis-cli 客戶端連接到redis服務，執(zhí)行slaveof命令

slaveof 主節(jié)點的ip  主節(jié)點的端口號

效果：在哪臺redis客戶端命令/配置文件中 添加上slaveof，那么這臺redis就會成為指定的主節(jié)點的從節(jié)點。

（2）永久模式–修改配置文件

在redis.conf文件中添加一行配置：

slaveof 主節(jié)點的ip  主節(jié)點的端口號

在某一臺redis中查看節(jié)點信息：

info replication

主從數(shù)據(jù)同步原理

建立連接時的第一次同步 是全量同步

（1）2個重要概念

• Replication id：簡稱replid，是數(shù)據(jù)集的標記，id一致則說明是同一數(shù)據(jù)集。每一個master都有唯一的replid，slave會繼承master節(jié)點的replid。
• offset：偏移量，隨著記錄在repl_baklog中的數(shù)據(jù)增多而逐漸增大。

master節(jié)點判斷某個從節(jié)點是否第一次同步：

每個redis節(jié)點都有自己replication id，每個redis從節(jié)點都有自己的replication id和相對于主節(jié)點的偏移量offset。

連接redis

bin/redis-cli
# 在bin目錄下 連接
redis-cli

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論