一、高可用

什么是高可用

在web服務(wù)器中，高可用是指服務(wù)器可以正常訪問的時間，衡量的標準是在多長時間內(nèi)可以提供正常服務(wù)(99.9%、99.99%、99.999%等等)。

但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(wù)( 如主從分離、快速容災(zāi)技術(shù))，還需要考慮數(shù)據(jù)容量的擴展、數(shù)據(jù)安全不會丟失等。

Redis的高可用

Redis中，實現(xiàn)高可用的技術(shù)主要包括持久化、主從復(fù)制、哨兵和cluster集群

持久化：持久化是最簡單的高可用方法（有時甚至不被歸為高可用的手段），主要作用是數(shù)據(jù)備份，即將數(shù)據(jù)存儲在硬盤，保證數(shù)據(jù)不會因進程退出而丟失。

主從復(fù)制：主從復(fù)制是高可用Redis的基礎(chǔ)，哨兵和集群都是在主從復(fù)制基礎(chǔ)上實現(xiàn)高可用的。主從復(fù)制主要實現(xiàn)了數(shù)據(jù)的多機備份（和同步），以及對于讀操作的負載均衡和簡單的故障恢復(fù)。

缺陷：故障恢復(fù)無法自動化，寫操作無法負載均衡，存儲能力受到單機的限制。

哨兵：在主從復(fù)制的基礎(chǔ)上，哨兵實現(xiàn)了自動化的故障恢復(fù)。（主掛了，找一個從成為新的主，哨兵節(jié)點進行監(jiān)控）

缺陷：寫操作無法負載均衡，存儲能力受到單機的限制；哨兵無法對從節(jié)點進行自動故障轉(zhuǎn)移，在讀寫分離場景下，從節(jié)點故障會導(dǎo)致讀服務(wù)不可用，需要對從節(jié)點做額外的監(jiān)控、切換操作。

Cluster集群：通過集群，Redis解決了寫操作無法負載均衡，以及存儲能力受到單機限制的問題，實現(xiàn)了較為完善的高可用方案（6臺起步，成雙成對，3主3從）

二、Redis持久化

持久化功能

Redis是內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)都是存儲在內(nèi)存中，為了避免服務(wù)器斷電等原因?qū)е翿edis進程異常退出后數(shù)據(jù)的永久丟失，需要定期將Redis中的數(shù)據(jù)以某種形式（數(shù)據(jù)或命令）從內(nèi)存保存到硬盤；當下次Redis重啟時，利用持久化文件實現(xiàn)數(shù)據(jù)恢復(fù)。除此之外，為了進行災(zāi)難備份，可以將持久化文件拷貝到一個遠程位置。

災(zāi)難備份：一般做異地備份，發(fā)生災(zāi)難后切換節(jié)點。

Redis提供兩種方式進行持久化

• RDB持久化：原理是將Redis在內(nèi)存中的數(shù)據(jù)庫記錄定時保存到磁盤上。（定時對內(nèi)存中的數(shù)據(jù)生成快照，以文件形式保存在硬盤中）
• AOF持久化（append only file）：原理是將Reids 的操作日志以追加的方式寫入文件，類似于MySQL的binlog。（類似于Mysql的二進制日志）（以追加的方式將寫和刪的操作命令記錄到AOF文件中）

由于AOF持久化的實時性更好，即當進程意外退出時丟失的數(shù)據(jù)更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地。（RDB體積小，恢復(fù)速度更快。對性能影響較小。

RDB持久化

RDB持久化是指在指定的時間間隔內(nèi)將內(nèi)存中當前進程中的數(shù)據(jù)生成快照保存到硬盤（因此也稱作快照持久化），用二進制壓縮存儲，保存的文件后綴是rdb；當Redis重新啟動時，可以讀取快照文件恢復(fù)數(shù)據(jù)。

 觸發(fā)條件

RDB持久化的觸發(fā)分為手動觸發(fā)和自動觸發(fā)

手動觸發(fā)

save命令和bgsave命令都可以生成RDB文件

save命令阻塞Redis服務(wù)器進程，直到RDB文件創(chuàng)建完畢為止，在Redis服務(wù)器阻塞期間，服務(wù)器不能處理任何命令請求。

bgsave命令會創(chuàng)建一個子進程，由子進程來負責(zé)創(chuàng)建RDB文件，父進程（即Redis主進程）則繼續(xù)處理請求。

bgsave命令執(zhí)行過程中，只有fork子進程時會阻塞服務(wù)器，而對于save命令，整個過程都會阻塞服務(wù)器，因此save已基本被廢棄，線上環(huán)境要杜絕save的使用。

自動觸發(fā)

在自動觸發(fā)RDB持久化時，Redis也會選擇bgsave而不是save來進行持久化。

自動觸發(fā)最常見的情況是在配置文件中通過save m n 指定當m秒內(nèi)發(fā)生n次變化時，會觸發(fā)bgsave。

vim /etc/redis/6379.conf219行以下三個save條件滿足任意一個時，都會引起bgsave的調(diào)用save 900 1      #當時間到900秒時，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsavesave 300 10     #當時間到300秒時，如果redis數(shù)據(jù)發(fā)生了至少10次變化，則執(zhí)行bgsavesave 60 10000   #當時間到60秒時，如果redis數(shù)據(jù)發(fā)生了至少10000次變化，則執(zhí)行bgsave242行開啟RDB文件壓縮rdbcompression yes254行 指定RDB文件名dbfilename dump.rdb264行 指定RDB文件和AOF文件所在目錄dir /var/lib/redis/6379

由此可見RDB時效性不夠，最快也需60秒備份一次，如果50幾秒服務(wù)器宕了，則備份失敗

其他觸發(fā)機制

除savemn以外，還有其他情況也會觸發(fā)

• 在主從復(fù)制場景下，如果從節(jié)點執(zhí)行全量復(fù)制操作，則主節(jié)點會執(zhí)行bgsave命令，并將rdb文件發(fā)送給從節(jié)點。
• 執(zhí)行shutdown命令時，自動執(zhí)行rdb持久化。

bgsave執(zhí)行流程

1、Redis父進程首先判斷：當前是否在執(zhí)行save，或 bgsave/ bgrewriteaof 的子進程，如果在執(zhí)行則bgsave命令直接返回。

• bgsave/bgrewriteaof 的子進程不能同時執(zhí)行，主要是基于性能方面的考慮：兩個并發(fā)的子進程同時執(zhí)行大量的磁盤寫操作，可能引起嚴重的性能問題。

2、父進程執(zhí)行fork操作創(chuàng)建子進程，這個過程中父進程是阻塞的，Redis不能執(zhí)行來自客戶端的任何命令。

3、父進程fork后，bgsave 命令返回"Background saving started" 信息并不再阻塞父進程，并可以響應(yīng)其他命令。

4、子進程創(chuàng)建RDB文件，根據(jù)父進程內(nèi)存快照生成臨時快照文件，完成后對原有文件進行原子替換。（原子替換：文件整體替換，要么都發(fā)生，要么都不發(fā)生）

5、子進程發(fā)送信號給父進程表示完成，父進程更新統(tǒng)計信息。

啟動時加載

• RDB文件的載入工作是在服務(wù)器啟動時自動執(zhí)行的，并沒有專門的命令。但是由于AOF的優(yōu)先級更高，因此當AOF開啟時，Redis會優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù)；只有當AOF關(guān)閉時，才會在Redis服務(wù)器啟動時檢測RDB文件，并自動載入。 服務(wù)器載入RDB文件期間處于阻塞狀態(tài)，直到載入完成為止。
• Redis載入RDB文件時，會對RDB文件進行校驗，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。

AOF持久化

• RDB持久化是將進程數(shù)據(jù)寫入文件，而AOF持久化，則是將Redis執(zhí)行的每次寫、刪除命令記錄到單獨的日志文件中，查詢操作不會記錄。
• 當Redis重啟時再次執(zhí)行AOF文件中的命令來恢復(fù)數(shù)據(jù)。（重放命令進行恢復(fù)）。
• 與RDB相比，AOF的實時性更好，因此已成為主流的持久化方案。

開啟AOF

Redis服務(wù)器默認開啟RDB，在/etc/redis/6379.conf配置文件中

/etc/init.d/redis_6379 restart

#重啟redis

執(zhí)行流程

由于需要記錄Redis的每條寫命令，因此AOF不需要觸發(fā)。

流程包括：

• 命令追加：將Redis的寫命令追加到緩沖區(qū)aof_buf
• 文件寫入和文件同步：根據(jù)不同的同步策略將aof_buf中的內(nèi)容同步到硬盤
• 文件重寫：定期重寫AOF文件，達到壓縮目的（將過期數(shù)據(jù)、無效命令、多條命令，進行壓縮或刪除）

命令追加

• Redis先將寫命令追加到緩沖區(qū)，而不是直接寫入文件，主要是為了避免每次有寫命令都直接寫入硬盤，導(dǎo)致硬盤IO成為Redis負載的瓶頸。
• 命令追加的格式是Redis命令請求的協(xié)議格式，它是一種純文本格式，具有兼容性好、可讀性強、容易處理、操作簡單避免二次開銷等優(yōu)點。
• 在AOF文件中，除了用于指定數(shù)據(jù)庫的select命令（如select 0為選中0號數(shù)據(jù)庫）是由Redis添加的， 其他都是客戶端發(fā)送來的寫命令。

文件寫入和文件同步

Redis提供了多種AOF緩存區(qū)的同步文件策略，策略涉及到操作系統(tǒng)的write函數(shù)和fsync函數(shù)，說明如下：

• 為了提高文件寫入效率，在現(xiàn)代操作系統(tǒng)中，當用戶調(diào)用write函數(shù)將數(shù)據(jù)寫入文件時，操作系統(tǒng)通常會將數(shù)據(jù)暫存到一個內(nèi)存緩沖區(qū)里，當緩沖區(qū)被填滿或超過了指定時限后，才真正將緩沖區(qū)的數(shù)據(jù)寫入到硬盤里。
• 這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機，內(nèi)存緩沖區(qū)中的數(shù)據(jù)會丟失。因此系統(tǒng)同時提供了fsync、fdatasync等同步函數(shù)，可以強制操作系統(tǒng)立刻將緩沖區(qū)中的數(shù)據(jù)寫入到硬盤里，從而確保數(shù)據(jù)的安全性。

AOF緩存區(qū)的同步文件策略存在三種同步方式

• appendfsync always：命令寫入aof_buf后立即調(diào)用系統(tǒng)fsync操作同步到AOF文件。安全性高，性能低。
• appendfsync no：當緩沖區(qū)被填滿或超過了指定時限后（默認30秒），才將緩沖區(qū)的數(shù)據(jù)寫入到硬盤里。性能高，但安全性低。
• appendfsync everysec：每秒同步一次，是性能和數(shù)據(jù)安全性的平衡，因此是Redis的默認配置。

文件重寫

• 隨著時間流逝，Redis服務(wù)器執(zhí)行的寫命令越來越多，AOF文件也會越來越大；過大的AOF文件不僅會影響服務(wù)器的正常運行，也會導(dǎo)致數(shù)據(jù)恢復(fù)需要的時間過長。
• 文件重寫是指定期重寫AOF文件，減小AOF文件的體積。需要注意的是，AOF 重寫是把Redis進程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令，同步到新的AOF文件；不會對舊的AOF文件進行任何讀取、寫入操作！
• 關(guān)于文件重寫需要注意的另一點是：對于AOF持久化來說，文件重寫雖然是強烈推薦的，但并不是必須的；即使沒有文件重寫，數(shù)據(jù)也可以被持久化并在Redis啟動的時候?qū)?。因此在一些現(xiàn)實中，會關(guān)閉自動的文件重寫，然后通過定時任務(wù)在每天的某一時刻定時執(zhí)行。

文件重寫之所以能夠壓縮AOF文件，是因為

• 過期的數(shù)據(jù)不再寫入文件。
• 無效的命令不再寫入文件：如有些數(shù)據(jù)被重復(fù)設(shè)值（set key v1, set key v2）、 有些數(shù)據(jù)被刪除了（set myset vl, del myset）等。
• 多條命令可以合并為一個：如sadd myset v1, sadd myset v2, sadd myset v3可以合并為sadd myset v1 v2 v3。（sadd添加集合）

rewrite之后aof文件會保存keys的最后狀態(tài)，清除掉之前冗余的，來縮小這個文件。

由此可以看出，由于重寫后AOF執(zhí)行的命令減少了，文件重寫既可以減少文件占用的空間，也可以加快恢復(fù)速度。

文件重寫的觸發(fā)方式

• 手動觸發(fā)： 直接調(diào)用bgrewriteaof命令，該命令的執(zhí)行與bgsave有些類似：都是fork子進程進行具體的工作，且都只有在fork時阻塞。
• 自動觸發(fā)： 通過設(shè)置auto-aof-rewrite-min-size選項和auto-aof-rewrite-percentage選項來自動執(zhí)行BGREWRITEAOF。

只有當這兩個選項同時滿足，才會自動觸發(fā)AOF重寫

 auto-aof-rewrite-percentage 100    

#文件的大小超過基準百分之多少后觸發(fā)bgrewriteaof。默認這個值設(shè)置為100，意味著當前aof是基準大小的兩倍的時候觸發(fā)bgrewriteaof。把它設(shè)置為0可以禁用自動觸發(fā)的功能。 即當前AOF文件大小(即aof_current_size)是上次日志重寫時AOF文件大小(aof_base_size)兩倍時，發(fā)生BGREWRITEAOF操作。 注意：例如上次文件達到100M進行重寫，那么這次需要達到200M時才進行重寫。文件需要越來越大，所以一般不使用自動重寫。如果使用自動重寫，需要定期手動重寫干預(yù)一次，讓文件要求恢復(fù)到100M。

auto-aof-rewrite-min-size 64mb    

 #當文件大于64M時才會進行重寫  #當前aof文件大于多少字節(jié)后才觸發(fā)。當前AOF文件執(zhí)行BGREWRITEAOF命令的最小值，避免剛開始啟動Reids時由于文件尺寸較小導(dǎo)致頻繁的BGREWRITEAOF

文件重寫流程

（1）Redis父進程首先判斷當前是否存在正在執(zhí)行bgsave/bgrewriteaof的子進程，如果存在則bgrewriteaof命令直接返回，如果存在bgsave命令則等bgsave執(zhí)行完成后再執(zhí)行。（正常情況下使用AOF就會使用AOF進行記錄，不會使用RDB。主從復(fù)制時會自動觸發(fā)bgsave命令）

（2）父進程執(zhí)行fork操作創(chuàng)建子進程，這個過程中父進程是阻塞的（無法接受任何客戶端的請求）。

（3.1）父進程fork后，bgrewriteaof 命令返回"Background append only file rewrite started" 信息并不再阻塞父進程，并可以響應(yīng)其他命令。Redis的所有寫命令依然寫入AOF緩沖區(qū)，并根據(jù)appendfsync策略同步到硬盤，保證原有AOF機制的正確。

（3.2）由于fork操作使用寫時復(fù)制技術(shù)，子進程只能共享fork操作時的內(nèi)存數(shù)據(jù)。由于父進程依然在響應(yīng)命令，因此Redis使用AOF重寫緩沖區(qū)(aof_rewrite_ buf)保存這部分數(shù)據(jù)，防止新AOF文件生成期間丟失這部分數(shù)據(jù)。也就是說，bgrewriteaof執(zhí)行期間，Redis的寫命令同時追加到aof_ buf和aof_rewirte_ buf兩個緩沖區(qū)。 （保證新寫入的數(shù)據(jù)不丟失）

（4）子進程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新的AOF文件。

（5.1）子進程寫完新的AOF文件后，向父進程發(fā)信號，父進程更新統(tǒng)計信息，具體可以通過info persistence查看。

（5.2）父進程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件，這樣就保證了新AOF文件所保存的數(shù)據(jù)庫狀態(tài)和服務(wù)器當前狀態(tài)一致。

（5.3）使用新的AOF文件替換老文件，完成AOF重寫。（替換是原子性的）

 啟動時加載

• 當AOF開啟時，Redis啟動時會優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù)；只有當AOF關(guān)閉時，才會載入RDB文件恢復(fù)數(shù)據(jù)。
• 當AOF開啟，但AOF文件不存在時，即使RDB文件存在也不會加載。
• Redis載入AOF文件時，會對AOF文件進行校驗，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。但如果是AOF文件結(jié)尾不完整（機器突然宕機等容易導(dǎo)致文件尾部不完整），且aof-load-truncated參數(shù)開啟，則日志中會輸出警告，Redis忽略掉AOF文件的尾部，啟動成功。aof-load-truncated參數(shù)默認是開啟的。

三、RDB和AOF的優(yōu)缺點

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

優(yōu)點

RDB文件緊湊，體積小，網(wǎng)絡(luò)傳輸快，適合全量復(fù)制；恢復(fù)速度比AOF快很多。當然，與AOF相比， RDB最重要的優(yōu)點之一是對性能的影響相對較小。

（體積小，恢復(fù)速度更快，對性能影響較小。）

缺點

• RDB文件的致命缺點在于其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實時持久化，而在數(shù)據(jù)越來越重要的今天，數(shù)據(jù)的大量丟失很多時候是無法接受的，因此AOF持久化成為主流。
• 此外，RDB文 件需要滿足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。
• 對于RDB持久化，一方面是bgsave在進行fork操作時Redis主進程會阻塞，另一方面，子進程向硬盤寫數(shù)據(jù)也會帶來IO壓力。

（實時性差、兼容性差、在fork子進程時會阻塞父進程。）

AOF持久化優(yōu)缺點

• 與RDB持久化相對應(yīng)，AOF的優(yōu)點在于支持秒級持久化、實時性好、兼容性好，缺點是文件大、恢復(fù)速度慢、對性能影響大。
• 對于AOF持久化，向硬盤寫數(shù)據(jù)的頻率大大提高（everysec策略下為秒級），IO 壓力更大，甚至可能造成AOF追加阻塞問題。
• AOF文件的重寫與RDB的bgsave類似，會有fork時的阻塞和子進程的 IO 壓力問題。相對來說，由于AOF向硬盤中寫數(shù)據(jù)的頻率更高，因此對Redis主進程性能的影響會更大。

四、Redis性能管理

查看Redis內(nèi)存使用

方式一：進入數(shù)據(jù)庫查看

方法二：命令行查看

內(nèi)存碎片率

內(nèi)存碎片率計算方式

內(nèi)存碎片率=Redis向操作系統(tǒng)申請的內(nèi)存 / Redis中的數(shù)據(jù)占用的內(nèi)存

mem_fragmentation_ratio = used_memory_rss / used_memory

mem_fragmentation_ratio：內(nèi)存碎片率。

used_memory_rss：是Redis向操作系統(tǒng)申請的內(nèi)存。

used_memory：是Redis中的數(shù)據(jù)占用的內(nèi)存。

used_memory_peak：redis內(nèi)存使用的峰值。

內(nèi)存碎片如何產(chǎn)生

• Redis內(nèi)部有自已的內(nèi)存管理器，為了提高內(nèi)存使用的效率，來對內(nèi)存的申請和釋放進行管理。
• Redis中的值刪除的時候，并沒有把內(nèi)存直接釋放、交還給操作系統(tǒng)，而是交給了Redis內(nèi)部有內(nèi)存管理器。
• Redis中申請內(nèi)存的時候，也是先看自己的內(nèi)存管理器中是否有足夠的內(nèi)存可用。
• Redis的這種機制，提高了內(nèi)存的使用率，但是會使Redis中有部分自己沒在用，卻不釋放的內(nèi)存，導(dǎo)致了內(nèi)存碎片的發(fā)生。

跟蹤內(nèi)存碎片率

跟蹤內(nèi)存碎片率，對理解Redis實例的資源性能是非常重要的：

• 內(nèi)存碎片率在1到1.5之間是正常的，這個值表示內(nèi)存碎片率比較低，也說明Redis 沒有發(fā)生內(nèi)存交換。
• 內(nèi)存碎片率超過1.5，說明Redis消耗了實際需要的物理內(nèi)存的150%，其中50%是內(nèi)存碎片率。
• 內(nèi)存碎片率低于1的，說明Redis內(nèi)存分配超出了物理內(nèi)存，操作系統(tǒng)正在進行內(nèi)存交換（使用虛擬內(nèi)存，會降低性能）。需要增加可用物理內(nèi)存或減少Redis內(nèi)存占用。

解決碎片率大的問題

• 如果Redis版本是4.0以下的，需要在redis-cli 工具上輸入shutdown save命令，讓Redis數(shù)據(jù)庫執(zhí)行保存操作并關(guān)閉Redis服務(wù)，再重啟服務(wù)器。Redis服務(wù)器重啟后，Redis 會將沒用的內(nèi)存歸還給操作系統(tǒng)，碎片率會降下來。
• Redis4.0版本開始，可以在不重啟的情況下，線上整理內(nèi)存碎片，將未使用的內(nèi)存歸還給操作系統(tǒng)。

config set activedefrag yes    #自動碎片清理  

memory purge                        #手動碎片清理

內(nèi)存使用率

redis實例的內(nèi)存使用率超過可用最大內(nèi)存，操作系統(tǒng)將開始進行內(nèi)存與swap空間交換。

避免內(nèi)存交換發(fā)生的方法

• 針對緩存數(shù)據(jù)大小選擇安裝Redis實例
• 盡可能的使用Hash數(shù)據(jù)結(jié)構(gòu)存儲
• 設(shè)置key的過期時間 

內(nèi)回收key

內(nèi)存清理策略，保證合理分配redis有限的內(nèi)存資源。

當內(nèi)存使用達到設(shè)置的最大閾值時，需選擇一種key的回收策略，默認情況下回收策略是禁止刪除（noenviction）。

修改 /etc/redis/6379.conf 文件中maxmemory-policy屬性

回收策略

• volatile-lru  #使用LRU算法從已設(shè)置過期時間的數(shù)據(jù)集合中淘汰數(shù)據(jù) （移除最近最少使用的key，針對設(shè)置了TTL的key）  ?
•  volatile-ttl  #從已設(shè)置過期時間的數(shù)據(jù)集合中挑選即將過期的數(shù)據(jù)淘汰 （移除最近過期的key）  ?
• volatile-random  #從已設(shè)置過期時間的數(shù)據(jù)集合中隨機挑選數(shù)據(jù)淘汰 （在設(shè)置了TTL的key里隨機移除）  ?  
• allkeys-lru  #使用LRU算法 從所有數(shù)據(jù)集合中淘汰數(shù)據(jù) （移除最少使用的key，針對所有的key）
• allkeys-random  #從數(shù)據(jù)集合中任意選擇數(shù)據(jù)淘汰（隨機移除key）  ?  
• noenviction  #禁止淘汰數(shù)據(jù)（不刪除直到寫滿時報錯）

五、Redis的優(yōu)化

設(shè)置客戶端連接超時時間

客戶端最大連接數(shù)

自動碎片清理

最大內(nèi)存閥值

key回收策略。

控制key的長度

控制元素的大小

數(shù)據(jù)結(jié)構(gòu)：Redis支持多種數(shù)據(jù)結(jié)構(gòu)，包括字符串、哈希表、列表、集合和有序集合。選擇正確的數(shù)據(jù)結(jié)構(gòu)可以提高性能并減少內(nèi)存使用量。

設(shè)置過期key：強制要求所有的key必須設(shè)置過期時間，以優(yōu)化redis內(nèi)存。

冷熱分離：熱key需要單獨存放并分配合理的資源，防止大流量下直接沖垮整個緩存系統(tǒng)。

數(shù)據(jù)壓縮：可以采用snappy、gzip 等壓縮算法來先將數(shù)據(jù)壓縮后再存入緩存中，來節(jié)約redis的內(nèi)存空間，但這種方法會使客戶端在讀取時還需要解壓縮，在這期間會消耗更多CPU資源，你需要根據(jù)實際情況進行權(quán)衡。建議，只是在redis匱乏時的一種方案。

內(nèi)存淘汰優(yōu)化：杜絕使用默認的內(nèi)存淘汰策略，避免在業(yè)務(wù)擴展下Redis的內(nèi)存持續(xù)膨脹，需要根據(jù)你的業(yè)務(wù)設(shè)置對應(yīng)內(nèi)存淘汰策略。

過期策略優(yōu)化：由于redis采用的是定期刪除+懶加載刪除策略，且這個過程在redis 6.0之前是在主線程上執(zhí)行的，建議所有key的過期時間用隨機數(shù)打散，杜絕大批量的數(shù)據(jù)同時過期，拉胯redis的性能和造成緩存雪崩。強制規(guī)范。

持久化優(yōu)化：Redis支持兩種持久化選項：RDB和AOF。選擇正確的持久化選項可以提高性能并確保數(shù)據(jù)安全。

架構(gòu)優(yōu)化：讀寫分離能最大限度提高redis的性能，其中主庫負責(zé)數(shù)據(jù)寫入，從庫負責(zé)數(shù)據(jù)讀取；分片集群是解決超大量數(shù)據(jù)導(dǎo)致性能瓶頸方案，如rediscluster。以上是在大流量下提高redis性能在架構(gòu)上的優(yōu)化。

lazy-free：在redis4.0+中支持，開啟lazy-free機制后，由主線程刪除bigkey，而較耗時的內(nèi)存釋放會在后臺線程中執(zhí)行，不會影響到主線程。

集群：使用Redis集群：如果Redis服務(wù)器無法滿足性能需求，可以使用Redis集群來擴展Redis服務(wù)器。Redis集群可以將數(shù)據(jù)分片并分布在多個Redis服務(wù)器上，從而提高性能和可擴展性。

使用管道：Redis支持管道操作，可以將多個命令一次性發(fā)送到Redis服務(wù)器，從而減少網(wǎng)絡(luò)延遲。

以上就是Redis高可用之持久化的詳細內(nèi)容，更多關(guān)于Redis持久化的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論