關(guān)于Redis數(shù)據(jù)持久化的概念介紹
一、數(shù)據(jù)持久化的概述
Redis是內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)都是存儲在內(nèi)存中，為了避免服務(wù)器斷電等原因?qū)е翿edis進(jìn)程異常退出后數(shù)據(jù)的永久丟失，需要定期將Redis中的數(shù)據(jù)以某種形式(或命數(shù)據(jù)令)從內(nèi)存保存到硬盤;當(dāng)下次Redis重啟時，利用持久化文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。除此之外，為了進(jìn)行災(zāi)難備份，可以將持久化文件拷貝到一個遠(yuǎn)程位置（NFS) 。
Redis提供兩種方式進(jìn)行持久化:
RDB持久化:原理是將Reids在內(nèi)存中的數(shù)據(jù)庫記錄定時保存到磁盤上。(類似快照)
AOF持久化(append only file):原理是將Reids的操作日志以追加的方式寫入文件，類似于MySQL的binlogo(基于日志持久化方式）
由于AOF持久化的實(shí)時性更好，即當(dāng)進(jìn)程意外退出時丟失的數(shù)據(jù)更少（一般設(shè)置每秒保存一次），因此AOF是目前主流的持久化方式，RDB持久化基本都會開啟(用于集群)
1、RDB持久化
（1）RDB持久化是指在指定的時間間隔內(nèi)將內(nèi)存中當(dāng)前進(jìn)程中的數(shù)據(jù)生成快照保存到硬盤(因此也稱作快照持久化)，用二進(jìn)制壓縮存儲，保存的文件后綴是rdb;當(dāng)Redis重新啟動時，可以讀取快照文件恢復(fù)數(shù)據(jù)。
Redis數(shù)據(jù)庫文件，全稱Redis DataBase -數(shù)據(jù)持久化方式之一 -數(shù)據(jù)持久化默認(rèn)方式 -按照指定時間間隔，將內(nèi)存中的數(shù)據(jù)集快照寫入硬盤-快照術(shù)語叫Snapshot - 恢復(fù)時，將快照文件直接讀入內(nèi)存 ·定義RDB文件名 - dbfilename "dump.rdb" #文件名
（2）觸發(fā)保存
優(yōu)化設(shè)置，數(shù)據(jù)從內(nèi)存保存到硬盤的頻率 - save 900 1 #15分鐘且有1個key改變時保存 - save 300 10 #5分鐘且有10個key改變時 - save 60 10000 #1分鐘且有10000個key改變時 手動進(jìn)行存盤 - save #阻塞寫存盤，保存過程中redis不允許寫入新數(shù)據(jù) - bgsave #不阻塞寫存盤
vim /etc/redis/6379.conf
#----219行----以下三個save條件滿足任意一個時，都會引起bgsave的調(diào)用 save 900 1 ：當(dāng)時間到900秒時，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsave save 300 10 ：當(dāng)時間到300秒時，如果redis數(shù)據(jù)發(fā)生了至少10次變化，則執(zhí)行bgsave save 60 10000 ：當(dāng)時間到60秒時，如果redis數(shù)據(jù)發(fā)生了至少10000次變化，則執(zhí)行bgsave #----242行----是否開啟RDB文件壓縮 rdbcompression yes #----254行----指定RDB文件名 dbfilename dump.rdb #----264行----指定RDB文件和AOF文件所在目錄 dir /var/lib/redis/6379
（3）其他自動觸發(fā)機(jī)制
除了save m n 以外，還有一些其他情況會觸發(fā)bgsave：
在主從復(fù)制場景下，如果從節(jié)點(diǎn)執(zhí)行全量復(fù)制操作，則主節(jié)點(diǎn)會執(zhí)行bgsave命令，并將rdb文件發(fā)送給從節(jié)點(diǎn)。
執(zhí)行shutdown關(guān)閉命令時，也自動執(zhí)行rdb持久化。
(4)執(zhí)行流程:
使用RDB文件恢復(fù)數(shù)據(jù) ·備份數(shù)據(jù) -備份dump.rdb 文件到其他位置 ]# cp 數(shù)據(jù)庫目錄/dump.rdb 備份目錄 ·恢復(fù)數(shù)據(jù) -拷貝備份文件到數(shù)據(jù)庫目錄，重啟redis服務(wù) ]#cp 備份目錄/dump.rdb 數(shù)據(jù)庫目錄/
(4) 啟動時加載
RDB文件的載入工作是在服務(wù)器啟動時自動執(zhí)行的，并沒有專門的命令。但是由于AOF的優(yōu)先級更高，因此當(dāng)AOF開啟時，Redis會優(yōu)先載入 AOF文件來恢復(fù)數(shù)據(jù)；只有當(dāng)AOF關(guān)閉時，才會在Redis服務(wù)器啟動時檢測RDB文件，并自動載入。服務(wù)器載入RDB文件期間處于阻塞狀態(tài)，直到載入完成為止。
Redis（AOF關(guān)閉的時候）載入RDB文件時，會對RDB文件進(jìn)行校驗(yàn)，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗
.AOF 持久化
RDB持久化是將進(jìn)程數(shù)據(jù)寫入文件，而AOF持久化，則是將Redis執(zhí)行的每次寫、刪除命令記錄到單獨(dú)的日志文件中，查詢操作不會記錄； 當(dāng)Redis重啟時再次執(zhí)行AOF文件中的命令來恢復(fù)數(shù)據(jù)。
與RDB相比，AOF的實(shí)時性更好，因此已成為主流的持久化方案。
2、開啟AOF
Redis服務(wù)器默認(rèn)開啟RDB，關(guān)閉AOF；要開啟AOF，需要在配置文件中配置：
（1）、修改配置文件
vim /etc/redis/6379.conf
①Redis父進(jìn)程首先判斷：當(dāng)前是否在執(zhí)行save，或bgsave/bgrewriteaof的子進(jìn)程，如果在執(zhí)行則bgsave命令直接返回。 bgsave/bgrewriteaof的子進(jìn)程不能同時執(zhí)行，主要是基于性能方面的考慮：兩個并發(fā)的子進(jìn)程同時執(zhí)行大量的磁盤寫操作，可能引起嚴(yán)重的性能問題。 ②父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個過程中父進(jìn)程是阻塞的，Redis不能執(zhí)行來自客戶端的任何命令 ③父進(jìn)程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令 ④子進(jìn)程創(chuàng)建RDB文件，根據(jù)父進(jìn)程內(nèi)存快照生成臨時快照文件，完成后對原有文件進(jìn)行原子替換 ⑤子進(jìn)程發(fā)送信號給父進(jìn)程表示完成，父進(jìn)程更新統(tǒng)計(jì)信息
（2）、執(zhí)行流程
#----700行----修改；開啟AOF appendonly yes #----704行----指定AOF文件名稱 appendfilename "appendonly.aof" #----796行----是否忽略最后一條可能存在問題的指令 aof-load-truncated yes #指redis在恢復(fù)時，會忽略最后一條可能存在問題的指令，默認(rèn)為yes，即在aof寫入時，可能存在指令錯誤的問題（突然斷電導(dǎo)致未執(zhí)行結(jié)束），這種情況下，yes會log并繼續(xù)，而no會直接恢復(fù)失敗 /etc/init.d/redis_6379 restart #需要先取消密碼
文件重寫的觸發(fā)，分為手動觸發(fā)和自動觸發(fā)：
手動觸發(fā)：直接調(diào)用bgrewriteaof命令，該命令的執(zhí)行與bgsave有些類似：都是fork子進(jìn)程進(jìn)行具體的工作，且都只有在fork時阻塞。
自動觸發(fā)：通過設(shè)置auto-aof-rewrite-min-size選項(xiàng)和auto-aof-rewrite-percentage選項(xiàng)來自動執(zhí)行BGREWRITEAOF。 只有當(dāng)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個選項(xiàng)同時滿足時，才會自動觸發(fā)AOF重寫，即bgrewriteaof操作。
由于需要記錄Redis的每條寫命令，因此AOF不需要觸發(fā)，下面介紹AOF的執(zhí)行流程。 AOF的執(zhí)行流程包括： 命令追加(append)：將Redis的寫命令追加到緩沖區(qū)aof_buf 文件寫入(write)和文件同步(sync)：根據(jù)不同的同步策略將aof_buf中的內(nèi)容同步到硬盤 文件重寫(rewrite)：定期重寫AOF文件，達(dá)到壓縮的目的 ①、命令追加（append） Redis先將寫命令追加到緩沖區(qū)，而不是直接寫入文件，主要是為了避免每次有寫命令都直接寫入硬盤，導(dǎo)致硬盤IO成為Redis負(fù)載的瓶頸。 命令追加的格式是Redis命令請求的協(xié)議格式，它是一種純文本格式，具有兼容性好、可讀性強(qiáng)、容易處理、操作簡單避免二次開銷等優(yōu)點(diǎn)。在AOF文件中，除了用于指定數(shù)據(jù)庫的select命令（如select 0為選中0號數(shù)據(jù)庫）是由Redis添加的，其他都是客戶端發(fā)送來的寫命令。 ②、文件寫入（write）和文件同步（sync） Redis提供了多種AOF緩存區(qū)的同步文件策略，策略涉及到操作系統(tǒng)的 write 函數(shù)和 fsync 函數(shù)，說明如下： 為了提高文件寫入效率，在現(xiàn)代操作系統(tǒng)中，當(dāng)用戶調(diào)用write函數(shù)將數(shù)據(jù)寫入文件時，操作系統(tǒng)通常會將數(shù)據(jù)暫存到一個內(nèi)存緩沖區(qū)里，當(dāng)緩沖區(qū)被填滿或超過了指定時限后，才真正將緩沖區(qū)的數(shù)據(jù)寫入到硬盤里。這樣的操作雖然提高了效率，但也帶來了安全問題：如果計(jì)算機(jī)停機(jī)，內(nèi)存緩沖區(qū)中的數(shù)據(jù)會丟失；因此系統(tǒng)同時提供了fsync、fdatasync等同步函數(shù)，可以強(qiáng)制操作系統(tǒng)立刻將緩沖區(qū)中的數(shù)據(jù)寫入到硬盤里，從而確保數(shù)據(jù)的安全性。 AOF緩存區(qū)的同步文件策略存在三種同步方式，它們分別是：（vim /etc/redis/6379.conf ----》 729行 ） appendfsync always： 命令寫入aof_buf后立即調(diào)用系統(tǒng)fsync操作同步到AOF文件，fsync完成后線程返回。這種情況下，每次有寫命令都要同步到AOF文件，硬盤IO成為性能瓶頸，Redis只能支持大約幾百TPS寫入，嚴(yán)重降低了Redis的性能；即便是使用固態(tài)硬盤（SSD），每秒大約也只能處理幾萬個命令，而且會大大降低SSD的壽命。 appendfsync no： 命令寫入aof_buf后調(diào)用系統(tǒng)write操作，不對AOF文件做fsync同步；同步由操作系統(tǒng)負(fù)責(zé)，通常同步周期為30秒。這種情況下，文件同步的時間不可控，且緩沖區(qū)中堆積的數(shù)據(jù)會很多，數(shù)據(jù)安全性無法保證。 appendfsync everysec： 命令寫入aof_buf后調(diào)用系統(tǒng)write操作，write完成后線程返回；fsync同步文件操作由專門的線程每秒調(diào)用一次。everysec是前述兩種策略的折中，是性能和數(shù)據(jù)安全性的平衡，因此是Redis的默認(rèn)配置，也是我們推薦的配置。 ③、文件重寫（rewrite） 隨著時間流逝，Redis服務(wù)器執(zhí)行的寫命令越來越多，AOF文件也會越來越大；過大的AOF文件不僅會影響服務(wù)器的正常運(yùn)行，也會導(dǎo)致數(shù)據(jù)恢復(fù)需要的時間過長。 文件重寫是指定期重寫AOF文件，減小AOF文件的體積。 AOF重寫是把Redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令，同步到新的AOF文件 不會對舊的AOF文件進(jìn)行任何讀取、寫入操作 對于AOF持久化來說，文件重寫雖然是強(qiáng)烈推薦的，但并不是必須的；即使沒有文件重寫，數(shù)據(jù)也可以被持久化并在Redis啟動的時候?qū)?；因此在一些?shí)現(xiàn)中，會關(guān)閉自動的文件重寫，然后通過定時任務(wù)在每天的某一時刻定時執(zhí)行。
文件重寫之所以能夠壓縮AOF文件，原因在于：
過期的數(shù)據(jù)不再寫入文件
無效的命令不再寫入文件：如有些數(shù)據(jù)被重復(fù)設(shè)值(set mykey v1, set mykey v2)、有些數(shù)據(jù)被刪除了(sadd myset v1, del myset)等。
多條命令可以合并為一個：如sadd myset v1, sadd myset v2, sadd myset v3可以合并為sadd myset v1 v2 v3。
文件重寫的觸發(fā)，分為手動觸發(fā)和自動觸發(fā)：
手動觸發(fā)：直接調(diào)用bgrewriteaof命令，該命令的執(zhí)行與bgsave有些類似：都是fork子進(jìn)程進(jìn)行具體的工作，且都只有在fork時阻塞。
自動觸發(fā)：通過設(shè)置auto-aof-rewrite-min-size選項(xiàng)和auto-aof-rewrite-percentage選項(xiàng)來自動執(zhí)行BGREWRITEAOF。 只有當(dāng)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個選項(xiàng)同時滿足時，才會自動觸發(fā)AOF重寫，即bgrewriteaof操作。
auto-aof-rewrite-percentage 100 ：當(dāng)前AOF文件大小(即aof_current_size)是上次日志重寫時AOF文件大小(aof_base_size)兩倍時，發(fā)生BGREWRITEAOF操作 auto-aof-rewrite-min-size 64mb ：當(dāng)前AOF文件執(zhí)行BGREWRITEAOF命令的最小值，避免剛開始啟動Reids時由于文件尺寸較小導(dǎo)致頻繁的BGREWRITEAOF vim /etc/redis/6379.conf #----729行---- auto-aof-rewrite-percentage 100 #當(dāng)前AOF文件大?。碼of_current_size）是上次日志重寫時AOF文件大小（aof_base_size）的兩倍時，發(fā)生bgrewriteaof操作 auto-aof-rewrite-min-size 64mb #當(dāng)前AOF文件執(zhí)行bgrewriteaof命令的最小值，避免剛開始啟動redis時由于文件尺寸較小導(dǎo)致頻繁的bgrewriteaof 注意： 重寫由父進(jìn)程fork子進(jìn)程進(jìn)行 重寫期間Redis執(zhí)行的寫命令，需要追加到新的AOF文件中，為此Redis引入了aof_rewrite_buf緩存。
（3）、文件重寫的流程如下
Redis父進(jìn)程首先判斷當(dāng)前是否存在正在執(zhí)行bgsave/bgrewriteaof的子進(jìn)程，如果存在則bgrewriteaof命令直接返回，如果存在 bgsave命令則等bgsave執(zhí)行完成后再執(zhí)行。
父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個過程中父進(jìn)程是阻塞的。
父進(jìn)程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父進(jìn)程， 并可以響應(yīng)其他命令。Redis的所有寫命令依然寫入AOF緩沖區(qū)，并根據(jù)appendfsync策略同步到硬盤，保證原有AOF機(jī)制的正確。
由于fork操作使用寫時復(fù)制技術(shù)，子進(jìn)程只能共享fork操作時的內(nèi)存數(shù)據(jù)。由于父進(jìn)程依然在響應(yīng)命令，因此Redis使用AOF重寫緩沖區(qū)(aof_rewrite_buf)保存這部分?jǐn)?shù)據(jù)，防止新AOF文件生成期間丟失這部分?jǐn)?shù)據(jù)。也就是說，bgrewriteaof執(zhí)行期間，Redis的寫命令同時追加到aof_buf和aof_rewirte_buf兩個緩沖區(qū)。
子進(jìn)程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新的AOF文件。
子進(jìn)程寫完新的AOF文件后，向父進(jìn)程發(fā)信號，父進(jìn)程更新統(tǒng)計(jì)信息，具體可以通過info persistence查看。
父進(jìn)程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件，這樣就保證了新AOF文件所保存的數(shù)據(jù)庫狀態(tài)和服務(wù)器當(dāng)前狀態(tài)一致。
使用新的AOF文件替換老文件，完成AOF重寫。
（4）、啟動時加載
當(dāng)AOF開啟時，Redis啟動時會優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù)；只有當(dāng)AOF關(guān)閉時，才會載入RDB文件恢復(fù)數(shù)據(jù)。
當(dāng)AOF開啟，但AOF文件不存在時，即使RDB文件存在也不會加載。
Redis載入AOF文件時，會對AOF文件進(jìn)行校驗(yàn)，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。但如果是AOF文件結(jié)尾不完整(機(jī)器突然宕機(jī)等容易導(dǎo)致文件尾部不完整)，且aof-load-truncated參數(shù)開啟，則日志中會輸出警告，Redis忽略掉AOF文件的尾部，啟動成功。aof-load-truncated參數(shù)默認(rèn)是開啟的。
二 .RDB 和 AOF 的優(yōu)缺點(diǎn)
1、 RDB 持久化優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：RDB文件緊湊，體積小，網(wǎng)絡(luò)傳輸快，適合全量復(fù)制；恢復(fù)速度比AOF快很多。當(dāng)然，與AOF相比，RDB最重要的優(yōu)點(diǎn)之一是對性能的影響相對較小。
缺點(diǎn)：RDB文件的致命缺點(diǎn)在于其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實(shí)時持久化，而在數(shù)據(jù)越來越重要的今天，數(shù)據(jù)的大量丟失很多時候是無法接受的，因此AOF持久化成為主流。此外，RDB文件需要滿足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。
對于RDB持久化，一方面是bgsave在進(jìn)行fork操作時Redis主進(jìn)程會阻塞，另一方面，子進(jìn)程向硬盤寫數(shù)據(jù)也會帶來IO壓力。
2、 AOF 持久化優(yōu)缺點(diǎn)
與RDB持久化相對應(yīng)，AOF的優(yōu)點(diǎn)在于支持秒級持久化、兼容性好，缺點(diǎn)是文件大、恢復(fù)速度慢、對性能影響大。
對于AOF持久化，向硬盤寫數(shù)據(jù)的頻率大大提高(everysec策略下為秒級)，IO壓力更大，甚至可能造成AOF追加阻塞問題。
AOF文件的重寫與RDB的bgsave類似，會有fork時的阻塞和子進(jìn)程的IO壓力問題。相對來說，由于AOF向硬盤中寫數(shù)據(jù)的頻率更高，因此對 Redis主進(jìn)程性能的影響會更大
.Redis 性能管理
9.1查看Redis內(nèi)存使用
redis-cli -h 192.168.184.10 -p 6379 #登錄
info memory #輸入指令進(jìn)行查看
9.2內(nèi)存碎片率
操作系統(tǒng)分配的內(nèi)存值used_memory_rss除以Redis使用的內(nèi)存值used_memory計(jì)算得出內(nèi)存碎片是由操作系統(tǒng)低效的分配/回收物理內(nèi)存導(dǎo)致的（不連續(xù)的物理內(nèi)存分配）
跟蹤內(nèi)存碎片率對理解Redis實(shí)例的資源性能是非常重要的：
內(nèi)存碎片率稍大于1是合理的，這個值表示內(nèi)存碎片率比較低
內(nèi)存碎片率超過1.5，說明Redis消耗了實(shí)際需要物理內(nèi)存的150%，其中50%是內(nèi)存碎片率。需要在redis-cli工具上輸入shutdown save 命令，并重啟 Redis 服務(wù)器。
內(nèi)存碎片率低于1的，說明Redis內(nèi)存分配超出了物理內(nèi)存，操作系統(tǒng)正在進(jìn)行內(nèi)存交換。需要增加可用物理內(nèi)存或減少 Redis 內(nèi)存占用。
9.3內(nèi)存使用率
redis實(shí)例的內(nèi)存使用率超過可用最大內(nèi)存，操作系統(tǒng)將開始進(jìn)行內(nèi)存與swap空間交換。
避免內(nèi)存交換發(fā)生的方法：
（1）針對緩存數(shù)據(jù)大小選擇安裝 Redis 實(shí)例
（2）盡可能的使用Hash數(shù)據(jù)結(jié)構(gòu)存儲
（3）設(shè)置key的過期時間
9.4 內(nèi)回收key
保證合理分配redis有限的內(nèi)存資源。
當(dāng)達(dá)到設(shè)置的最大閥值時，需選擇一種key的回收策略，默認(rèn)情況下回收策略是禁止刪除。
配置文件中修改 maxmemory-policy 屬性值：
vim /etc/redis/6379.conf
#----598取消注釋---- maxmemory-policy noenviction volatile-lru ：使用LRU算法從已設(shè)置過期時間的數(shù)據(jù)集合中淘汰數(shù)據(jù) volatile-ttl ：從已設(shè)置過期時間的數(shù)據(jù)集合中挑選即將過期的數(shù)據(jù)淘汰 volatile-random ：從已設(shè)置過期時間的數(shù)據(jù)集合中隨機(jī)挑選數(shù)據(jù)淘汰 allkeys-lru ：使用LRU算法從所有數(shù)據(jù)集合中淘汰數(shù)據(jù) allkeys-random ：從數(shù)據(jù)集合中任意選擇數(shù)據(jù)淘汰 noenviction ：禁止淘汰數(shù)據(jù)
到此這篇關(guān)于關(guān)于Redis數(shù)據(jù)的持久化的概念介紹的文章就介紹到這了,更多相關(guān)Redis數(shù)據(jù)持久化內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
這篇文章主要介紹了Redis解決Session共享問題,本文結(jié)合實(shí)例代碼給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下2023-07-07
與發(fā)生時間相關(guān)的一組數(shù)據(jù),就是時間序列數(shù)據(jù),這些數(shù)據(jù)的特點(diǎn)是沒有嚴(yán)格的關(guān)系模型,記錄的信息可以表示成鍵和值的關(guān)系,這篇文章主要給大家介紹了關(guān)于在Redis中如何保存時間序列數(shù)據(jù)的相關(guān)資料,需要的朋友可以參考下2021-10-10
這篇文章主要介紹了Redis教程(十四)：內(nèi)存優(yōu)化介紹,本文講解了特殊編碼、BIT和Byte級別的操作、盡可能使用Hash等內(nèi)容,需要的朋友可以參考下2015-05-05
本文將介紹Redis中Lua腳本的基本用法，以及腳本超時導(dǎo)致的問題和處理方式。文中通過示例代碼介紹的非常詳細(xì)，感興趣的小伙伴們可以參考一下2021-11-11
一些Redis原語命令比如LPUSH、LTRIM和 LREM等等能夠用來幫助開發(fā)者完成需要的任務(wù)——這些任務(wù)在傳統(tǒng)的數(shù)據(jù)庫存儲中非常困難或緩慢。這是一篇非常有用并且實(shí)際的文章。那么要如何在你的框架中完成這些任務(wù)呢?2015-09-09
本文主要介紹了Redis分片集群搭建及其原理，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-06-06
Redis出現(xiàn)(error)NOAUTH?Authentication?required.報(bào)錯的解決辦法(秒懂!)
這篇文章主要給大家介紹了關(guān)于Redis出現(xiàn)(error)NOAUTH?Authentication?required.報(bào)錯的解決辦法,對于 這個錯誤這通常是因?yàn)镽edis服務(wù)器需要密碼進(jìn)行身份驗(yàn)證,但客戶端沒有提供正確的身份驗(yàn)證信息導(dǎo)致的,需要的朋友可以參考下2024-03-03
本文主要介紹了Redis實(shí)現(xiàn)訂單過期刪除的方法步驟，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2022-06-06
這篇文章給大家整理了在操作Redis字符串類型中的常用命令，文章總結(jié)的很全面，對大家學(xué)習(xí)Redis具有一定的參考借鑒價值，下面來一起看看吧。2016-09-09
今天小編就為大家分享一篇使用redis管理用戶登錄會話的方法，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2018-05-05