概述
Redis高可用高性能緩存的應(yīng)用系列的第二篇,主要介紹Redis事務(wù)機制和IO多路復用、和持久化的知識點。
(相關(guān)資料圖)
Redis事務(wù)機制
Redis事務(wù)機制,和Mysql有大的不同,分為4步進行執(zhí)行:
1.事務(wù)提交前,先檢查命令語法是否正確2.提交命令后,一定會被執(zhí)行3.有命令報錯也會執(zhí)行完4.不能回滾Redis事務(wù)和批量操作的區(qū)別:Redis在執(zhí)行exec時,命令要么執(zhí)行,要么都不執(zhí)行,批量操作不會檢查語法。
Redis事務(wù)命令說明:
multi:告訴Redis開啟一個事務(wù)(注意只是開啟,而不是執(zhí)行)exec: 告訴Redis開始執(zhí)行事務(wù)discard:告訴Redis取消事務(wù)watch:監(jiān)視某一個鍵值對,它的作用是在事務(wù)執(zhí)行之前,如果監(jiān)視的鍵值被修改,事務(wù)會被取消當執(zhí)行multi命令后,表明Redis開啟一個事務(wù),在執(zhí)行后續(xù)的命令都屬于在排隊中,執(zhí)行exec命令時,Redis事務(wù)的命令要么全部執(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的事務(wù)會被服務(wù)駁回,全部不執(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ù)據(jù)有錯誤拋出,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采用單線程處理請求, 假設(shè)服務(wù)器是4核的CPU,只會占用一個,其他3個都不進行參與,在線程處理上是并行的。
Redis 6.0版本后對這里進行了優(yōu)化,使用了I/O thread概念,Redis 6.0的主進程只做計算,不在參與讀寫操作,I/O thread 處理上都是并行的關(guān)系,充分利用了多核CPU的優(yōu)勢,節(jié)省了處理時間,提升了處理請求的性能。
持久化
Redis的數(shù)據(jù)是保存在內(nèi)存中的,所以當服務(wù)器重啟時會造成數(shù)據(jù)丟失,Redis提供了數(shù)據(jù)持久化方案,把數(shù)據(jù)保存到磁盤上,使用文件恢復數(shù)據(jù),主要有3種持久化方式:
rdb : 生成某一時刻的快照,然后保存在二進制文件中aof :記錄每一條命令,追加到文件中,打開可以看到具體的操作記錄混合模式:它是上面兩種方式的結(jié)合手動觸發(fā)save ,會讓Redis處于阻塞狀態(tài),直到rdb持久化完成,線上環(huán)境要謹慎使用bgsave ,它會fork出一個子進程,用來執(zhí)行持久化,主進程繼續(xù)響應(yīng)客戶端請求,它會有短暫的阻塞2.自動觸發(fā)
在m秒內(nèi),執(zhí)行命令最終執(zhí)行的是bgsavebgsave的執(zhí)行過程:1)首先,redis主進程fork出子進程,2)子進程會共享子進程的數(shù)據(jù),并把主進程設(shè)置成read only,然后開始執(zhí)行持久化的操作,當有新命令要修改數(shù)據(jù)時,Redis采用寫實復制的方法來解決數(shù)據(jù)不一致的問題。
rdb持久化的優(yōu)缺點:
優(yōu)點:
容災(zāi)性好,方便備份性能最大化,fork出一個子進程來操作,對主進程沒有影響數(shù)據(jù)比較多時,相對于aof啟動效率比較高缺點:
假如中間發(fā)生故障,故障期間會造成數(shù)據(jù)丟失Aof同步策略
appendfsync everysec 每秒同步一次,默認是每秒同步一次appendfsync always 每次操作后要同步一次appendfsync no 由操作系統(tǒng)進行調(diào)度Aof的重寫策略:因為在Redis操作的過程中有很多命令都是對同一個key進行操作,會造成大量的命令重復,造成Aof文件過大,而整理出的解決方案。
手動觸發(fā),執(zhí)行bgrewriteaof命令自動觸發(fā)auto-aof-rewrit-precentage
:當前Aof文件大小和最后一次重寫后的大小之間的比率等于或者是等于指定的增長百分比,如100是代表當前Aof文件是上次重寫的兩倍時候才重寫的。
auto-aof-rewrit-mini-size
:當Aof文件大小大于該值時候才可能重寫。
優(yōu)點:數(shù)據(jù)安全,不會造成數(shù)據(jù)的丟失
缺點:比rdb重啟效率低,運行效率比rdb低