一、Redis 事務(wù)

1.1 事務(wù)本質(zhì)

一組命令的集合

1.2 數(shù)據(jù)庫事務(wù)與redis事務(wù)

1.2.1 數(shù)據(jù)庫事務(wù)

數(shù)據(jù)庫事務(wù)通過ACID（原子性、一致性、隔離性、持久性）來保證。

數(shù)據(jù)庫中除查詢操作以外，插入(Insert)、刪除(Delete)和更新(Update)這三種操作都會對數(shù)據(jù)造成影響，因為事務(wù)處理能夠保證一系列操作可以完全地執(zhí)行或者完全不執(zhí)行，因此在一個事務(wù)被提交以后，該事務(wù)中的任何一條SQL語句在被執(zhí)行的時候，都會生成一條撤銷日志(Undo Log)。

1.2.2 Redis事務(wù)

redis事務(wù)提供了一種“將多個命令打包， 然后一次性、按順序地執(zhí)行”的機制， 并且事務(wù)在執(zhí)行的期間不會主動中斷 —— 服務(wù)器在執(zhí)行完事務(wù)中的所有命令之后， 才會繼續(xù)處理其他客戶端的其他命令。

Redis中一個事務(wù)從開始到執(zhí)行會經(jīng)歷開始事務(wù)（muiti）、命令入隊和執(zhí)行事務(wù)(exec)三個階段，事務(wù)中的命令在加入時都沒有被執(zhí)行，直到提交時才會開始執(zhí)行(Exec)一次性完成。

1.2.2.1 兩種錯誤不同處理方式

1）代碼語法錯誤（編譯時異常）

發(fā)生代碼語法錯誤時，所有命令都不執(zhí)行。

2）代碼邏輯錯誤（運行時錯誤）

發(fā)生代碼邏輯錯誤時，其他命令可以正常執(zhí)行 （該點不保證事務(wù)的原子性）

為什么redis不支持回滾來保證原子性

1.2.2.2 這種做法的優(yōu)點：

• Redis 命令只會因為錯誤的語法而失?。ú⑶疫@些問題不能在入隊時發(fā)現(xiàn)），或是命令用在了錯誤類型的鍵上面：這也就是說，從實用性的角度來說，失敗的命令是由編程錯誤造成的，而這些錯誤應(yīng)該在開發(fā)的過程中被發(fā)現(xiàn)，而不應(yīng)該出現(xiàn)在生產(chǎn)環(huán)境中。
• 因為不需要對回滾進行支持，所以 Redis 的內(nèi)部可以保持簡單且快速。

鑒于沒有任何機制能避免程序員自己造成的錯誤， 并且這類錯誤通常不會在生產(chǎn)環(huán)境中出現(xiàn)， 所以 Redis 選擇了更簡單、更快速的無回滾方式來處理事務(wù)。

1.3 事務(wù)監(jiān)控

redis使用watch key監(jiān)控指定數(shù)據(jù)，相當(dāng)于加樂觀鎖

watch保證事務(wù)只能在所有被監(jiān)視鍵都沒有被修改的前提下執(zhí)行， 如果這個前提不能滿足的話，事務(wù)就不會被執(zhí)行。

watch執(zhí)行流程:

二、數(shù)據(jù)持久化

Redis是一種內(nèi)存型數(shù)據(jù)庫，一旦服務(wù)器進程退出，數(shù)據(jù)庫的數(shù)據(jù)就會丟失，為了解決這個問題Redis供了兩種持久化的方案，將內(nèi)存中的數(shù)據(jù)保存到磁盤中，避免數(shù)據(jù)的丟失兩種持久化方式：快照（RDB文件）和追加式文件（AOF文件），下面分別為大家介紹兩種方式的原理。

• RDB持久化方式會在一個特定的間隔保存那個時間點的數(shù)據(jù)快照。
• AOF持久化方式則會記錄每一個服務(wù)器收到的寫操作。在服務(wù)啟動時，這些記錄的操作會逐條執(zhí)行從而重建出原來的數(shù)據(jù)。寫操作命令記錄的格式跟Redis協(xié)議一致，以追加的方式進行保存。
• Redis的持久化是可以禁用的，就是說你可以讓數(shù)據(jù)的生命周期只存在于服務(wù)器的運行時間里。
• 兩種方式的持久化是可以同時存在的，但是當(dāng)Redis重啟時，AOF文件會被優(yōu)先用于重建數(shù)據(jù)。

2.1 RDB持久化

RDB持久化產(chǎn)生的文件是一個經(jīng)過壓縮的二進制文件，這個文件可以被保存到硬盤中，可以通過這個文件還原數(shù)據(jù)庫的狀態(tài)，它可以手動執(zhí)行，也可以在redis.conf配置文件中配置，定時執(zhí)行。

2.1.1 工作原理

在進行RDB時，redis的主進程不會做io操作，會fork一個子進程來完成該操作：

1）Redis 調(diào)用forks。同時擁有父進程和子進程。

2）子進程將數(shù)據(jù)集寫入到一個臨時 RDB 文件中。

3）當(dāng)子進程完成對新 RDB 文件的寫入時，Redis 用新 RDB 文件替換原來的 RDB 文件，并刪除舊的 RDB 文件。

這種工作方式使得 Redis 可以從寫時復(fù)制（copy-on-write）機制中獲益(因為是使用子進程進行寫操作，而父進程依然可以接收來自客戶端的請求)

2.1.2 觸發(fā)機制

在Redis中RDB持久化的觸發(fā)分為兩種：自己手動觸發(fā)與自動觸發(fā)。

2.1.2.1 手動觸發(fā)

1）save

save命令是同步的命令，會占用主進程，會造成阻塞，阻塞所有客戶端的請求

2）bgsave

bgsave是異步進行，進行持久化的時候，redis還可以將繼續(xù)響應(yīng)客戶端請求

bgsave和save對比：

2.1.2.2 自動觸發(fā)

觸發(fā)條件：

save自動觸發(fā)配置，見下面配置，滿足m秒內(nèi)修改n次key，觸發(fā)rdb

# 時間策略   save m n m秒內(nèi)修改n次key，觸發(fā)rdb
save 900 1
save 300 10
save 60 10000

# 文件名稱
dbfilename dump.rdb

# 文件保存路徑
dir /home/work/app/redis/data/

# 如果持久化出錯，主進程是否停止寫入
stop-writes-on-bgsave-error yes

# 是否壓縮
rdbcompression yes

# 導(dǎo)入時是否檢查
rdbchecksum yes

1）從節(jié)點全量復(fù)制時，主節(jié)點發(fā)送rdb文件給從節(jié)點完成復(fù)制操作，主節(jié)點會觸發(fā)bgsave命令；

2）執(zhí)行flushall命令，會觸發(fā)rdb

3）退出redis，且沒有開啟aof時

2.1.3 RDB優(yōu)缺點

2.1.3.1 優(yōu)點：

1）RDB 的內(nèi)容為二進制的數(shù)據(jù)，占用內(nèi)存更小，更緊湊，更適合做為備份文件；

2）RDB 對災(zāi)難恢復(fù)非常有用，它是一個緊湊的文件，可以更快的傳輸?shù)竭h程服務(wù)器進行 Redis 服務(wù)恢復(fù)；

3）RDB 可以更大程度的提高 Redis 的運行速度，因為每次持久化時 Redis 主進程都會 fork() 一個子進程，進行數(shù)據(jù)持久化到磁盤，Redis 主進程并不會執(zhí)行磁盤 I/O 等操作；

4）與 AOF 格式的文件相比，RDB 文件可以更快的重啟。

2.1.3.2 缺點：

1）因為 RDB 只能保存某個時間間隔的數(shù)據(jù)，如果中途 Redis 服務(wù)被意外終止了，則會丟失一段時間內(nèi)的 Redis 數(shù)據(jù)。

2）RDB 需要經(jīng)常 fork() 才能使用子進程將其持久化在磁盤上。如果數(shù)據(jù)集很大，fork() 可能很耗時，并且如果數(shù)據(jù)集很大且 CPU 性能不佳，則可能導(dǎo)致 Redis 停止為客戶端服務(wù)幾毫秒甚至一秒鐘。

2.2 AOF持久化

以日志的形式來記錄每個寫的操作，將Redis執(zhí)行過的所有指令記錄下來（讀操作不記錄），只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構(gòu)建數(shù)據(jù)，換言之，redis重啟的話就根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作。

2.2.1 AOF配置項

# 默認(rèn)不開啟aof  而是使用rdb的方式
appendonly no

# 默認(rèn)文件名
appendfilename "appendonly.aof"

# 每次修改都會sync 消耗性能
# appendfsync always
# 每秒執(zhí)行一次 sync 可能會丟失這一秒的數(shù)據(jù)
appendfsync everysec
# 不執(zhí)行 sync ,這時候操作系統(tǒng)自己同步數(shù)據(jù)，速度最快
# appendfsync no 

AOF的整個流程大體來看可以分為兩步，一步是命令的實時寫入（如果是appendfsync everysec 配置，會有1s損耗），第二步是對aof文件的重寫。

2.2.2 AOF 重寫機制

隨著Redis的運行，AOF的日志會越來越長，如果實例宕機重啟，那么重放整個AOF將會變得十分耗時，而在日志記錄中，又有很多無意義的記錄，比如我現(xiàn)在將一個數(shù)據(jù) incr一千次，那么就不需要去記錄這1000次修改，只需要記錄最后的值即可。所以就需要進行 AOF 重寫。

Redis 提供了bgrewriteaof指令用于對AOF日志進行重寫，該指令運行時會開辟一個子進程對內(nèi)存進行遍歷，然后將其轉(zhuǎn)換為一系列的 Redis 的操作指令，再序列化到一個日志文件中。完成后再替換原有的AOF文件，至此完成。

同樣的也可以在redis.config中對重寫機制的觸發(fā)進行配置：

通過將no-appendfsync-on-rewrite設(shè)置為yes，開啟重寫機制；auto-aof-rewrite-percentage 100意為比上次從寫后文件大小增長了100%再次觸發(fā)重寫；

auto-aof-rewrite-min-size 64mb意為當(dāng)文件至少要達到64mb才會觸發(fā)制動重寫。

2.2.3 觸發(fā)方式

在Redis中AOF持久化的觸發(fā)也分為兩種：自己手動觸發(fā)與自動觸發(fā)。

2.2.3.1 手動觸發(fā)

bgrewriteaof

2.2.3.2 自動觸發(fā)

就是根據(jù)配置規(guī)則來觸發(fā)，當(dāng)然自動觸發(fā)的整體時間還跟Redis的定時任務(wù)頻率有關(guān)系。

2.2.4 AOF的優(yōu)缺點

2.2.4.1 優(yōu)點

1）數(shù)據(jù)安全

aof 持久化可以配置 appendfsync 屬性，有 always，每進行一次 命令操作就記錄到 aof 文件中一次。

2）解決數(shù)據(jù)一致性問題。

通過 append 模式寫文件，即使中途服務(wù)器宕機，可以通過 redis-check-aof 工具解決數(shù)據(jù)一致性問題。

3）AOF 機制的 rewrite 模式。

AOF 文件沒被 rewrite 之前（文件過大時會對命令 進行合并重寫），可以刪除其中的某些命令（比如誤操作的 flushall）)

2.2.4.2 缺點

1）AOF 文件比 RDB 文件大，且恢復(fù)速度慢。

2）數(shù)據(jù)集大的時候，比 rdb 啟動效率低。

2.3 rdb與aof對比

總結(jié)

RDB基于快照方式在一個特定的間隔保存那個時間點的數(shù)據(jù)，備份數(shù)據(jù)相對較小，恢復(fù)速度較塊，但是可能會發(fā)生數(shù)據(jù)丟失；AOF持久化方式則會記錄每一個服務(wù)器收到的寫操作，備份文件體積較大，恢復(fù)速度較慢，但是這種方式制定一定的策略，不會丟失數(shù)據(jù)，相對來說數(shù)據(jù)安全性要比RDB高。

在真實的企業(yè)生產(chǎn)環(huán)境中，Redis數(shù)據(jù)備份策略，一般是同時開啟RDB和AOF兩種備份方式，盡可能提高企業(yè)安全性的同時，也可以針對某個時間點基于數(shù)據(jù)快照快速恢復(fù)數(shù)據(jù)。

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

最新評論