網(wǎng)站宣傳方法有哪些營(yíng)銷方法有哪些方式
目錄
一、理論
1.Redis 高可用
2.Redis持久化
3.RDB持久化
?4.AOF持久化（支持秒級(jí)寫入）
5.RDB和AOF的優(yōu)缺點(diǎn)
6.RDB和AOF對(duì)比
7.Redis性能管理
8.Redis的優(yōu)化
二、實(shí)驗(yàn)
1.RDB持久化
2.AOF持久化
3.Redis性能管理
4.Redis的優(yōu)化
三、總結(jié)
一、理論
1.Redis 高可用
（1）概念
在web服務(wù)器中，高可用是指服務(wù)器可以正常訪問的時(shí)間，衡量的標(biāo)準(zhǔn)是在多長(zhǎng)時(shí)間內(nèi)可以提供正常服務(wù)(99.9%、99.99%、99.999%等等)。
但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(wù)( 如主從分離、快速容災(zāi)技術(shù))，還需要考慮數(shù)據(jù)容量的擴(kuò)展、數(shù)據(jù)安全不會(huì)丟失等。
?
（2）Redis的高可用技術(shù)
在Redis中，實(shí)現(xiàn)高可用的技術(shù)主要包括持久化、主從復(fù)制、哨兵和cluster集群，下面分別說明它們的作用，以及解決了什么樣的問題。
①持久化： 持久化是最簡(jiǎn)單的高可用方法（有時(shí)甚至不被歸為高可用的手段），主要作用是數(shù)據(jù)備份，即將數(shù)據(jù)存儲(chǔ)在硬盤，保證數(shù)據(jù)不會(huì)因進(jìn)程退出而丟失。
②主從復(fù)制： 主從復(fù)制是高可用Redis的基礎(chǔ)，哨兵和集群都是在主從復(fù)制基礎(chǔ)上實(shí)現(xiàn)高可用的。主從復(fù)制主要實(shí)現(xiàn)了數(shù)據(jù)的多機(jī)備份（和同步），以及對(duì)于讀操作的負(fù)載均衡和簡(jiǎn)單的故障恢復(fù)。
缺陷：故障恢復(fù)無法自動(dòng)化；寫操作無法負(fù)載均衡；存儲(chǔ)能力受到單機(jī)的限制。
③哨兵： 在主從復(fù)制的基礎(chǔ)上，哨兵實(shí)現(xiàn)了自動(dòng)化的故障恢復(fù)。（主掛了，找一個(gè)從成為新的主，哨兵節(jié)點(diǎn)進(jìn)行監(jiān)控）
缺陷： 寫操作無法負(fù)載均衡；存儲(chǔ)能力受到單機(jī)的限制。
④Cluster集群： 通過集群，Redis解決了寫操作無法負(fù)載均衡，以及存儲(chǔ)能力受到單機(jī)限制的問題，實(shí)現(xiàn)了較為完善的高可用方案。（6臺(tái)起步，成雙成對(duì)，3主3從）
2.Redis持久化
（1）持久化的功能
①?持久化的功能： Redis是內(nèi)存數(shù)據(jù)庫(kù)，數(shù)據(jù)都是存儲(chǔ)在內(nèi)存中，為了避免服務(wù)器斷電等原因?qū)е翿edis進(jìn)程異常退出后數(shù)據(jù)的永久丟失，需要定期將Redis中的數(shù)據(jù)以某種形式（數(shù)據(jù)或命令）從內(nèi)存保存到硬盤；當(dāng)下次Redis重啟時(shí)，利用持久化文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。除此之外，為了進(jìn)行災(zāi)難備份，可以將持久化文件拷貝到一個(gè)遠(yuǎn)程位置。
②?災(zāi)難備份： 一般做異地備份，發(fā)生災(zāi)難后切換節(jié)點(diǎn)。例如本來使用上海的數(shù)據(jù)庫(kù)，現(xiàn)在使用切換到重慶的。
（2）兩種持久化方式
①?RDB持久化：原理是將Reids在內(nèi)存中的數(shù)據(jù)庫(kù)記錄定時(shí)保存到磁盤上。（定時(shí)對(duì)內(nèi)存中的數(shù)據(jù)生成快照，以文件形式保存在硬盤中）
②?AOF持久化（append only file）：原理是將Reids 的操作日志以追加的方式寫入文件，類似于MySQL的binlog。（類似于Mysql的二進(jìn)制日志）（以追加的方式將寫和刪的操作命令記錄到AOF文件中）
由于AOF持久化的實(shí)時(shí)性更好，即當(dāng)進(jìn)程意外退出時(shí)丟失的數(shù)據(jù)更少，因此AOF是目前主流的持久化方式，不過RDB持 久化仍然有其用武之地。（RDB體積小，恢復(fù)速度更快。對(duì)性能影響較小。）
3.RDB持久化
（1）概念
RDB持久化是指在指定的時(shí)間間隔內(nèi)將內(nèi)存中當(dāng)前進(jìn)程中的數(shù)據(jù)生成快照保存到硬盤（因此也稱作快照持久化），用二進(jìn)制壓縮存儲(chǔ)，保存的文件后綴是rdb；當(dāng)Redis重新啟動(dòng)時(shí)，可以讀取快照文件恢復(fù)數(shù)據(jù)。
在 Redis 運(yùn)行時(shí)， RDB 將當(dāng)前內(nèi)存中的數(shù)據(jù)庫(kù)生成一個(gè) Snapshot 快照保存到磁盤文件中， 在 Redis 重啟動(dòng)時(shí)， RDB 可以通過載入 RDB 文件來還原數(shù)據(jù)庫(kù)的狀態(tài)。
（2）觸發(fā)條件
?RDB持久化的觸發(fā)分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)兩種。
①手動(dòng)觸發(fā)
1）save命令和bgsave命令都可以生成RDB文件。
2）save命令會(huì)阻塞Redis服務(wù)器進(jìn)程，直到RDB文件創(chuàng)建完畢為止，在Redis服務(wù)器阻塞期間，服務(wù)器不能處理任何命令請(qǐng)求。
而bgsave命令會(huì)創(chuàng)建一個(gè)子進(jìn)程，由子進(jìn)程來負(fù)責(zé)創(chuàng)建RDB文件，父進(jìn)程（即Redis主進(jìn)程）則繼續(xù)處理請(qǐng)求。
3）bgsave命令執(zhí)行過程中，只有fork子進(jìn)程時(shí)會(huì)阻塞服務(wù)器，而對(duì)于save命令，整個(gè)過程都會(huì)阻塞服務(wù)器，因此save已基本被廢棄，線上環(huán)境要杜絕save的使用。
?
區(qū)別如下：
②自動(dòng)觸發(fā)
在自動(dòng)觸發(fā)RDB持久化時(shí)，Redis 也會(huì)選擇bgsave而不是save來進(jìn)行持久化。
自動(dòng)觸發(fā)最常見的情況是在配置文件中通過 save m n 指定當(dāng)m秒內(nèi)發(fā)生n次變化時(shí)，會(huì)觸發(fā)bgsave。
vim /etc/redis/6379.conf #編輯配置文件?----219行--以下三個(gè)save條件滿足任意一一個(gè)時(shí)，都會(huì)引起bgsave的調(diào)用save 900 1 #當(dāng)時(shí)間到900秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsavesave 300 10 #當(dāng)時(shí)間到300秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少10次變化，則執(zhí)行bgsavesave 60 10000 #當(dāng)時(shí)間到60秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少10000次變化， 則執(zhí)行bgsave?----242行--是否開啟RDB文件壓縮rdbcompression yes?----254行--指定RDB文件名dbfilename dump.rdb?----264行--指定RDB文件和AOF文件所在目錄dir /var/lib/redis/6379
由此可看出RDB持久化的問題：
實(shí)時(shí)性不夠，最快也要60秒備份一次，如果50多秒時(shí)服務(wù)器宕機(jī)，則備份失敗。
③?其他自動(dòng)觸發(fā)機(jī)制
除了savemn以外，還有一些其他情況會(huì)觸發(fā)bgsave：
1）在主從復(fù)制場(chǎng)景下，如果從節(jié)點(diǎn)執(zhí)行全量復(fù)制操作，則主節(jié)點(diǎn)會(huì)執(zhí)行bgsave命令，并將rdb文件發(fā)送給從節(jié)點(diǎn)。
2）執(zhí)行shutdown命令時(shí)，自動(dòng)執(zhí)行rdb持久化。
（3）bgsave執(zhí)行流程
①Redis父進(jìn)程首先判斷：當(dāng)前是否在執(zhí)行save，或 bgsave/ bgrewriteaof 的子進(jìn)程，如果在執(zhí)行則bgsave命令直接返回。
bgsave/bgrewriteaof 的子進(jìn)程不能同時(shí)執(zhí)行，主要是基于性能方面的考慮：兩個(gè)并發(fā)的子進(jìn)程同時(shí)執(zhí)行大量的磁盤寫操作，可能引起嚴(yán)重的性能問題。
②父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個(gè)過程中父進(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)存快照生成臨時(shí)快照文件，完成后對(duì)原有文件進(jìn)行原子替換。（原子替換：文件整體替換，要么都發(fā)生，要么都不發(fā)生）
⑤子進(jìn)程發(fā)送信號(hào)給父進(jìn)程表示完成，父進(jìn)程更新統(tǒng)計(jì)信息。
（4）啟動(dòng)時(shí)加載
①?RDB文件的載入工作是在服務(wù)器啟動(dòng)時(shí)自動(dòng)執(zhí)行的，并沒有專門的命令。但是由于AOF的優(yōu)先級(jí)更高，因此當(dāng)AOF開啟時(shí)，Redis會(huì)優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù)；只有當(dāng)AOF關(guān)閉時(shí)，才會(huì)在Redis服務(wù)器啟動(dòng)時(shí)檢測(cè)RDB文件，并自動(dòng)載入。 服務(wù)器載入RDB文件期間處于阻塞狀態(tài)，直到載入完成為止。
②?Redis載入RDB文件時(shí)，會(huì)對(duì)RDB文件進(jìn)行校驗(yàn)，如果文件損壞，則日志中會(huì)打印錯(cuò)誤，Redis啟動(dòng)失敗。
?4.AOF持久化（支持秒級(jí)寫入）
（1）概念
①?RDB持久化是將進(jìn)程數(shù)據(jù)寫入文件，而AOF持久化，則是將Redis執(zhí)行的每次寫、刪除命令記錄到單獨(dú)的日志文件中，查詢操作不會(huì)記錄。
②?當(dāng)Redis重啟時(shí)再次執(zhí)行AOF文件中的命令來恢復(fù)數(shù)據(jù)。（重放命令進(jìn)行恢復(fù)）
③?與RDB相比，AOF的實(shí)時(shí)性更好，?因此已成為主流的持久化方案。
?（2）開啟AOF
Redis服務(wù)器默認(rèn)開啟RDB，關(guān)閉AOF的， 要開啟AOF，需要在?/etc/redis/6379.conf?配置文件中配置。
vim /etc/redis/6379.conf----700行---修改，開啟AOFappendonly yes----704行---指定AOF文件名稱appendfilename "appendonly.aof"----796行---是否忽略最后一條可能存在問題的指令aof-load-truncated yes #Redis恢復(fù)時(shí)，發(fā)現(xiàn)AOF文件的末尾被截?cái)嗔?#xff0c;會(huì)忽略最后一條可能存在問題的指令。默認(rèn)值yes。即在aof寫入時(shí)，可能發(fā)生redis機(jī)器運(yùn)行崩潰，AOF文件的末尾被截?cái)嗔?#xff0c;這種情況下，yes會(huì)繼續(xù)執(zhí)行并恢復(fù)盡量多的數(shù)據(jù)，而no會(huì)直接恢復(fù)失敗報(bào)錯(cuò)退出。??/etc/init.d/redis_6379 restart #重啟redisls /var/lib/redis/6379/ #查看是否生成了aof文件
（3）執(zhí)行流程
由于需要記錄Redis的每條寫命令，因此AOF不需要觸發(fā)，下面介紹AOF的執(zhí)行流程。
AOF的執(zhí)行流程包括：
表1?AOF的執(zhí)行流程
| 序號(hào) | 流程 | 描述 |
| 1 | 命令追加（append） | 將Redis的寫 命令追加到緩沖區(qū)aof_ buf |
| 2 | 文件寫入（write）和文件同步（sync） | 根據(jù)不同的同步策略將aof_buf中的內(nèi)容同步到硬盤 |
| 3 | 文件重寫（rewrite） | 定期重寫AOF文件，達(dá)到壓縮的目的。（將過期數(shù)據(jù)、無效命令、多條命令，進(jìn)行壓縮或刪除） |
?①?命令追加(append)
1）Redis先將寫命令追加到緩沖區(qū)，而不是直接寫入文件，主要是為了避免每次有寫命令都直接寫入硬盤，導(dǎo)致硬盤IO成為Redis負(fù)載的瓶頸。
2）命令追加的格式是Redis命令請(qǐng)求的協(xié)議格式，它是一種純文本格式，具有兼容性好、可讀性強(qiáng)、容易處理、操作簡(jiǎn)單避免二次開銷等優(yōu)點(diǎn)。
3）在AOF文件中，除了用于指定數(shù)據(jù)庫(kù)的select命令（如select 0為選中0號(hào)數(shù)據(jù)庫(kù)）是由Redis添加的， 其他都是客戶端發(fā)送來的寫命令。
②?文件寫入(write)和文件同步(sync)
Redis提供了多種AOF緩存區(qū)的同步文件策略，策略涉及到操作系統(tǒng)的write函數(shù)和fsync函數(shù)，說明如下：
1）為了提高文件寫入效率，在現(xiàn)代操作系統(tǒng)中，當(dāng)用戶調(diào)用write函數(shù)將數(shù)據(jù)寫入文件時(shí)，操作系統(tǒng)通常會(huì)將數(shù)據(jù)暫存到一個(gè)內(nèi)存緩沖區(qū)里，當(dāng)緩沖區(qū)被填滿或超過了指定時(shí)限后，才真正將緩沖區(qū)的數(shù)據(jù)寫入到硬盤里。
2）這樣的操作雖然提高了效率，但也帶來了安全問題：如果計(jì)算機(jī)停機(jī)，內(nèi)存緩沖區(qū)中的數(shù)據(jù)會(huì)丟失。因此系統(tǒng)同時(shí)提供了fsync、fdatasync等同步函數(shù)，可以強(qiáng)制操作系統(tǒng)立刻將緩沖區(qū)中的數(shù)據(jù)寫入到硬盤里，從而確保數(shù)據(jù)的安全性。
?
AOF緩存區(qū)的同步文件策略存在三種同步方式，它們分別是：
表2?AOF緩存區(qū)的同步文件策略
| 序號(hào) | 策略 | 描述 |
| 1 | appendfsync always | 命令寫入aof_buf后立即調(diào)用系統(tǒng)fsync操作同步到AOF文件。安全性高，性能低。 |
| 2 | appendfsync no | 當(dāng)緩沖區(qū)被填滿或超過了指定時(shí)限后（默認(rèn)30秒），才將緩沖區(qū)的數(shù)據(jù)寫入到硬盤里。性能高，但安全性低。 |
| 3 | appendfsync everysec | 每秒同步一次，是性能和數(shù)據(jù)安全性的平衡，因此是Redis的默認(rèn)配置。 |
vim /etc/redis/6379.conf----729行----729 # appendfsync always730 appendfsync everysec731 # appendfsync no?------------------------以下是注釋----------------------------------------------------● appendfsync always:#命令寫入aof_buf后立即調(diào)用系統(tǒng)fsync操作同步到AOF文件，fsync完成后線程返回。這種情況下，每次有寫命令都要同步到AOF文件，硬盤IO成為性能瓶頸，Redis只能支持大約幾百TPS寫入，嚴(yán)重降低了Redis的性能；即便是使用固態(tài)硬盤(SSD) ，每秒大約也只能處理幾萬個(gè)命令，而且會(huì)大大降低SSD的壽命。（安全性高，性能低。）?● appendfsync no:#命令寫入aof_buf后調(diào)用系統(tǒng)write操作，不對(duì)AOF文件做fsync同步；同步由操作系統(tǒng)負(fù)責(zé)，通常同步周期為30秒。這種情況下，文件同步的時(shí)間不可控，且緩沖區(qū)中堆積的數(shù)據(jù)會(huì)很多，數(shù)據(jù)安全性無法保證。（當(dāng)緩沖區(qū)被填滿或超過了指定時(shí)限后，才將緩沖區(qū)的數(shù)據(jù)寫入到硬盤里。性能高，但安全性低。）?● appendfsync everysec:#命令寫入aof_buf后調(diào)用系統(tǒng)write操作，write完成后線程返回; fsync同步文件操作由專門的線程每秒調(diào)用一次。everysec是前述兩種策略的折中，是性能和數(shù)據(jù)安全性的平衡，因此是Redis的默認(rèn)配置，也是我們推薦的配置。（同時(shí)保證了數(shù)據(jù)安全和性能的需求）
【1】always: 每次寫入一條數(shù)據(jù)就立即將這個(gè)數(shù)據(jù)對(duì)應(yīng)的寫日志 fsync 到磁盤上去，雖然可以確保 Redis 里的數(shù)據(jù)一條都不丟，但是性能非常差，吞吐量很低。
【2】everysec：每秒將緩沖中的數(shù)據(jù) fsync 到磁盤，這個(gè)比較最常用的，生產(chǎn)環(huán)境一般都這么配置，而且性能很高。但是缺點(diǎn)就是不像 always 那樣保證每個(gè)命令都會(huì)記錄，Redis 服務(wù)器出現(xiàn)故障有可能會(huì)丟失一秒鐘的數(shù)據(jù)。
【3】no: 僅僅 redis 負(fù)責(zé)將數(shù)據(jù)寫入緩沖區(qū)，什么時(shí)候刷新到磁盤中是根據(jù)操作系統(tǒng)自己決定。這種一般不會(huì)使用。
【4】三種策略對(duì)比
③文件重寫(rewrite)
1)? ?概念
【1】隨著時(shí)間流逝，Redis服務(wù)器執(zhí)行的寫命令越來越多，AOF文件也會(huì)越來越大；過大的AOF文件不僅會(huì)影響服務(wù)器的正常運(yùn)行，也會(huì)導(dǎo)致數(shù)據(jù)恢復(fù)需要的時(shí)間過長(zhǎng)。
【2】文件重寫是指定期重寫AOF文件，減小AOF文件的體積。需要注意的是，AOF 重寫是把Redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令，同步到新的AOF文件；不會(huì)對(duì)舊的AOF文件進(jìn)行任何讀取、寫入操作！
【3】關(guān)于文件重寫需要注意的另一點(diǎn)是：對(duì)于AOF持久化來說，文件重寫雖然是強(qiáng)烈推薦的，但并不是必須的；即使沒有文件重寫，數(shù)據(jù)也可以被持久化并在Redis啟動(dòng)的時(shí)候?qū)?。因此在一些現(xiàn)實(shí)中，會(huì)關(guān)閉自動(dòng)的文件重寫，然后通過定時(shí)任務(wù)在每天的某一時(shí)刻定時(shí)執(zhí)行。
?
注意：
重寫會(huì)消耗性能，影響業(yè)務(wù)，不能在業(yè)務(wù)高峰期進(jìn)行重寫。所以一般會(huì)關(guān)閉自動(dòng)重寫，由定時(shí)任務(wù)在每天的某一時(shí)刻定時(shí)執(zhí)行重寫功能。
2）文件重寫能夠壓縮AOF文件
原因在于：
表3 重寫壓縮AOF文件
| 序號(hào) | 原因 |
| 1 | 過期的數(shù)據(jù)不再寫入文件。 |
| 2 | 無效的命令不再寫入文件：如有些數(shù)據(jù)被重復(fù)設(shè)值（set mykey v1, set mykey v2）、 有些數(shù)據(jù)被刪除了（set myset vl, del myset）等。 |
| 3 | 多條命令可以合并為一個(gè)：如sadd myset v1, sadd myset v2, sadd myset v3可以合并為sadd myset v1 v2 v3。（sadd添加集合） |
rewrite之后aof文件會(huì)保存keys的最后狀態(tài)，清除掉之前冗余的，來縮小這個(gè)文件。
通過上述內(nèi)容可以看出，由于重寫后AOF執(zhí)行的命令減少了，文件重寫既可以減少文件占用的空間，也可以加快恢復(fù)速度。
3）文件重寫的觸發(fā)
分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)：
表4? 文件重寫觸發(fā)
| 序號(hào) | 除法類型 | 描述 |
| 1 | 手動(dòng)觸發(fā) | 直接調(diào)用bgrewriteaof命令，該命令的執(zhí)行與bgsave有些類似：都是fork子進(jìn)程進(jìn)行具體的工作，且都只有在fork時(shí)阻塞。 |
| 2 | 自動(dòng)觸發(fā) | 通過設(shè)置auto-aof-rewrite-min-size選項(xiàng)和auto-aof-rewrite-percentage選項(xiàng)來自動(dòng)執(zhí)行BGREWRITEAOF。 只有當(dāng)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個(gè)選項(xiàng)同時(shí)滿足時(shí)，才會(huì)自動(dòng)觸發(fā)AOF重寫，即bgrewriteaof操作。 |
vim /etc/redis/6379.conf----771行----771 auto-aof-rewrite-percentage 100772 auto-aof-rewrite-min-size 64mb?-----------------------以下是注釋--------------------------------● auto-aof-rewrite-percentage 100 #文件的大小超過基準(zhǔn)百分之多少后觸發(fā)bgrewriteaof。默認(rèn)這個(gè)值設(shè)置為100，意味著當(dāng)前aof是基準(zhǔn)大小的兩倍的時(shí)候觸發(fā)bgrewriteaof。把它設(shè)置為0可以禁用自動(dòng)觸發(fā)的功能。#即當(dāng)前AOF文件大小(即aof_current_size)是上次日志重寫時(shí)AOF文件大小(aof_base_size)兩倍時(shí)，發(fā)生BGREWRITEAOF操作。#注意：例如上次文件達(dá)到100M進(jìn)行重寫，那么這次需要達(dá)到200M時(shí)才進(jìn)行重寫。文件需要越來越大，所以一般不使用自動(dòng)重寫。如果使用自動(dòng)重寫，需要定期手動(dòng)重寫干預(yù)一次，讓文件要求恢復(fù)到100M。?● auto-aof-rewrite-min-size 64mb #當(dāng)文件大于64M時(shí)才會(huì)進(jìn)行重寫#當(dāng)前aof文件大于多少字節(jié)后才觸發(fā)。#當(dāng)前AOF文件執(zhí)行BGREWRITEAOF命令的最小值，避免剛開始啟動(dòng)Reids時(shí)由于文件尺寸較小導(dǎo)致頻繁的BGREWRITEAOF
4）關(guān)于文件重寫的流程有兩點(diǎn)需要特別注意：
【1】重寫由父進(jìn)程fork子進(jìn)程進(jìn)行。
【2】重寫期間Redis執(zhí)行的寫命令，需要追加到新的AOF文件中，為此Redis引入了aof_rewrite_buf緩存。
5）文件重寫的流程如下
表5 文件重寫流程
| 序號(hào) | 詳細(xì)流程 |
| （1） | Redis父進(jìn)程首先判斷當(dāng)前是否存在正在執(zhí)行bgsave/bgrewriteaof的子進(jìn)程，如果存在則bgrewriteaof命令直接返回，如果存在bgsave命令則等bgsave執(zhí)行完成后再執(zhí)行。（正常情況下使用AOF就會(huì)使用AOF進(jìn)行記錄，不會(huì)使用RDB。主從復(fù)制時(shí)會(huì)自動(dòng)觸發(fā)bgsave命令） ? |
| （2） | 父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個(gè)過程中父進(jìn)程是阻塞的（無法接受任何客戶端的請(qǐng)求）。 |
| （3.1） | 父進(jìn)程fork后，bgrewriteaof 命令返回"Background append only file rewrite started" 信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令。Redis的所有寫命令依然寫入AOF緩沖區(qū)，并根據(jù)appendfsync策略同步到硬盤，保證原有AOF機(jī)制的正確。 |
| （3.2） | 由于fork操作使用寫時(shí)復(fù)制技術(shù)，子進(jìn)程只能共享fork操作時(shí)的內(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的寫命令同時(shí)追加到aof_ buf和aof_rewirte_ buf兩個(gè)緩沖區(qū)。（保證新寫入的數(shù)據(jù)不丟失） |
| （4） | 子進(jìn)程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新的AOF文件。 |
| （5.1） | 子進(jìn)程寫完新的AOF文件后，向父進(jìn)程發(fā)信號(hào)，父進(jìn)程更新統(tǒng)計(jì)信息，具體可以通過info persistence查看。 |
| （5.2） | 父進(jìn)程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件，這樣就保證了新AOF文件所保存的數(shù)據(jù)庫(kù)狀態(tài)和服務(wù)器當(dāng)前狀態(tài)一致。 |
| （5.3） | 使用新的AOF文件替換老文件，完成AOF重寫。（替換是原子性的） |
?（4）啟動(dòng)時(shí)加載
①?當(dāng)AOF開啟時(shí)，Redis啟動(dòng)時(shí)會(huì)優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù)；只有當(dāng)AOF關(guān)閉時(shí)，才會(huì)載入RDB文件恢復(fù)數(shù)據(jù)。
②?當(dāng)AOF開啟，但AOF文件不存在時(shí)，即使RDB文件存在也不會(huì)加載。
③?Redis載入AOF文件時(shí)，會(huì)對(duì)AOF文件進(jìn)行校驗(yàn)，如果文件損壞，則日志中會(huì)打印錯(cuò)誤，Redis啟動(dòng)失敗。但如果是AOF文件結(jié)尾不完整（機(jī)器突然宕機(jī)等容易導(dǎo)致文件尾部不完整），且aof-load-truncated參數(shù)開啟，則日志中會(huì)輸出警告，Redis忽略掉AOF文件的尾部，啟動(dòng)成功。aof-load-truncated參數(shù)默認(rèn)是開啟的。
5.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)之一是對(duì)性能的影響相對(duì)較小。（體積小，恢復(fù)速度更快，對(duì)性能影響較小。）
②?缺點(diǎn)：
RDB文件的致命缺點(diǎn)在于其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實(shí)時(shí)持久化，而在數(shù)據(jù)越來越重要的今天，數(shù)據(jù)的大量丟失很多時(shí)候是無法接受的，因此AOF持久化成為主流。
此外，RDB文 件需要滿足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。
對(duì)于RDB持久化，一方面是bgsave在進(jìn)行fork操作時(shí)Redis主進(jìn)程會(huì)阻塞，另一方面，子進(jìn)程向硬盤寫數(shù)據(jù)也會(huì)帶來IO壓力。
（實(shí)時(shí)性差、兼容性差、在fork子進(jìn)程時(shí)會(huì)阻塞父進(jìn)程。）
?
（2）?AOF持久化的優(yōu)缺點(diǎn)
①?與RDB持久化相對(duì)應(yīng)，AOF的優(yōu)點(diǎn)在于支持秒級(jí)持久化、實(shí)時(shí)性好、兼容性好，缺點(diǎn)是文件大、恢復(fù)速度慢、對(duì)性能影響大。
②?對(duì)于AOF持久化，向硬盤寫數(shù)據(jù)的頻率大大提高（everysec策略下為秒級(jí)），IO壓力更大，甚至可能造成AOF追加阻塞問題。
③?AOF文件的重寫與RDB的bgsave類似，會(huì)有fork時(shí)的阻塞和子進(jìn)程的Io壓力問題。相對(duì)來說，由于AOF向硬盤中寫數(shù)據(jù)的頻率更高，因此對(duì)Redis主進(jìn)程性能的影響會(huì)更大。
6.RDB和AOF對(duì)比
（1）持久化對(duì)比
表6 持久化對(duì)比
| RDB持久化 | AOF持久化 |
|---|---|
| 全量備份，一次保存整個(gè)數(shù)據(jù)庫(kù)。 | 增量備份，一次只保存一個(gè)修改數(shù)據(jù)庫(kù)的命令。 |
| 每次執(zhí)行持久化操作的間隔時(shí)間較長(zhǎng)。 | 保存的間隔默認(rèn)為一秒鐘（Everysec） |
| 數(shù)據(jù)保存為二進(jìn)制格式，其還原速度快。 | 使用文本格式還原數(shù)據(jù)，所以數(shù)據(jù)還原速度一般。 |
| 執(zhí)行 SAVE 命令時(shí)會(huì)阻塞服務(wù)器，但手動(dòng)或者自動(dòng)觸發(fā)的 BGSAVE 不會(huì)阻塞服務(wù)器 | AOF持久化無論何時(shí)都不會(huì)阻塞服務(wù)器。 |
7.Redis性能管理
（1）查看Redis內(nèi)存使用
方法一：進(jìn)入redis數(shù)據(jù)庫(kù)查看redis-cli127.0.0.1:6379> info memory?方法二：命令行查看redis-cli info memory | grep ratio
（2）內(nèi)存碎片
①?內(nèi)存碎片率如何計(jì)算：
內(nèi)存碎片率=Redis向操作系統(tǒng)申請(qǐ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)申請(qǐng)的內(nèi)存。
used_memory：是Redis中的數(shù)據(jù)占用的內(nèi)存。
used_memory_peak：redis內(nèi)存使用的峰值。
?
②內(nèi)存碎片產(chǎn)生原因
1） Redis內(nèi)部有自已的內(nèi)存管理器，為了提高內(nèi)存使用的效率，來對(duì)內(nèi)存的申請(qǐng)和釋放進(jìn)行管理。
2） Redis中的值刪除的時(shí)候，并沒有把內(nèi)存直接釋放、交還給操作系統(tǒng)，而是交給了Redis內(nèi)部有內(nèi)存管理器。
3） Redis中申請(qǐng)內(nèi)存的時(shí)候，也是先看自己的內(nèi)存管理器中是否有足夠的內(nèi)存可用。
4） Redis的這種機(jī)制，提高了內(nèi)存的使用率，但是會(huì)使Redis中有部分自己沒在用，卻不釋放的內(nèi)存，導(dǎo)致了內(nèi)存碎片的發(fā)生。
③跟蹤內(nèi)存碎片率
跟蹤內(nèi)存碎片率，對(duì)理解Redis實(shí)例的資源性能是非常重要的：
1） 內(nèi)存碎片率在1到1.5之間是正常的，這個(gè)值表示內(nèi)存碎片率比較低，也說明Redis 沒有發(fā)生內(nèi)存交換。
2） 內(nèi)存碎片率超過1.5，說明Redis消耗了實(shí)際需要的物理內(nèi)存的150%，其中50%是內(nèi)存碎片率。
3）內(nèi)存碎片率低于1的，說明Redis內(nèi)存分配超出了物理內(nèi)存，操作系統(tǒng)正在進(jìn)行內(nèi)存交換（使用虛擬內(nèi)存，會(huì)降低性能）。需要增加可用物理內(nèi)存或減少Redis內(nèi)存占用。
?
④?解決碎片率大的問題
1） 如果你的Redis版本是4.0以下的，需要在redis-cli 工具上輸入shutdown save命令，讓Redis數(shù)據(jù)庫(kù)執(zhí)行保存操作并關(guān)閉Redis服務(wù)，再重啟服務(wù)器。Redis服務(wù)器重啟后，Redis 會(huì)將沒用的內(nèi)存歸還給操作系統(tǒng)，碎片率會(huì)降下來。
2） Redis4.0版本開始，可以在不重啟的情況下，線上整理內(nèi)存碎片，將未使用的內(nèi)存歸還給操作系統(tǒng)。
?
config set activedefrag yes #自動(dòng)碎片清理memory purge #手動(dòng)碎片清理
（3）內(nèi)存使用率
redis實(shí)例的內(nèi)存使用率超過可用最大內(nèi)存，操作系統(tǒng)將開始進(jìn)行內(nèi)存與swap空間交換。
1）避免內(nèi)存交換發(fā)生的方法：
【1】針對(duì)緩存數(shù)據(jù)大小選擇安裝Redis 實(shí)例
【2】盡可能的使用Hash數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)
【3】設(shè)置key的過期時(shí)間
2） 內(nèi)回收key
內(nèi)存清理策略，保證合理分配redis有限的內(nèi)存資源。
當(dāng)內(nèi)存使用達(dá)到設(shè)置的最大閥值時(shí)，需選擇一種key的回收策略，默認(rèn)情況下回收策略是禁止刪除（noenviction）。
配置文件中修改 maxmemory-policy 屬性值：
vim /etc/redis/6379.conf---599行----maxmemory-policy noenviction #修改max-memory-policy屬性值?##回收策略有以下幾種：##●volatile-lru#使用LRU算法從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中淘汰數(shù)據(jù)（移除最近最少使用的key，針對(duì)設(shè)置了TTL的key）?●volatile-ttl#從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中挑選即將過期的數(shù)據(jù)淘汰（移除最近過期的key）?●volatile-random#從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中隨機(jī)挑選數(shù)據(jù)淘汰（在設(shè)置了TTL的key里隨機(jī)移除）?●allkeys-lru#使用LRU算法 從所有數(shù)據(jù)集合中淘汰數(shù)據(jù)（移除最少使用的key，針對(duì)所有的key）?●allkeys-random#從數(shù)據(jù)集合中任意選擇數(shù)據(jù)淘汰（隨機(jī)移除key）?●noenviction#禁止淘汰數(shù)據(jù)（不刪除直到寫滿時(shí)報(bào)錯(cuò)）
8.Redis的優(yōu)化
設(shè)置客戶端連接超時(shí)時(shí)間、客戶端最大連接數(shù)、自動(dòng)碎片清理、最大內(nèi)存閥值、key回收策略。
（1）設(shè)置Redis客戶端連接的超時(shí)時(shí)間
vim /etc/redis/6379.conf-----114行------114 timeout 0 #單位為秒（s），取值范圍為0~100000。默認(rèn)值為0，表示無限制，即Redis不會(huì)主動(dòng)斷開連接，即使這個(gè)客戶端已經(jīng)空閑了很長(zhǎng)時(shí)間。#例如可設(shè)置為600，則客戶端空閑10分鐘后，Redis會(huì)主動(dòng)斷開連接。?#注意：在實(shí)際運(yùn)行中，為了提高性能，Redis不一定會(huì)精確地按照timeout的值規(guī)定的時(shí)間來斷開符合條件的空閑連接，例如設(shè)置timeout為10s，但空閑連接可能在12s后，服務(wù)器中新增很多連接時(shí)才會(huì)被斷開。
（2）設(shè)置 redis客戶端最大連接數(shù)
1）redis客戶端最大連接數(shù)默認(rèn)為10000。
vim /etc/redis/6379.conf-----540行------540 # maxclients 10000 #若不設(shè)置，默認(rèn)是10000
2）查看 redis 當(dāng)前連接數(shù)：
[root@localhost ~]# redis-cli127.0.0.1:6379> info clients #查看redis當(dāng)前連接數(shù)# Clientsconnected_clients:1 #redis當(dāng)前連接數(shù)的為1 client_recent_max_input_buffer:2client_recent_max_output_buffer:0blocked_clients:0
3）查看 redis 允許的最大連接數(shù)：
127.0.0.1:6379> config get maxclients1) "maxclients" 2) "10000" #redis允許的最大連接數(shù)默認(rèn)為10000
（3）設(shè)置redis自動(dòng)碎片清理
config set activedefrag yes #自動(dòng)碎片清理memory purge #手動(dòng)碎片清理
（4）設(shè)置redis最大內(nèi)存閥值
內(nèi)存閥值如果不設(shè)置，則沒有限制，直到把服務(wù)器的內(nèi)存干滿、之后會(huì)使用交換分區(qū)。
設(shè)置內(nèi)存閥值后，不會(huì)使用swap交換分區(qū)。且如果設(shè)置了key回收策略，當(dāng)內(nèi)存使用達(dá)到設(shè)置的最大閥值時(shí)，系統(tǒng)會(huì)進(jìn)行key回收。
vim /etc/redis/6379.conf-----567行------567 # maxmemory <bytes>568 maxmemory 1gb #例如設(shè)置最大內(nèi)存閥值為1gb
（5）設(shè)置key回收策略
當(dāng)內(nèi)存使用達(dá)到設(shè)置的最大閥值時(shí)，需選擇一種key的回收策略，默認(rèn)情況下回收策略是禁止刪除（noenviction）。
設(shè)置key回收策略后，則當(dāng)redis內(nèi)存使用達(dá)到設(shè)置的最大閥值時(shí)，系統(tǒng)會(huì)進(jìn)行key回收，釋放一部分內(nèi)存。
vim /etc/redis/6379.conf---599行----maxmemory-policy noenviction #需要修改max-memory-policy屬性值?##回收策略有以下幾種：##●volatile-lru#使用LRU算法從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中淘汰數(shù)據(jù)（移除最近最少使用的key，針對(duì)設(shè)置了TTL的key）?●volatile-ttl#從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中挑選即將過期的數(shù)據(jù)淘汰（移除最近過期的key）?●volatile-random#從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中隨機(jī)挑選數(shù)據(jù)淘汰（在設(shè)置了TTL的key里隨機(jī)移除）?●allkeys-lru#使用LRU算法 從所有數(shù)據(jù)集合中淘汰數(shù)據(jù)（移除最少使用的key，針對(duì)所有的key）?●allkeys-random#從數(shù)據(jù)集合中任意選擇數(shù)據(jù)淘汰（隨機(jī)移除key）?●noenviction#禁止淘汰數(shù)據(jù)（不刪除直到寫滿時(shí)報(bào)錯(cuò)）
二、實(shí)驗(yàn)
1.RDB持久化
（1）自動(dòng)觸發(fā)
在自動(dòng)觸發(fā)RDB持久化時(shí)，Redis 也會(huì)選擇bgsave而不是save來進(jìn)行持久化。
自動(dòng)觸發(fā)最常見的情況是在配置文件中通過?save m n?指定當(dāng)m秒內(nèi)發(fā)生n次變化時(shí)，會(huì)觸發(fā)bgsave。
當(dāng)時(shí)間到900秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsave；
當(dāng)時(shí)間到300秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少10次變化，則執(zhí)行bgsave；
當(dāng)時(shí)間到60秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少10000次變化， 則執(zhí)行bgsave。
?開啟RDB文件壓縮
?指定RDB文件名
?重啟后查看是否生成了rdb文件
2.AOF持久化
（1）自動(dòng)觸發(fā)
?開啟AOF
?指定AOF文件名稱
是否忽略最后一條可能存在問題的指令
重啟后?查看是否生成了aof文件
（2）AOF緩存區(qū)的同步文件策略
（3）文件重寫的觸發(fā)
文件的大小超過基準(zhǔn)百分之100后觸發(fā)bgrewriteaof。
當(dāng)文件大于64M時(shí)才會(huì)進(jìn)行重寫
3.Redis性能管理
（1）查看Redis內(nèi)存使用
方法一：進(jìn)入redis數(shù)據(jù)庫(kù)查看
?方法二：命令行查看
（2）內(nèi)存碎片
config set activedefrag yes #自動(dòng)碎片清理
memory purge #手動(dòng)碎片清理
（3）內(nèi)存使用率
禁止淘汰數(shù)據(jù)（不刪除直到寫滿時(shí)報(bào)錯(cuò)）
可以設(shè)置最大內(nèi)存閥值
?
4.Redis的優(yōu)化
（1）設(shè)置Redis客戶端連接的超時(shí)時(shí)間
（2）設(shè)置 redis客戶端最大連接數(shù)
①?redis客戶端最大連接數(shù)默認(rèn)為10000。
若不設(shè)置，默認(rèn)是10000
②?查看 redis 當(dāng)前連接數(shù)
③?查看 redis 允許的最大連接數(shù)
（3）設(shè)置redis自動(dòng)碎片清理
（4）設(shè)置redis最大內(nèi)存閥值
（5）設(shè)置key回收策略
三、總結(jié)
Redis群集有三種模式，分別是主從同步/復(fù)制、哨兵模式、Cluster。
Redis 提供兩種方式進(jìn)行持久化：RDB類似于Mysql?dump快照，AOF則類似于mysql binlog。
RDB觸發(fā)方式：
RDB持久化的觸發(fā)分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)兩種。
（1）手動(dòng)觸發(fā)
① save命令
redis-cli
redis> save
OK② bigsave命令
redis-cli -p 6379 -h 127.0.0.1
127.0.0.1:6379> bgsave
Background saving started（2）自動(dòng)觸發(fā)
在自動(dòng)觸發(fā)RDB持久化時(shí)，Redis 也會(huì)選擇bgsave而不是save來進(jìn)行持久化。
自動(dòng)觸發(fā)最常見的情況是在配置文件中通過 save m n 指定當(dāng)m秒內(nèi)發(fā)生n次變化時(shí)，會(huì)觸發(fā)bgsave。
vim /etc/redis/6379.conf #編輯配置文件?----219行--以下三個(gè)save條件滿足任意一一個(gè)時(shí)，都會(huì)引起bgsave的調(diào)用save 900 1 #當(dāng)時(shí)間到900秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsavesave 300 10 #當(dāng)時(shí)間到300秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少10次變化，則執(zhí)行bgsavesave 60 10000 #當(dāng)時(shí)間到60秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少10000次變化， 則執(zhí)行bgsave?----242行--是否開啟RDB文件壓縮rdbcompression yes?----254行--指定RDB文件名dbfilename dump.rdb?----264行--指定RDB文件和AOF文件所在目錄dir /var/lib/redis/6379
RDB恢復(fù)數(shù)據(jù)：
#如果需要恢復(fù)數(shù)據(jù)，只需將備份文件 (dump.rdb) 移動(dòng)到 redis 安裝目錄并啟動(dòng)服務(wù)即可。獲取 redis 目錄可以使用?CONFIG?命令，如下所示：redis 127.0.0.1:6379> CONFIG GET dir1) "dir"2) "/usr/local/redis/bin"
redis 127.0.0.1:6379> CONFIG GET dir1) "dir"2) "/usr/local/redis/bin"
AOF觸發(fā)方式：
AOF持久化的觸發(fā)分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)兩種。
（1）手動(dòng)觸發(fā)
① #向Redis發(fā)送命令來觸發(fā)AOF重寫
redis-cli
redis> bgrewriteaof
Background append only file rewriting started② #修改Redis配置文件中的來手動(dòng)觸發(fā)AOF持久化
vim /etc/redis/6379.conf
--700行--修改，開啟AOF
appendonly yes
--704行--指定AOF文件名稱
appendfilename "appendonly.aof"
--796行--是否忽略最后一條可能存在問題的指令
aof-load-truncated yes（2）自動(dòng)觸發(fā)
① #rewrite-min-size和auto-aof-rewrite-percentage兩個(gè)選項(xiàng)同時(shí)滿足時(shí)，才會(huì)自動(dòng)觸發(fā)AOF重寫，即bgrewriteaof操作。vim /etc/redis/6379.conf?
--729--
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb ② AOF緩存區(qū)的同步文件策略:
vim /etc/redis/6379.conf----729行----# 每條語句同步執(zhí)行持久化（強(qiáng)一致性場(chǎng)景）
appendfsync always# 每秒進(jìn)行一次AOF持久化（均衡性場(chǎng)景）
appendfsync everysec# 從不進(jìn)行持久化
appendfsync no內(nèi)存回收key ：
vim /etc/redis/6379.conf
--598--
maxmemory-policy noenviction
●volatile-lru：使用LRU算法從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中淘汰數(shù)據(jù)(移除最近最少使用的key，針對(duì)設(shè)置了TTL的key)
●volatile-ttl：從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中挑選即將過期的數(shù)據(jù)淘汰（移除最近過期的key）
●volatile-random：從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中隨機(jī)挑選數(shù)據(jù)淘汰（在設(shè)置了TTL的key里隨機(jī)移除）
●allkeys-lru：使用LRU算法從所有數(shù)據(jù)集合中淘汰數(shù)據(jù)（移除最少使用的key，針對(duì)所有的key）
●allkeys-random：從數(shù)據(jù)集合中任意選擇數(shù)據(jù)淘汰（隨機(jī)移除key）
●noenviction：禁止淘汰數(shù)據(jù)（不刪除直到寫滿時(shí)報(bào)錯(cuò)）