NoSQL之Redis高可用與優化

一、Redis高可用

在web服務器中，高可用是指服務器可以正常訪問的時間，衡量的標準是在多長時間內可以提供正常服務（99.9%、99.99%、99.999%等等）。
但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務（如主從分離、快速容災技術），還需要考慮數據容量的擴展、數據安全不會丟失等。

在Redis中，實現高可用的技術主要包括持久化、主從復制、哨兵和 Cluster集群，下面分別說明它們的作用，以及解決了什么樣的問題。

持久化：持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是數據備份，即將數據存儲在硬盤，保證數據不會因進程退出而丟失。
主從復制：主從復制是高可用Redis的基礎，哨兵和集群都是在主從復制基礎上實現高可用的。主從復制主要實現了數據的多機備份，以及對于讀操作的負載均衡和簡單的故障恢復。缺陷：故障恢復無法自動化；寫操作無法負載均衡；存儲能力受到單機的限制。
哨兵：在主從復制的基礎上，哨兵實現了自動化的故障恢復。缺陷：寫操作無法負載均衡；存儲能力受到單機的限制。
Cluster集群：通過集群，Redis解決了寫操作無法負載均衡，以及存儲能力受到單機限制的問題，實現了較為完善的高可用方案。

二、Redis 持久化

持久化的功能：Redis是內存數據庫，數據都是存儲在內存中，為了避免服務器斷電等原因導致Redis進程異常退出后數據的永久丟失，需要定期將Redis中的數據以某種形式（數據或命令）從內存保存到硬盤；當下次Redis重啟時，利用持久化文件實現數據恢復。除此之外，為了進行災難備份，可以將持久化文件拷貝到一個遠程位置。

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

RDB 持久化：原理是將 Reids在內存中的數據庫記錄定時保存到磁盤上。
AOF 持久化（append only file）：原理是將 Reids 的操作日志以追加的方式寫入文件，類似于MySQL的binlog。

由于AOF持久化的實時性更好，即當進程意外退出時丟失的數據更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地。

2.2 RDB持久化

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

2.2-1 觸發條件

RDB持久化的觸發分為手動觸發和自動觸發兩種。

1、手動觸發

save命令和bgsave命令都可以生成RDB文件。
save命令會阻塞Redis服務器進程，直到RDB文件創建完畢為止，在Redis服務器阻塞期間，服務器不能處理任何命令請求。
而bgsave命令會創建一個子進程，由子進程來負責創建RDB文件，父進程(即Redis主進程)則繼續處理請求。
bgsave命令執行過程中，只有fork子進程時會阻塞服務器，而對于save命令，整個過程都會阻塞服務器，因此save已基本被廢棄，線上環境要杜絕save的使用。

2、自動觸發

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

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

vim /usr/local/redis/conf/redis.conf    #編輯配置文件?----433行--以下三個save條件滿足任意一一個時，都會引起bgsave的調用save 900 1 300 10 60 10000900 1      #當時間到900秒時，如果redis數據發生了至少1次變化，則執行bgsave300 10     #當時間到300秒時，如果redis數據發生了至少10次變化，則執行bgsave60 10000   #當時間到60秒時，如果redis數據發生了至少10000次變化， 則執行bgsave?----454行--是否開啟RDB文件壓縮rdbcompression yes?----481行--指定RDB文件名dbfilename dump.rdb?----504行--指定RDB文件和AOF文件所在目錄dir /usr/local/redis/data

其他自動觸發機制
除了save m n 以外，還有一些其他情況會觸發bgsave：

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

2.2-2 執行流程

Redis父進程首先判斷：當前是否在執行save，或bgsave/bgrewriteaof的子進程，如果在執行bgsave命令直接返回。 bgsave/bgrewriteaof的子進程不能同時執行，主要是基于性能方面的考慮：兩個并發的子進程同時執行大量的磁盤寫操作，可能引起嚴重的性能問題。
父進程執行fork操作創建子進程，這個過程中父進程是阻塞的，Redis不能執行來自客戶端的任何命令
父進程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父進程，并可以響應其他命令
子進程創建RDB文件，根據父進程內存快照生成臨時快照文件，完成后對原有文件進行原子替換
子進程發送信號給父進程表示完成，父進程更新統計信息

2.2-3 啟動時加載

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

2.3 AOF 持久化

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

2.3.1 開啟AOF

Redis服務器默認開啟RDB，關閉AOF；要開啟AOF，需要在配置文件中配置,
不同版本的Redis所在的配置行都不一樣，通過字符串查找vim /usr/local/redis/conf/redis.conf----1379行---修改，開啟AOFappendonly yes----1406行---指定AOF文件名稱appendfilename "appendonly.aof"----1504行---是否忽略最后一條可能存在問題的指令aof-load-truncated yes ??#Redis恢復時，發現AOF文件的末尾被截斷了，會忽略最后一條可能存在問題的指令。默認值yes。即在aof寫入時，可能發生redis機器運行崩潰，AOF文件的末尾被截斷了，這種情況下，yes會繼續執行并恢復盡量多的數據，而no會直接恢復失敗報錯退出。??systemctl restart redis-server ? ?#重啟redisls /usr/local/redis/data ? ? ?#查看是否生成了aof文件

2.3.2 執行流程

由于需要記錄Redis的每條寫命令，因此AOF不需要觸發，下面介紹AOF的執行流程。

AOF的執行流程包括：

命令追加(append)：將Redis的寫命令追加到緩沖區aof_buf；
文件寫入(write)和文件同步(sync)：根據不同的同步策略將aof_buf中的內容同步到硬盤；
文件重寫(rewrite)：定期重寫AOF文件，達到壓縮的目的。

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

（2）文件寫入(write)和文件同步(sync)
Redis提供了多種AOF緩存區的同步文件策略，策略涉及到操作系統的write函數和fsync函數，說明如下：
為了提高文件寫入效率，在現代操作系統中，當用戶調用write函數將數據寫入文件時，操作系統通常會將數據暫存到一個內存緩沖區里，當緩沖區被填滿或超過了指定時限后，才真正將緩沖區的數據寫入到硬盤里。這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機，內存緩沖區中的數據會丟失；因此系統同時提供了fsync、fdatasync等同步函數，可以強制操作系統立刻將緩沖區中的數據寫入到硬盤里，從而確保數據的安全性。

AOF緩存區的同步文件策略存在三種同步方式，它們分別是：

vim /usr/local/redis/conf/redis.conf
--1437--
appendfsync always： 命令寫入aof_buf后立即調用系統fsync操作同步到AOF文件，fsync完成后線程返回。這種情況下，每次有寫命令都要同步到AOF文件，硬盤IO成為性能瓶頸，Redis只能支持大約幾百TPS寫入，嚴重降低了Redis的性能；即便是使用固態硬盤（SSD），每秒大約也只能處理幾萬個命令，而且會大大降低SSD的壽命。
--1439--
appendfsync no： 命令寫入aof_buf后調用系統write操作，不對AOF文件做fsync同步；同步由操作系統負責，通常同步周期為30秒。這種情況下，文件同步的時間不可控，且緩沖區中堆積的數據會很多，數據安全性無法保證。
--1438--
appendfsync everysec： 命令寫入aof_buf后調用系統write操作，write完成后線程返回；fsync同步文件操作由專門的線程每秒調用一次。everysec是前述兩種策略的折中，是性能和數據安全性的平衡，因此是Redis的默認配置，也是我們推薦的配置。

（3）文件重寫(rewrite)
隨著時間流逝，Redis服務器執行的寫命令越來越多，AOF文件也會越來越大；過大的AOF文件不僅會影響服務器的正常運行，也會導致數據恢復需要的時間過長。

文件重寫是指定期重寫AOF文件，減小AOF文件的體積。需要注意的是，AOF重寫是把Redis進程內的數據轉化為寫命令，同步到新的AOF文件；不會對舊的AOF文件進行任何讀取、寫入操作!

關于文件重寫需要注意的另一點是：對于AOF持久化來說，文件重寫雖然是強烈推薦的，但并不是必須的；即使沒有文件重寫，數據也可以被持久化并在Redis啟動的時候導入；因此在一些現實中，會關閉自動的文件重寫，然后通過定時任務在每天的某一時刻定時執行。

文件重寫之所以能夠壓縮AOF文件，原因在于：

過期的數據不再寫入文件
無效的命令不再寫入文件：如有些數據被重復設值(set mykey v1, set mykey v2)、有些數據被刪除了(set myset v1, del myset)等。
多條命令可以合并為一個：如sadd myset v1, sadd myset v2, sadd myset v3可以合并為sadd myset v1 v2 v3。

通過上述內容可以看出，由于重寫后AOF執行的命令減少了，文件重寫既可以減少文件占用的空間，也可以加快恢復速度。

文件重寫的觸發，分為手動觸發和自動觸發：

手動觸發：直接調用bgrewriteaof命令，該命令的執行與bgsave有些類似：都是fork子進程進行具體的工作，且都只有在fork時阻塞。
自動觸發：通過設置auto-aof-rewrite-min-size選項和auto-aof-rewrite-percentage選項來自動執行BGREWRITEAOF。只有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個選項同時滿足時，才會自動觸發AOF重寫，即bgrewriteaof操作。

vim /usr/local/redis/conf/redis.conf
--1479--
auto-aof-rewrite-percentage 100?? ?：當前AOF文件大小(即aof_current_size)是上次日志重寫時AOF文件大小(aof_base_size)兩倍時，發生BGREWRITEAOF操作
--1480--
auto-aof-rewrite-min-size 64mb ：當前AOF文件執行BGREWRITEAOF命令的最小值，避免剛開始啟動Reids時由于文件尺寸較小導致頻繁的BGREWRITEAOF

關于文件重寫的流程，有兩點需要特別注意：

重寫由父進程fork子進程進行；
重寫期間Redis執行的寫命令，需要追加到新的AOF文件中，為此Redis引入了aof_rewrite_buf緩存。

文件重寫的流程如下：
（1）Redis父進程首先判斷當前是否存在正在執行bgsave/bgrewriteaof的子進程，如果存在則bgrewriteaof命令直接返回，如果存在 bgsave命令則等bgsave執行完成后再執行。
（2）父進程執行fork操作創建子進程，這個過程中父進程是阻塞的。
（3.1）父進程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父進程，并可以響應其他命令。Redis的所有寫命令依然寫入AOF緩沖區，并根據appendfsync策略同步到硬盤，保證原有AOF機制的正確。
（3.2）由于fork操作使用寫時復制技術，子進程只能共享fork操作時的內存數據。由于父進程依然在響應命令，因此Redis使用AOF重寫緩沖區(aof_rewrite_buf)保存這部分數據，防止新AOF文件生成期間丟失這部分數據。也就是說，bgrewriteaof執行期間，Redis的寫命令同時追加到aof_buf和aof_rewirte_buf兩個緩沖區。
（4）子進程根據內存快照，按照命令合并規則寫入到新的AOF文件。
（5.1）子進程寫完新的AOF文件后，向父進程發信號，父進程更新統計信息，具體可以通過info persistence查看。
（5.2）父進程把AOF重寫緩沖區的數據寫入到新的AOF文件，這樣就保證了新AOF文件所保存的數據庫狀態和服務器當前狀態一致。
（5.3）使用新的AOF文件替換老文件，完成AOF重寫。

2.3.3 執行流程啟動時加載

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

三、RDB和AOF的優缺點

RDB持久化
優點：RDB文件緊湊，體積小，網絡傳輸快，適合全量復制；恢復速度比AOF快很多。當然，與AOF相比，RDB最重要的優點之一是對性能的影響相對較小。

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

AOF持久化

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

四、Redis 性能管理

4.1 查看Redis內存使用

192.168.9.236:7001> info memory

4.2 內存碎片率

mem_fragmentation_ratio：內存碎片率。mem_fragmentation_ratio = used_memory_rss / used_memory
used_memory_rss：是Redis向操作系統申請的內存。
used_memory：是Redis中的數據占用的內存。
used_memory_peak：redis內存使用的峰值。

4.3 內存碎片如何產生的？

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

4.4 跟蹤內存碎片率對理解Redis實例的資源性能是非常重要的

內存碎片率在1到1.5之間是正常的，這個值表示內存碎片率比較低，也說明 Redis 沒有發生內存交換。
內存碎片率超過1.5，說明Redis消耗了實際需要物理內存的150%，其中50%是內存碎片率。
內存碎片率低于1的，說明Redis內存分配超出了物理內存，操作系統正在進行內存交換。需要增加可用物理內存或減少 Redis內存占用。

4.5 解決碎片率大的問題

如果你的Redis版本是4.0以下的，需要在 redis-cli 工具上輸入 shutdown save 命令，讓 Redis 數據庫執行保存操作并關閉 Redis 服務，再重啟服務器。Redis服務器重啟后，Redis會將沒用的內存歸還給操作系統，碎片率會降下來。

Redis4.0版本開始，可以在不重啟的情況下，線上整理內存碎片。

config set activedefrag yes ? ? #自動碎片清理，內存就會自動清理了。
memory purge?? ??? ??? ??? ??? ?#手動碎片清理

4.6 內存使用率

redis實例的內存使用率超過可用最大內存，操作系統將開始進行內存與swap空間交換。

4.7 避免內存交換發生的方法

針對緩存數據大小選擇安裝 Redis 實例
盡可能的使用Hash數據結構存儲
設置key的過期時間

4.8 內回收key

內存數據淘汰策略，保證合理分配redis有限的內存資源。

當達到設置的最大閥值時，需選擇一種key的回收策略，默認情況下回收策略是禁止刪除。
配置文件中修改 maxmemory-policy 屬性值：

vim /usr/local/redis/conf/redis.conf
--1148--
maxmemory-policy noenvictionvolatile-lru：使用LRU算法從已設置過期時間的數據集合中淘汰數據(移除最近最少使用的key，針對設置了TTL的key)volatile-ttl：從已設置過期時間的數據集合中挑選即將過期的數據淘汰（移除最近過期的key）volatile-random：從已設置過期時間的數據集合中隨機挑選數據淘汰（在設置了TTL的key里隨機移除）allkeys-lru：使用LRU算法從所有數據集合中淘汰數據（移除最少使用的key，針對所有的key）allkeys-random：從數據集合中任意選擇數據淘汰（隨機移除key）noenviction：禁止淘汰數據（不刪除直到寫滿時報錯）

五、redis 優化

5.1 redis 優化

開啟 AOF 持久化
設置 config set activedefrag yes 開啟內存碎片自動清理，或者定時執行 memory purge 清理內存碎片
設置內存數據淘汰策略 maxmemory-policy 實現保證內存使用率不超過系統最大內存
maxmemory設置redis占用最大內存值，maxmemory-samples設置淘汰策略算法的樣本數量
盡可能使用 Hash 數據類型存儲數據，如果 Hash 中包含很少的字段，那么該類型的數據也將僅占用很少的空間
設置 key 的過期時間，精簡鍵名和鍵值，控制鍵值的大小
設置 config set requirepass 開啟密碼驗證
合理設置 maxclient 最大連接數參數（10000），tcp-backlog 連接排隊數（1024）， timeout 連接超時時間（30000）
部署主從復制，備份數據，采用哨兵或集群方案實現高可用

5.2 緩存和數據庫雙寫一致性問題

先更新數據庫，然后再刪除緩存 + 緩存做過期時間，數據過期后再有讀請求可從數據庫直接更新緩存

5.3 緩存雪崩

緩存同一時間大面積的過期失效，所以，后面的請求都會落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。

解決方案：
緩存數據的過期時間設置隨機，防止同一時間大量數據過期現象發生。
一般并發量不是特別多的時候，使用最多的解決方案是加鎖排隊。
給每一個緩存數據增加相應的緩存標記，記錄緩存的是否失效，如果緩存標記失效，則更新數據緩存。

5.4 緩存擊穿

緩存中沒有但數據庫中有的數據（一般是緩存時間到期），這時由于并發用戶特別多，同時讀緩存沒讀到數據，又同時去數據庫去取數據，引起數據庫壓力瞬間增大，造成過大壓力。
和緩存雪崩不同的是，緩存擊穿指并發查同一條數據，緩存雪崩是不同數據都過期了，很多數據都查不到從而查數據庫。

解決方案
設置熱點數據永遠不過期。
加互斥鎖，互斥鎖。

5.5 緩存穿透

緩存和數據庫中都沒有的數據，導致所有的請求都落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。

解決方案：
接口層增加校驗，如用戶鑒權校驗，id做基礎校驗，id<=0的直接攔截；
從緩存取不到的數據，在數據庫中也沒有取到，這時也可以將key-value對寫為key-null，緩存有效時間可以設置短點，如30秒（設置太長會導致正常情況也沒法使用）。這樣可以防止攻擊用戶反復用同一個id暴力攻擊
采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的 bitmap 中，一個一定不存在的數據會被這個 bitmap 攔截掉，從而避免了對底層存儲系統的查詢壓力。

六、RDB與AOF 持久化的區別？（面試題）

RDB持久化方式：定時把redis內存中的數據進行快照，并壓縮保存
RDB的優缺點： ?RDB保存的文件占用空間小，網絡傳輸快，恢復速度比AOF快，但兼容性較差RDB持久化期間，在fork子進程時會阻塞父進程，由于是定時持久化，實時性不如AOFAOF持久化方式：以追加的方式將redis寫操作的命令記錄到文件中，實時性比RDB好
AOF的優缺點： ?支持秒級持久化，兼容性較好，缺點持久化文件占用空間較大，恢復速度較慢，對IO性能消耗更大AOF文件重寫期間，在fork子進程會阻塞父進程，且對IO性能消耗更大

七、 Redis做過哪些優化？（面試題）

重啟AOF持久化
設置Redis密碼
開啟內存碎片清理
使用哈希做數據類型，占用空間小
設置內存的最大占用值
設置鍵的回收策略
設置最大連接數

八、排查redis占用內存高的排查方法？

1、登陸服務器，查看tcp連接數

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

查看已經建立的連接數，即ESTABLISHED的數量，發現大多數建立的ESTABLISHED連接是java和redis之間的TCP連接。
運行config get maxclients命令，查看redis的最大連接數，如果上述命令獲取的連接數遠大于redis自身的允許的最大最大連接數，說明過多的連接導致redis內存占用高。
查看監控，流量正常，也沒有突發大流量進入。那很有可能是TCP連接后沒有釋放，找開發檢查代碼，是否存在方法獲取redis的key后，沒有close。增加關閉redis連接的代碼即可。

2、查看redis是否存在過多空閑鍵

3、分析redis基本的內存信息

連接redis后，使用info memory命令查看redis內存的基本信息
查看每個db key的數量
查詢redis已經連接的客戶端數
查看單個redis key占用的空間

?redis-memory-for-key -s ${host} -p ${port} key_name

如果redis是用的集群，找到key的槽位所在的節點，port用對應的節點即可。尋找占用內存過高的key 。