redis重點總結
在正常的業務流程中，用戶發送請求，然后到緩存中查詢數據。如果緩存中不存在數據的話，就會去數據庫查詢數據。數據庫中有的話，就會更新緩存然后返回數據，數據庫中也沒有的話就會給用戶返回一個空。
1.緩存擊穿
1.1概念
緩存擊穿是指緩存中沒有但數據庫中有的數據（一般是緩存時間到期），這時由于并發用戶特別多，同時讀緩存沒讀到數據，又同時去數據庫去取數據，引起數據庫壓力瞬間增大，造成過大壓力。和緩存雪崩不同的是，緩存擊穿是指并發查同一條數據，緩存雪崩是不同數據都過期了，很多數據都查不到從而查數據庫。
1.2解決方案
- 設置熱點數據永遠不過期。（常用
- 加互斥鎖，進行排隊
2.緩存雪崩
2.1概念
緩存雪崩是指緩存同一時間大面積的失效或者緩存服務器宕機，所以，后面的請求都會落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。
2.2解決方案
- 緩存數據的過期時間設置隨機，防止同一時間大量數據過期現象發生。（常用
- 一般并發量不是特別多的時候，使用最多的解決方案是加鎖排隊。
- 給每一個緩存數據增加相應的緩存標記，記錄緩存的是否失效，如果緩存標記失效，則更新數據緩存。
3.緩存穿透
3.1概念
緩存穿透是指緩存和數據庫中都沒有的數據，導致所有的請求都落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。
3.2解決方案
- 接口層增加校驗，如用戶鑒權校驗，id做基礎校驗，id<=0的直接攔截；
- 從緩存取不到的數據，在數據庫中也沒有取到，這時也可以將key-value對寫為key-null，緩存有效時間可以設置短點，如30秒（設置太長會導致正常情況也沒法使用）。這樣可以防止攻擊用戶反復用同一個id暴力攻擊
- 采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的 bitmap 中，一個一定不存在的數據會被這個 bitmap 攔截掉，從而避免了對底層存儲系統的查詢壓力
4.主從復制原理
實現主從復制 ( Master-slave Replication)的工作原理 :
- slave從節點服務啟動并連接到Master之后，它將主動發送一個SYNC命令
- Maser服務主節點收到同步命令后將啟動后臺存盤進程，同時收集所有接收到的用于修改數據集的命令，在后臺進程執行完畢后。Mastr將傳送整個數據庫文件到Slave，以完成一次完全同步
- 而slave從節點服務在接收到數據庫文件數據之后將其存盤并加載到內存中
此后，Master主節點繼續將所有已經收集到的修改命令，和新的修改命令依次傳送給Slaves，slave將在本次執行這些數據修改命令，從而達到最終的數據同步。
如果Master和Slave之間的鏈接出現斷連現象，Slave可以自動重連Master，但是在連接成功之后，一次完全同步將被自動執行。
5.Redis持久化
Redis是基于內存存儲的nosql數據庫 但是也可以持久化數據到硬盤當中
redis有兩種持久化方式，分別是 rdb 和 aof
5.1rdb
rdb的觸發方式分為兩種：自動觸發、手動觸發
優點：存儲的數據是按照二進制形式進行存儲，比較緊湊，存儲和恢復都比較快
缺點：當進行存盤的時候，在存盤開始到存盤完成的這段時間的數據，并沒有立即的持久化到硬盤當中，如果服務器宕機，就可能發生數據丟失。
5.1.1手動觸發
rdb在手動觸發當中呢，使用的主要是save和bgsave命令。
1.save
save命令執行后，會阻塞當前服務器，知道RDB完成為止，但是當你數據量大的時候，就會出現造成過長時間的阻塞
2.bgsave
bgsave命令執行后，Redis的主進程就會fork一個子進程來完成RDB的過程，完成后自動結束。所有使用bgsave時，造成主進程阻塞的時間只為fork階段的那一下。與save相比，阻塞時間短。
5.1.2自動觸發
場景一：可通過配置redis.conf文件，定義觸發規則使得rdb自動執行
比如 save 900 1 表示 在900s內，至少執行了一次寫操作，就會自動觸發bgsave
場景二：在執行shutdown命令時，如果沒有開啟AOF持久化功能，那么就會自動執行一次bgsave
場景三：主從同步（master和slave建立同步機制
5.2aof
aof的觸發方式也分為 自動觸發和手動觸發
優點：aof存儲中，數據丟失的少，精準度高
缺點：存儲的文件越來越大 需要瘦身 恢復數據也慢
5.2.1手動觸發
執行 bgrewriteaof命令。 該命令會使主進程 redis-server 創建出一個子進程 bgrewriteaof，由該子進程完成 rewrite過程。而在 rewrite 期間，redis-server 仍是可以對外提供讀寫服務的。
5.2.2自動觸發
修改配置文件
首先指定aof文件的名稱。
AOF 持久化的方法提供了多種的同步頻率，即使使用默認的同步頻率每秒同步一次，Redis 最多也就丟失 1 秒的數據而已。
5.3AOF與RDB對比
- RDB快照的存儲是全量存儲，每次執行時，會將數據以二進制流的方式全部存儲到硬盤當中。
- AOF是增量存儲，他存儲的是數據庫中每次進行數據修改時的命令，將命令以增量的方式存儲在硬盤當中。他的恢復也是將命令從頭到尾執行一遍進行恢復。
在Redis 4.0版本后采用混合模式
在正常的存儲過程中采用RDB快照的方式，而當RDB執行時，采用AOF存儲，這樣既提高了數據存儲和恢復的效率，也減少了丟失的數據（并不是不會丟失）。
6.Redis的key過期策略
過期策略通常有以下三種
- 定時過期：每個設置過期時間的key都需要創建一個定時器，到過期時間就會立即清除。該策略可以立即清除過期的數據，對內存很友好；但是會占用大量的CPU資源去處理過期的數據，從而影響緩存的響應時間和吞吐量。
- 惰性過期：只有當訪問一個key時，才會判斷該key是否已過期，過期則清除。該策略可以最大化地節省CPU資源，卻對內存非常不友好。極端情況可能出現大量的過期key沒有再次被訪問，從而不會被清除，占用大量內存。
- 定期過期：每隔一定的時間，會掃描一定數量的數據庫的expires字典中一定數量的key，并清除其中已過期的key。該策略是前兩者的一個折中方案。通過調整定時掃描的時間間隔和每次掃描的限定耗時，可以在不同情況下使得CPU和內存資源達到最優的平衡效果。
7.Redis的內存淘汰機制
Redis的內存淘汰策略是指在Redis的用于緩存的內存不足時，怎么處理需要新寫入且需要申請額外空間的數據。
全局的鍵空間選擇性移除
- noeviction：當內存不足以容納新寫入數據時，新寫入操作會報錯。
- allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的key。（這個是最常用的）
- allkeys-random：當內存不足以容納新寫入數據時，在鍵空間中，隨機移除某個key。
設置過期時間的鍵空間選擇性移除
-
volatile-lru：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，移除最近最少使用的key。
-
volatile-random當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，隨機移除某個key。
的鍵空間選擇性移除 -
volatile-lru：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，移除最近最少使用的key。
-
volatile-random當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，隨機移除某個key。
-
volatile-ttl當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，有更早過期時間的key優先移除。
 (A-G))
