Redis入門(7) - 持久化、主從複製、安全

持久化 RDB方式 Redis實現快照的過程 AOF方式操作系統緩存 RDB與AOF 複製主從資料庫主從複製的意義安全持久化 Redis通過將數據存儲在記憶體中而獲得了極快的速度，但為了保證Redis在重啟後數據不丟失，需要將數據從記憶體持久化到硬碟中。持久化的方式有兩種，二者可以只用一種， ...

持久化
- RDB方式
  - Redis實現快照的過程
- AOF方式
  - 操作系統緩存
  - RDB與AOF
複製
- 主從資料庫
- 主從複製的意義
安全

持久化

Redis通過將數據存儲在記憶體中而獲得了極快的速度，但為了保證Redis在重啟後數據不丟失，需要將數據從記憶體持久化到硬碟中。

持久化的方式有兩種，二者可以只用一種，也可以組合使用：

RDB方式
AOF方式

RDB方式

RDB是Redis預設採用的持久化方式，當符合一定條件時Redis會自動將記憶體中的所有數據進行快照（snapshotting）並存儲在硬碟上。進行快照的條件可以由用戶在配置文件中自定義，配置由兩個參數構成：時間和改動的鍵的個數。當在指定的時間內被更改的鍵的個數大於指定的數值時就會進行快照。在配置文件redis.conf中已經預置了3個條件：

save 900 1
save 300 10
save 60 10000

這些條件直接是“或”的關係。如果需要禁用自動快照，可以將所有的save配置刪除。

除了自動快照，還可以手動發送SAVE或BGSAVE命令讓Redis執行快照，SAVE命令是由主進程進行快照操作，會阻塞住其他請求，而BGSAVE命令則會通過fork子進程進行快照操作。

Redis預設會將快照文件存儲在當前目錄的dump.rdb文件中，可以通過配置dir和dbfilename兩個參數分別指定快照文件的存儲路徑和文件名。

Redis實現快照的過程

RDB快照的過程為：

Redis使用fork函數複製一份當前進程（父進程）的副本（子進程）；
父進程繼續接收並處理客戶端發來的命令，子進程則開始將記憶體中的數據寫入硬碟中的臨時文件；
當子進程寫入完所有數據後，會用該臨時文件替換舊的RDB文件，至此一次快照操作完成。
Redis重新啟動時會讀取RDB快照文件，將數據從硬碟載入到記憶體。（根據數據量大小與結構和伺服器性能不同，這個時間也不同。通常將一個記錄一千萬個字元串類型鍵、大小為1GB的快照文件載入到記憶體中需要花費20～30秒鐘）。

Redis在進行快照的過程中不會修改RDB文件，只有快照結束後才會將舊的文件替換成新的，也就是說任何時候RDB文件都是完整的，所以可以通過定時備份RDB文件來實現Redis資料庫備份。RDB文件是經過壓縮的二進位格式，占用的空間會小於記憶體中的數據大小。但壓縮過程也會增加CPU占用，如有需要可以通過修改配置rdbcompression參數以禁用壓縮。

config set rdbcompression no

AOF方式

AOF全稱為append only file，在這種持久化方式下，每執行一條會更改Redis中的數據的命令，Redis都會將該命令寫入硬碟中的AOF文件。
AOF文件的保存位置和RDB文件的位置相同，都可以通過dir參數設置，預設的文件名是appendonly.aof，可以通過appendfilename參數修改。
AOF文件是純文本文件，其內容是Redis客戶端向Redis發送的原始通信協議的內容。設想執行這樣幾條命令：

SET key1 1
SET key1 2
SET key1 3

AOF文件中會記錄這三次操作，但實際上前兩條實際上是多餘的，只需要記錄最終一次的命令即可。隨著執行的命令越來越多，AOF文件也會越來越大，而Redis可以通過去除這類多餘命令記錄，自動對AOF文件進行優化。

每當達到一定條件時Redis就會自動重寫AOF文件，這個條件可以在配置文件中設置：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-percentage設置當目前的AOF文件大小超過上一次重寫時的AOF文件大小的百分之多少時會再次進行重寫，如果之前沒有重寫過，則以啟動時的AOF文件大小為依據。
auto-aof-rewrite-min-size則限制了允許重寫的最小AOF文件大小，通常在AOF文件很小的情況下即使其中有很多冗餘的命令也不需要重寫。

除了讓Redis自動執行重寫外，還可以主動使用BGREWRITEAOF命令手動執行AOF重寫。

在重啟時Redis會逐個執行AOF文件中的命令來將硬碟中的數據載入到記憶體中，載入的速度相較RDB會慢一些。

操作系統緩存

雖然每次執行更改資料庫內容的操作時，AOF都會將命令記錄在AOF文件中，但實際上由於操作系統的緩存機制的存在，數據並沒有真正地寫入硬碟，而是進入了系統的硬碟緩存。在預設情況下系統每30秒會執行一次同步操作，以便將硬碟緩存中的內容真正地寫入硬碟，在這30秒的過程中如果系統異常退出則會導致硬碟緩存中的數據丟失。一般來講啟用AOF持久化的應用都無法容忍這樣的損失，這就需要Redis在寫入AOF文件後主動要求系統將緩存內容同步到硬碟中。
可以通過appendfsync參數設置同步的時機：

config set appendfsync always/eversec/no

always 每次執行寫入都會執行同步，這種模式最安全但也最慢
everysec 每秒同步一次
no 不主動進行同步操作，操作系統沒30秒同步一次

RDB與AOF

如果選擇RDB的持久化方式，一旦Redis異常退出，就會丟失最後一次快照以後更改的所有數據。這就需要開發者根據具體的應用場合，通過組合設置自動快照條件的方式來將可能發生的數據損失控制在能夠接受的範圍。如果數據很重要以至於無法承受任何損失，則可以考慮使用AOF方式進行持久化。
可以同時開啟AOF和RDB，這樣既保證了數據安全，又使得進行備份等操作十分容易。此時重新啟動Redis後Redis會使用AOF文件來恢複數據，因為AOF方式的持久化可能丟失的數據更少。

複製

Redis的持久化功能可以保證在伺服器重啟的情況下不會損失（或少量損失）數據。但是由於數據只存儲在一臺伺服器，如果這台伺服器的硬碟出現故障，也會導致數據丟失。為了避免單點故障，將資料庫複製多個副本以部署在不同的伺服器上，組成集群，這樣即使有一臺伺服器出現故障時，其他伺服器依然可以繼續提供服務，此外也提升了整體的性能。
Redis提供了複製（replication）功能用以保障構成集群的多台伺服器之間數據的同步。

主從資料庫

構成集群的資料庫分為兩類，主資料庫（master）和從資料庫（slave）。主資料庫可以進行讀寫操作，當發生寫操作時自動將數據同步給從資料庫。而從資料庫一般是只讀的，並接受主資料庫同步過來的數據。主從資料庫是一對多的關係。

要把一個資料庫作為從資料庫，需要在啟動參數或者配置文件中加入：

slaveof 主資料庫的IP 埠

接下來使用redis的docker鏡像試驗主從複製，首先啟動兩個實例：

docker run --name redis-6379 -p 6379:6379 -d redis
docker run --name redis-6380 -p 6380:6379 -d redis

redis-6379將被作為主資料庫，redis-6380為從庫，首先獲取redis-6379容器的內網IP地址：

docker inspect redis-6379

在"NetworkSettings"結點下可以看到IP和埠為172.17.0.2 6379

進入redis-6380，設置其為從資料庫：

> docker exec -it redis-6380 /bin/bash
root@cd19cbbab6d9:/data# redis-cli
127.0.0.1:6379> SLAVEOF 172.17.0.2 6379

這樣主從資料庫就設置好了，可以測試下在主資料庫插入一個鍵，然後在從資料庫讀取。

從資料庫預設是只讀的，嘗試寫入將提示：

SET KEY1 1
(error) READONLY You can't write against a read only replica.

可以通過設置從資料庫的配置文件中的slave-read-only為no以使從資料庫可寫，但是對從資料庫的任何更改都不會同步給其他資料庫，並且一旦主資料庫中更新了對應的數據就會覆蓋從資料庫中的改動。

在redis實例運行也可以使用SLAVEOF命令，如果該資料庫已經是其他主資料庫的從資料庫，則SLAVEOF命令會停止和原來資料庫的同步轉而和新資料庫同步。還可以使用SLAVEOF NO ONE來使當前資料庫停止接收其他資料庫的同步轉成主資料庫。

主從複製的意義

數據冗餘:主從複製實現了數據的熱備份，是持久化之外的一種數據冗餘方式。
故障恢復:當主節點出現問題時，可以由從節點提供服務，實現快速的故障恢復;實際上是一種服務的冗餘。
讀寫分離:可以用於實現讀寫分離，主庫寫、從庫讀，讀寫分離不僅可以提高伺服器的負載能力，同時可根據需求的變化，改變從庫的數量;
負載均衡:在主從複製的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務分擔伺服器負載;尤其是在寫少讀多的場景下，通過多個從節點分擔讀負載，可以大大提高Redis伺服器的併發量。
高可用基石:除了上述作用以外，主從複製還是哨兵和集群能夠實施的基礎，因此說主從複製是Redis高可用的基礎。

安全

在安全方面，Redis提供了下麵幾種策略。

可信的環境

Redis安全設計都是建立在“Redis運行在可信環境”這個前提下的，在生產環境運行時不能允許外界直接連接到Redis伺服器上，而應該通過應用程式進行中轉，運行在可信的環境中是保證Redis安全的最重要方法。

Redis的預設會接受來自任何地址發送來的請求，要更改這一設置，可以在配置文件中修改bind參數，如只允許本機應用連接Redis，可以將bind參數改成：

bind 127.0.0.1

密碼

要設置密碼，可以修改配置文件中的requirepass參數，例如：

requirepass 123456

docker鏡像也可以在啟動容器的時候設置密碼：

docker run --name redis-test -p 6379:6379 redis --requirepass 123456

添加密碼後，客戶端在連接時需要輸入密碼:

redis-cli -h 127.0.0.1 -p 6379 -a 123456

設置密碼後，如果要搭建主從資料庫，需要在從資料庫配置文件中的masterauth添加主資料庫的密碼。

需要註意的是，由於Redis的性能極高，並且輸入錯誤密碼後Redis並不會進行主動延遲，所以攻擊者可以通過窮舉法破解Redis的密碼（1秒內能夠嘗試十幾萬個密碼），因此在設置時一定要選擇複雜的密碼。

命令重命名

Redis支持在配置文件中將命令重命名，比如將FLUSHALL命令重命名成一個比較複雜的名字，以保證只有自己的應用可以使用該命令：

rename-command FLUSHALL oiuyhjkghjgyutdfhbuhbnjinjbgyvtcrd

如果希望直接禁用某個命令，可以將命令重命名成空字元串。