一文詳解Redis中的持久化
1. 前言
為什么要進(jìn)行持久化?:持久化功能有效地避免因進(jìn)程退出造成的數(shù)據(jù)丟失問題,當(dāng)下次重啟時(shí)利用之前持久化的文件即可實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。
持久化都有那些方式?:Redis支持RDB和AOF兩種持久化機(jī)制。
2. RDB
RDB持久化是把當(dāng)前進(jìn)程數(shù)據(jù)生成快照保存到硬盤的過程,觸發(fā)RDB持久化過程分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)。
2.1 手動(dòng)觸發(fā)
手動(dòng)觸發(fā)分別對(duì)應(yīng)save
和bgsave
命令:
save
命令::阻塞當(dāng)前Redis服務(wù)器,直到RDB過程完成為止,對(duì)于內(nèi)存比較大的實(shí)例會(huì)造成長(zhǎng)時(shí)間阻塞,線上環(huán)境不建議使用。bgsave
命令:Redis進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程,RDB持久化過程由子進(jìn)程負(fù)責(zé),完成后自動(dòng)結(jié)束。阻塞只發(fā)生在fork階段,一般時(shí)間很短。
顯然bgsave命令是針對(duì)save阻塞問題做的優(yōu)化。因此Redis內(nèi)部所有的涉及RDB的操作都采用bgsave的方式,而save命令已經(jīng)廢棄。
2.2 自動(dòng)觸發(fā)
- 使用save相關(guān)配置,如
save m n
。表示m秒內(nèi)數(shù)據(jù)集存在n次修改時(shí),自動(dòng)觸發(fā)bgsave。 - 如果從節(jié)點(diǎn)執(zhí)行全量復(fù)制操作,主節(jié)點(diǎn)自動(dòng)執(zhí)行bgsave生成RDB文件并發(fā)送給從節(jié)點(diǎn)。
- 執(zhí)行debug reload命令重新加載Redis時(shí),也會(huì)自動(dòng)觸發(fā)save操作。
- 默認(rèn)情況下執(zhí)行shutdown命令時(shí),如果沒有開啟AOF持久化功能則自動(dòng)執(zhí)行bgsave。
3. bgsave大致流程
流程說明:
- 執(zhí)行bgsave命令,Redis父進(jìn)程判斷當(dāng)前是否存在正在執(zhí)行的子進(jìn)程,如RDB/AOF子進(jìn)程,如果存在bgsave命令直接返回。
- 父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程,fork操作過程中父進(jìn)程會(huì)阻塞,通過
info stats
命令查看latest_fork_usec選項(xiàng),可以獲取最近一個(gè)fork操作的耗時(shí),單位為微秒。 - 父進(jìn)程fork完成后,bgsave命令返回“Background saving started”信息并不再阻塞父進(jìn)程,可以繼續(xù)響應(yīng)其他命令。
- 子進(jìn)程創(chuàng)建RDB文件,根據(jù)父進(jìn)程內(nèi)存生成臨時(shí)快照文件,完成后對(duì)原有文件進(jìn)行原子替換。執(zhí)行
lastsave
命令可以獲取最后一次生成RDB的時(shí)間,對(duì)應(yīng)info統(tǒng)計(jì)的rdb_last_save_time選項(xiàng)。 - 進(jìn)程發(fā)送信號(hào)給父進(jìn)程表示完成,父進(jìn)程更新統(tǒng)計(jì)信息,具體見info Persistence下的rdb_*相關(guān)選項(xiàng)。
關(guān)于RDB文件:
- 存儲(chǔ)位置:RDB文件保存在dir配置指定的目錄下,文件名通過dbfilename配置指定??梢酝ㄟ^執(zhí)行config set dir{newDir}和config set dbfilename{newFileName}運(yùn)行期動(dòng)態(tài)執(zhí)行,當(dāng)下次運(yùn)行時(shí)RDB文件會(huì)保存到新目錄。
- 壓縮:Redis默認(rèn)采用LZF算法對(duì)生成的RDB文件做壓縮處理,壓縮后的文件遠(yuǎn)遠(yuǎn)小于內(nèi)存大小,默認(rèn)開啟,可以通過參數(shù)config set rdbcompression{yes|no}動(dòng)態(tài)修改。
- 校驗(yàn):如果Redis加載損壞的RDB文件時(shí)拒絕啟動(dòng),并打印
# Short read or OOM loading DB. Unrecoverable error, aborting now.
(可以使用Redis提供的redis-check-dump工具檢測(cè)RDB文件并獲取對(duì)應(yīng)的錯(cuò)誤報(bào)告)。
4. RDB持久化方式的優(yōu)缺點(diǎn)
優(yōu)點(diǎn):
- RDB是一個(gè)緊湊壓縮的二進(jìn)制文件,代表Redis在某個(gè)時(shí)間點(diǎn)上的數(shù)據(jù)快照。非常適用于備份,全量復(fù)制等場(chǎng)景。比如每6小時(shí)執(zhí)行bgsave備份,并把RDB文件拷貝到遠(yuǎn)程機(jī)器或者文件系統(tǒng)中(如hdfs),用于災(zāi)難恢復(fù)。(數(shù)據(jù)緊湊,便于存儲(chǔ))
- Redis加載RDB恢復(fù)數(shù)據(jù)遠(yuǎn)遠(yuǎn)快于AOF的方式。(恢復(fù)速度快)
缺點(diǎn):
- RDB方式數(shù)據(jù)沒辦法做到實(shí)時(shí)持久化/秒級(jí)持久化。因?yàn)閎gsave每次運(yùn)行都要執(zhí)行fork操作創(chuàng)建子進(jìn)程,屬于重量級(jí)操作,頻繁執(zhí)行成本過高。(成本高)
- RDB文件使用特定二進(jìn)制格式保存,Redis版本演進(jìn)過程中有多個(gè)格式的RDB版本,存在老版本Redis服務(wù)無法兼容新版RDB格式的問題。(不兼容)
5. AOF
AOF(append only file)持久化:以獨(dú)立日志的方式記錄每次寫命令,重啟時(shí)再重新執(zhí)行AOF文件中的命令達(dá)到恢復(fù)數(shù)據(jù)的目的。主要作用是解決了數(shù)據(jù)持久化的實(shí)時(shí)性。
6. AOF的使用方式
- 開啟AOF功能需要設(shè)置配置:appendonly yes,默認(rèn)不開啟。
- AOF文件名通過appendfilename配置設(shè)置,默認(rèn)文件名是appendonly.aof。(路徑同RDB)
- 主要流程有命令寫入(append)、文件同步(sync)、文件重寫(rewrite)、重啟加載(load)。
7. AOF流程剖析
流程描述:
- 所有的寫入命令會(huì)追加到aof_buf(緩沖區(qū))中。
- AOF緩沖區(qū)根據(jù)對(duì)應(yīng)的策略向硬盤做同步操作。
- 隨著AOF文件越來越大,需要定期對(duì)AOF文件進(jìn)行重寫,達(dá)到壓縮的目的。
- 當(dāng)Redis服務(wù)器重啟時(shí),可以加載AOF文件進(jìn)行數(shù)據(jù)恢復(fù)。
7.1 命令寫入
AOF命令寫入的內(nèi)容直接是文本協(xié)議格式。例如set hello world這條命令,在AOF緩沖區(qū)會(huì)追加如下文本:
*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n
為什么使用文本協(xié)議格式?
- 文本協(xié)議具有很好的兼容性。(兼容性好)
- 開啟AOF后,所有寫入命令都包含追加操作,直接采用協(xié)議格式,避免了二次處理開銷。(處理簡(jiǎn)單)
- 文本協(xié)議具有可讀性,方便直接修改和處理。(方便修改)
為什么要追加到aof_buf中而不是直接寫入硬盤?
- 如果每次寫AOF文件命令都直接追加到硬盤,那么Redis的性能就會(huì)受到硬盤讀寫速度的影響,而硬盤的讀寫速度相對(duì)于內(nèi)存則是數(shù)量級(jí)上的差距,所以如果每次直接寫入硬盤則勢(shì)必會(huì)大幅度影響Redis的運(yùn)行速度。(影響運(yùn)行速度)
- 使用緩沖區(qū)暫存,Redis還可以提供多種緩沖區(qū)同步硬盤的策略,在性能和安全性方面做出平衡。(可以針對(duì)具體場(chǎng)景干預(yù)刷盤策略,以達(dá)到更好的效果)
7.2 文件同步
Redis提供了多種AOF緩沖區(qū)同步文件策略,由參數(shù)appendfsync控制。
系統(tǒng)調(diào)用write和fsync的幾點(diǎn)說明:
- write :會(huì)觸發(fā)延遲寫(delayed write)機(jī)制。Linux在內(nèi)核提供頁緩沖區(qū)用來提高硬盤IO性能。write操作在寫入系統(tǒng)緩沖區(qū)后直接返回。同步硬盤操作依賴于系統(tǒng)調(diào)度機(jī)制,例如:緩沖區(qū)頁空間寫滿或達(dá)到特定時(shí)間周期。同步文件之前,如果此時(shí)系統(tǒng)故障宕機(jī),緩沖區(qū)內(nèi)數(shù)據(jù)將丟失。(寫緩沖,定期由操作系統(tǒng)刷盤)
- fsync :針對(duì)單個(gè)文件操作(比如AOF文件),做強(qiáng)制硬盤同步,fsync將阻塞直到寫入硬盤完成后返回,保證了數(shù)據(jù)持久化。(立即將緩沖數(shù)據(jù)刷盤)
策略的幾點(diǎn)說明:
- always:每次寫入都要同步AOF文件,在一般的SATA硬盤上,Redis只能支持大約幾百TPS寫入,顯然跟Redis高性能特性背道而馳,不建議配置。
- no:由于操作系統(tǒng)每次同步AOF文件的周期不可控,而且會(huì)加大每次同步硬盤的數(shù)據(jù)量,雖然提升了性能,但數(shù)據(jù)安全性無法保證。
- everysec:是建議的同步策略,也是默認(rèn)配置,做到兼顧性能和數(shù)據(jù)安全性。(在系統(tǒng)突然宕機(jī)的情況下丟失1~2秒的數(shù)據(jù))
7.3 重寫機(jī)制
為什么要重寫?:
- 隨著命令不斷寫入AOF,文件會(huì)越來越大。
- 會(huì)包含越來越多無用的命令記錄。(比如最近一次對(duì)一個(gè)值的更新操作,那么在此之前記錄的更新操作都會(huì)作廢)
- 更小的AOF文件可以更快地被Redis加載。
怎么重寫?:
- AOF文件重寫就是把Redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令同步到新AOF文件。
重寫后那些優(yōu)化讓文件變小了?:
- 進(jìn)程內(nèi)已經(jīng)超時(shí)的數(shù)據(jù)不再寫入文件。(去除失效數(shù)據(jù))
- 舊的AOF文件含有無效命令,如del key1、hdel key2、srem keys、set a111、set a222等。重寫使用進(jìn)程內(nèi)數(shù)據(jù)直接生成,這樣新的AOF文件只保留最終數(shù)據(jù)的寫入命令。(去除無用命令)
- 多條寫命令可以合并為一個(gè),如:lpush list a、lpush list b、lpush list c可以轉(zhuǎn)化為:lpush list a b c;為了防止單條命令過大造成客戶 端緩沖區(qū)溢出,對(duì)于list、set、hash、zset等類型操作,以64個(gè)元素為界拆分為多條。(使用批量命令)
重寫有那些觸發(fā)方式?:
- 手動(dòng)觸發(fā) :直接調(diào)用bgrewriteaof命令。
- 自動(dòng)觸發(fā) :根據(jù)auto-aof-rewrite-min-size和auto-aof-rewritepercentage參數(shù)確定自動(dòng)觸發(fā)時(shí)機(jī)。
- auto-aof-rewrite-min-size:表示運(yùn)行AOF重寫時(shí)文件最小體積,默認(rèn)為64MB。(根據(jù)當(dāng)前文件大?。?/li>
- auto-aof-rewrite-percentage:代表當(dāng)前AOF文件空間(aof_current_size)和上一次重寫后AOF文件空間(aof_base_size)的比值。(根據(jù)文件大小的增量)
自動(dòng)觸發(fā)時(shí)機(jī):
aof_current_size > auto-aof-rewrite-minsize && (aof_current_size-aof_base_size)/aof_base_size >= auto-aof-rewrite-percentage
aof_current_size 和 aof_base_size 可以在info Persistence統(tǒng)計(jì)信息中查看。
重寫流程概述:
流程描述:
執(zhí)行AOF重寫請(qǐng)求。
- 如果當(dāng)前進(jìn)程正在執(zhí)行AOF重寫,請(qǐng)求不執(zhí)行并返回
ERR Background append only file rewriting already in progress
。 - 如果當(dāng)前進(jìn)程正在執(zhí)行bgsave操作,重寫命令延遲到bgsave完成之后再執(zhí)行,返回
Background append only file rewriting scheduled
- 如果當(dāng)前進(jìn)程正在執(zhí)行AOF重寫,請(qǐng)求不執(zhí)行并返回
- 父進(jìn)程執(zhí)行fork創(chuàng)建子進(jìn)程,開銷等同于bgsave過程。
- (1)主進(jìn)程fork操作完成后,繼續(xù)響應(yīng)其他命令。所有修改命令依然寫入AOF緩沖區(qū)并根據(jù)appendfsync策略同步到硬盤,保證原有AOF機(jī)制正確性。(2)由于fork操作運(yùn)用寫時(shí)復(fù)制技術(shù)(Copy On Write),子進(jìn)程只能共享fork操作時(shí)的內(nèi)存數(shù)據(jù)。由于父進(jìn)程依然響應(yīng)命令,Redis使用“AOF重寫緩沖區(qū)”保存這部分新數(shù)據(jù),防止新AOF文件生成期間丟失這部分?jǐn)?shù)據(jù)。
- 子進(jìn)程根據(jù)內(nèi)存快照,按照命令合并規(guī)則寫入到新的AOF文件。每次批量寫入硬盤數(shù)據(jù)量由配置aof-rewrite-incremental-fsync控制,默認(rèn)為32MB,防止單次刷盤數(shù)據(jù)過多造成硬盤阻塞。
- (1)新AOF文件寫入完成后,子進(jìn)程發(fā)送信號(hào)給父進(jìn)程,父進(jìn)程更新統(tǒng)計(jì)信息,具體見info persistence的aof_*相關(guān)統(tǒng)計(jì)。(2)父進(jìn)程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件(3)并使用新AOF文件替換老文件,完成AOF重寫。
7.4 重啟加載
流程描述:
- AOF持久化開啟且存在AOF文件時(shí),優(yōu)先加載AOF文件,并輸出
DB loaded from append only file: xxx seconds
。 - AOF關(guān)閉或者AOF文件不存在時(shí),加載RDB文件,并輸出
DB loaded from disk: xxx seconds
。 - 加載AOF或RDB文件成功后,Redis啟動(dòng)成功。
- AOF或RDB文件存在錯(cuò)誤時(shí),Redis啟動(dòng)失敗并打印錯(cuò)誤信息。
關(guān)于文件校驗(yàn):
加載損壞的AOF文件時(shí)會(huì)拒絕啟動(dòng),并會(huì)輸出:
Bad file format reading the append only file: make a backup of your AOF file,then use ./redis-check-aof --fix <filename>
對(duì)于錯(cuò)誤格式的AOF文件:先進(jìn)行備份,然后采用redis-check-aof --fix命令進(jìn)行修復(fù),修復(fù)后使用diff-u對(duì)比數(shù)據(jù)的差異,找出丟失的數(shù)據(jù),有些可以人工修改補(bǔ)全。
對(duì)于AOF文件結(jié)尾不完整:比如機(jī)器突然掉電導(dǎo)致AOF尾部文件命令寫入不全。Redis為我們提供了aof-load-truncated配置來兼容這種情況,默認(rèn)開啟。加載AOF時(shí),當(dāng)遇到此問題時(shí)會(huì)忽略并繼續(xù)啟動(dòng),同時(shí)打印如下警告日志:
# !!! Warning: short read while loading the AOF file !!! # !!! Truncating the AOF at offset 397856725 !!! # AOF loaded anyway because aof-load-truncated is enabled
8. 問題定位與優(yōu)化
8.1 關(guān)于fork操作
當(dāng)Redis做RDB或AOF重寫時(shí),一個(gè)必不可少的操作就是執(zhí)行fork操作創(chuàng)建子進(jìn)程,對(duì)于大多數(shù)操作系統(tǒng)來說fork是個(gè)重量級(jí)操作雖然fork創(chuàng)建的子進(jìn)程不需要拷貝父進(jìn)程的物理內(nèi)存空間,但是會(huì)復(fù)制父進(jìn)程的空間內(nèi)存頁表,因此fork操作耗時(shí)跟進(jìn)程總內(nèi)存量息息相關(guān)??梢栽趇nfo stats統(tǒng)計(jì)中查latest_fork_usec指標(biāo)獲取最近一次fork操作耗時(shí),單位微秒。
減少fork耗時(shí)的措施:
- 優(yōu)先使用物理機(jī)或者高效支持fork操作的虛擬化技術(shù),避免使用Xen。
- 控制Redis實(shí)例最大可用內(nèi)存,fork耗時(shí)跟內(nèi)存量成正比,線上建議每個(gè)Redis實(shí)例內(nèi)存控制在10GB以內(nèi)。
- 合理配置Linux內(nèi)存分配策略,避免物理內(nèi)存不足導(dǎo)致fork失敗。
- 降低fork操作的頻率,如適度放寬AOF自動(dòng)觸發(fā)時(shí)機(jī),避免不必要的全量復(fù)制等。
8.2 關(guān)于子進(jìn)程開銷
CPU:
- 分析:子進(jìn)程負(fù)責(zé)把進(jìn)程內(nèi)的數(shù)據(jù)分批寫入文件,這個(gè)過程屬于CPU密集操作,通常子進(jìn)程對(duì)單核CPU利用率接近90%。
- 優(yōu)化:
- Redis是CPU密集型服務(wù),不要做綁定單核CPU操作。由于子進(jìn)程非常消耗CPU,會(huì)和父進(jìn)程產(chǎn)生單核資源競(jìng)爭(zhēng)。
- 不要和其他CPU密集型服務(wù)部署在一起,造成CPU過度競(jìng)爭(zhēng)。
- 如果部署多個(gè)Redis實(shí)例,盡量保證同一時(shí)刻只有一個(gè)子進(jìn)程執(zhí)行重寫工作。
內(nèi)存:
- 分析:得益于Linux的寫時(shí)復(fù)制機(jī)制(copy on write),父子進(jìn)程會(huì)共享相同的物理內(nèi)存頁,當(dāng)父進(jìn)程處理寫請(qǐng)求時(shí)會(huì)把要修改的頁創(chuàng)建副本,而子進(jìn)程在fork操作過程中共享整個(gè)父進(jìn)程內(nèi)存快照。(重寫時(shí)共享同一份物理內(nèi)存區(qū)域,內(nèi)存主要開銷在于 拷貝的頁表 和 應(yīng)用 copy on write 時(shí)某些頁的拷貝 以及在進(jìn)行AOF重寫所使用的 aof_rewrite_buf占用的大小 )
- 優(yōu)化:
- 如果部署多個(gè)Redis實(shí)例,盡量保證同一時(shí)刻只有一個(gè)子進(jìn)程在工作。
- 避免在大量寫入時(shí)做子進(jìn)程重寫操作,這樣將導(dǎo)致父進(jìn)程維護(hù)大量頁副本,造成內(nèi)存消耗。
- Linux kernel在2.6.38內(nèi)核增加了Transparent Huge Pages(THP),支持huge page(2MB)的頁分配,默認(rèn)開啟。當(dāng)開啟時(shí)可以降低fork創(chuàng) 建子進(jìn)程的速度,但執(zhí)行fork之后,如果開啟THP,復(fù)制頁單位從原來4KB變?yōu)?MB,會(huì)大幅增加重寫期間父進(jìn)程內(nèi)存消耗。
硬盤:
- 分析:子進(jìn)程主要職責(zé)是把AOF或者RDB文件寫入硬盤持久化,所以在執(zhí)行重寫的時(shí)候勢(shì)必會(huì)增加硬盤的寫入壓力。根據(jù)Redis重寫AOF或RDB的數(shù)據(jù)量,結(jié)合系統(tǒng)工具如sar、iostat、iotop等,可分析出重寫期間硬盤負(fù)載情況。
- 優(yōu)化:
- 不要和其他高硬盤負(fù)載的服務(wù)部署在一起。如:存儲(chǔ)服務(wù)、消息隊(duì)列服務(wù)等。
- AOF重寫時(shí)會(huì)消耗大量硬盤IO,可以開啟配置no-appendfsyncon-rewrite,默認(rèn)關(guān)閉。表示在AOF重寫期間不做fsync操作,注意!配置no-appendfsync-on-rewrite=yes時(shí),在極端情況下可能丟失整個(gè)AOF重寫期間的數(shù)據(jù),需要根據(jù)數(shù)據(jù)安全性決定是否配置。
- 當(dāng)開啟AOF功能的Redis用于高流量寫入場(chǎng)景時(shí),Redis的性能會(huì)受到硬盤寫入性能的影響。
- 對(duì)于單機(jī)配置多個(gè)Redis實(shí)例的情況,可以配置不同實(shí)例分盤存儲(chǔ)AOF文件,分?jǐn)傆脖P寫入壓力。
8.3 關(guān)于AOF追加阻塞
描述:當(dāng)開啟AOF持久化時(shí),常用的同步硬盤的策略是everysec,用于平衡性能和數(shù)據(jù)安全性。對(duì)于這種方式,Redis使用另一條線程每秒執(zhí)行fsync同步硬盤。當(dāng)系統(tǒng)硬盤資源繁忙時(shí),會(huì)造成Redis主線程阻塞。
問題定位:
- 發(fā)生AOF阻塞時(shí),Redis輸出日志,用于記錄AOF fsync阻塞導(dǎo)致拖慢Redis服務(wù)的行為:
Asynchronous AOF fsync is taking too long (disk is busy). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redi
- 每當(dāng)發(fā)生AOF追加阻塞事件發(fā)生時(shí),在info Persistence統(tǒng)計(jì)中,aof_delayed_fsync指標(biāo)會(huì)累加,查看這個(gè)指標(biāo)方便定位AOF阻塞問題。
- AOF同步最多允許2秒的延遲,當(dāng)延遲發(fā)生時(shí)說明硬盤存在高負(fù)載問題。
流程概述:
- 主線程負(fù)責(zé)寫入AOF緩沖區(qū)。
- AOF線程負(fù)責(zé)每秒執(zhí)行一次同步磁盤操作,并記錄最近一次同步時(shí)間。
- 主線程負(fù)責(zé)對(duì)比上次AOF同步時(shí)間:
- 如果距上次同步成功時(shí)間在2秒內(nèi),主線程直接返回。
- 如果距上次同步成功時(shí)間超過2秒,主線程將會(huì)阻塞,直到同步操作完成。
也就是說:
- everysec配置最多可能丟失2秒數(shù)據(jù),不是1秒。
- 如果系統(tǒng)fsync緩慢,將會(huì)導(dǎo)致Redis主線程阻塞影響效率。
到此這篇關(guān)于一文詳解Redis中的持久化的文章就介紹到這了,更多相關(guān)Redis持久化內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
基于redis實(shí)現(xiàn)世界杯排行榜功能項(xiàng)目實(shí)戰(zhàn)
前段時(shí)間,做了一個(gè)世界杯競(jìng)猜積分排行榜。對(duì)世界杯64場(chǎng)球賽勝負(fù)平進(jìn)行猜測(cè),猜對(duì)+1分,錯(cuò)誤+0分,一人一場(chǎng)只能猜一次。下面通過本文給大家分享基于redis實(shí)現(xiàn)世界杯排行榜功能項(xiàng)目實(shí)戰(zhàn),感興趣的朋友一起看看吧2018-10-10RedisTemplate的使用與注意事項(xiàng)小結(jié)
本文詳細(xì)介紹了RedisTemplate的用途和使用方法,RedisTemplate是Spring提供的一個(gè)工具類,用于操作Redis數(shù)據(jù)庫,其API提供了豐富的方法來實(shí)現(xiàn)對(duì)Redis各種操作,本文就來詳細(xì)的介紹一下,感興趣的可以來了解一下2024-10-10redis 替代php文件存儲(chǔ)session的實(shí)例
這篇文章主要介紹了redis 替代php文件存儲(chǔ)session的實(shí)例的相關(guān)資料,希望通過本文能幫助到大家,讓大家掌握這樣的方法,需要的朋友可以參考下2017-10-10Redis5之后版本的高可用集群搭建的實(shí)現(xiàn)
這篇文章主要介紹了Redis5之后版本的高可用集群搭建的實(shí)現(xiàn),文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-04-04Redis 事務(wù)與過期時(shí)間詳細(xì)介紹
這篇文章主要介紹了Redis 事務(wù)與過期時(shí)間詳細(xì)介紹的相關(guān)資料,需要的朋友可以參考下2017-05-05Redis中?HyperLogLog數(shù)據(jù)類型使用小結(jié)
Redis使用HyperLogLog的主要作用是在大數(shù)據(jù)流(view,IP,城市)的情況下進(jìn)行去重計(jì)數(shù),這篇文章主要介紹了Redis中?HyperLogLog數(shù)據(jù)類型使用總結(jié),需要的朋友可以參考下2023-03-03dubbo服務(wù)使用redis注冊(cè)中心的系列異常解決
這篇文章主要為大家介紹了dubbo服務(wù)在使用redis注冊(cè)中心遇到的一系列異常的解決,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步2022-03-03