概述

Redis高可用高性能緩存的應用系列的第二篇，主要介紹Redis事務機制和IO多路復用、和持久化的知識點。

(相關資料圖)

Redis事務機制

Redis事務機制，和Mysql有大的不同，分為4步進行執(zhí)行：

1.事務提交前，先檢查命令語法是否正確2.提交命令后，一定會被執(zhí)行3.有命令報錯也會執(zhí)行完4.不能回滾

Redis事務和批量操作的區(qū)別：Redis在執(zhí)行exec時，命令要么執(zhí)行，要么都不執(zhí)行，批量操作不會檢查語法。

Redis事務命令說明：

multi：告訴Redis開啟一個事務(注意只是開啟，而不是執(zhí)行)exec: 告訴Redis開始執(zhí)行事務discard：告訴Redis取消事務watch:監(jiān)視某一個鍵值對，它的作用是在事務執(zhí)行之前，如果監(jiān)視的鍵值被修改，事務會被取消

當執(zhí)行multi命令后，表明Redis開啟一個事務，在執(zhí)行后續(xù)的命令都屬于在排隊中，執(zhí)行exec命令時，Redis事務的命令要么全部執(zhí)行，要么全不執(zhí)行。

redis-cli> set name "stark"OKredis-cli> multiOKredis-cli> set name "stark張宇"QUEUEDredis-cli> set age 33QUEUEDredis-cli> exec1) OK2) OK

復制

如果因為執(zhí)行的命令語法錯誤，整個Redis的事務會被服務駁回，全部不執(zhí)行。

redis-cli> multiOKredis-cli> set name "stark張宇"QUEUEDredis-cli> lpop "changchang" "quanquan" "xiaoshenyang"QUEUEDredis-cli> exec(error) wrong number of arguments (given 3, expected 1)

復制

如果語法沒有錯誤，在執(zhí)行過程中數(shù)據有錯誤拋出，Redis也會全部執(zhí)行，只要語法正確，命令都會被執(zhí)行。

redis-cli> multiOKredis-cli> set name "stark張宇"QUEUEDredis-cli> lpop nameQUEUEDredis-cli> exec1) OK2) WRONGTYPE Operation against a key holding the wrong kind of value

復制

I/O多路復用

首先要說明一點，redis采用單線程處理請求， 假設服務器是4核的CPU，只會占用一個，其他3個都不進行參與，在線程處理上是并行的。

Redis 6.0版本后對這里進行了優(yōu)化，使用了I/O thread概念，Redis 6.0的主進程只做計算，不在參與讀寫操作，I/O thread 處理上都是并行的關系，充分利用了多核CPU的優(yōu)勢，節(jié)省了處理時間，提升了處理請求的性能。

持久化

Redis的數(shù)據是保存在內存中的，所以當服務器重啟時會造成數(shù)據丟失，Redis提供了數(shù)據持久化方案，把數(shù)據保存到磁盤上，使用文件恢復數(shù)據，主要有3種持久化方式：

rdb : 生成某一時刻的快照，然后保存在二進制文件中aof ：記錄每一條命令，追加到文件中，打開可以看到具體的操作記錄混合模式：它是上面兩種方式的結合手動觸發(fā)save ，會讓Redis處于阻塞狀態(tài)，直到rdb持久化完成，線上環(huán)境要謹慎使用bgsave ，它會fork出一個子進程，用來執(zhí)行持久化，主進程繼續(xù)響應客戶端請求，它會有短暫的阻塞

2.自動觸發(fā)

在m秒內，執(zhí)行命令最終執(zhí)行的是bgsave

bgsave的執(zhí)行過程:1)首先，redis主進程fork出子進程，2)子進程會共享子進程的數(shù)據，并把主進程設置成read only,然后開始執(zhí)行持久化的操作，當有新命令要修改數(shù)據時，Redis采用寫實復制的方法來解決數(shù)據不一致的問題。

rdb持久化的優(yōu)缺點：

優(yōu)點：

容災性好，方便備份性能最大化，fork出一個子進程來操作，對主進程沒有影響數(shù)據比較多時，相對于aof啟動效率比較高

缺點：

假如中間發(fā)生故障，故障期間會造成數(shù)據丟失

Aof同步策略

appendfsync everysec 每秒同步一次，默認是每秒同步一次appendfsync always 每次操作后要同步一次appendfsync no 由操作系統(tǒng)進行調度

Aof的重寫策略：因為在Redis操作的過程中有很多命令都是對同一個key進行操作，會造成大量的命令重復，造成Aof文件過大，而整理出的解決方案。

手動觸發(fā)，執(zhí)行bgrewriteaof命令自動觸發(fā)

auto-aof-rewrit-precentage:當前Aof文件大小和最后一次重寫后的大小之間的比率等于或者是等于指定的增長百分比，如100是代表當前Aof文件是上次重寫的兩倍時候才重寫的。

auto-aof-rewrit-mini-size:當Aof文件大小大于該值時候才可能重寫。

優(yōu)點：數(shù)據安全，不會造成數(shù)據的丟失

缺點：比rdb重啟效率低，運行效率比rdb低