Redis本質上是一個Key-Value類型的內存數據庫，很像memcached，整個數據庫統統加載 在內存當中進行操作，定期通過異步操作把數據庫數據flush到硬盤上進行保存。
因為是純內存操作，Redis的性能非常出色，每秒可以處理超過 10萬次讀寫操作，是已知性能 最快的Key-Value DB。
Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存多種數據結構，此外單個value 的最大限制是1GB，不像 memcached只能保存1MB的數據，因此Redis可以用來實現很多有用的功能。比方說用他的List來做FIFO雙向鏈表，實現一個輕量級的高性 能消息隊列服務，用他的Set可 以做高性能的tag系統等等。
另外Redis也可以對存入的Key-Value設置expire時間，因此也可以被當作一 個功能加強版的 memcached來用。 Redis的主要缺點是數據庫容量受到物理內存的限制，不能用作海量數據 的高性能讀寫，因此Redis適合的場景主要局限在較小數據量的高性能操作和運算上。
字符串（String）：二進制安全字符串。
列表（List）：根據插入順序排序的字符串元素列表，基于鏈表實現。
集合（Set）：唯一的亂序的字符串元素的集合。
有序集合（Sorted Set）：與集合類似，但是每個字符串元素都與一個稱為score的數字相關聯。元素總是按其score排序，并且可以檢索一定score范圍的元素。
哈希（Hash）：由字段與值相關聯組成的映射，字段和值都是字符串。
位圖（Bitmap）:像操作位數組一樣操作字符串值，可以設置和清除某個位，對所有為1的位進行計數，找到第一個設置1的位，找到第一個設置0的位等等。
HyperLogLogs：一種概率數據結構，使用較小的內存空間來統計唯一元素的數量，誤差小于1％。
1.完全基于內存，絕大部分請求是純粹的內存操作，非常快速。數據存在內存中，類似于 HashMap，HashMap 的優勢就是查找和操作的時間復雜度都是O(1)；
2.數據結構簡單，對數據操作也簡單，Redis 中的數據結構是專門進行設計的；
3.采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的性能消耗；
4.使用多路 I/O 復用模型，非阻塞 IO；
5.使用底層模型不同，它們之間底層實現方式以及與客戶端之間通信的應用協議不一樣，Redis 直接自己構建了 VM 機制 ，因為一般的系統調用系統函數的話，會浪費一定的時間去移動和請求；
1.緩存：減輕數據庫的壓力，提高系統性能。
2.排行榜：利用 Redis 的 SortSet（有序集合）實現；
3.計數器/限速器：利用 Redis 中原子性的自增操作，我們可以統計類似用戶點贊數、用戶訪問數等。這類操作如果用 MySQL，頻繁的讀寫會帶來相當大的壓力；限速器比較典型的使用場景是限制某個用戶訪問某個 API 的頻率，常用的有搶購時，防止用戶瘋狂點擊帶來不必要的壓力；
4.好友關系：利用集合的一些命令，比如求交集、并集、差集等。可以方便解決一些共同好友、共同愛好之類的功能；
5.消息隊列：除了 Redis 自身的發布/訂閱模式，我們也可以利用 List 來實現一個隊列機制，比如：到貨通知、郵件發送之類的需求，不需要高可靠，但是會帶來非常大的 DB 壓力，完全可以用 List 來完成異步解耦；
6.Session 共享：Session 是保存在服務器的文件中，如果是集群服務，同一個用戶過來可能落在不同機器上，這就會導致用戶頻繁登陸；采用 Redis 保存 Session 后，無論用戶落在那臺機器上都能夠獲取到對應的 Session 信息。
緩存穿透指查詢一個一定不存在的數據，由于緩存是不命中時需要從數據庫查詢，查不到數據則不寫入緩存，這將導致這個不存在的數據每次請求都要到數據庫去查詢，進而給數據庫帶來壓力。
解決方案：
1)將空數據也緩存：占有一定的空間，可能帶來短期的數據不一致。
如果一個查詢返回的數據為空（不管是數據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘，
2)使用布隆過濾器bloom filter：是一種預防的方案，占用空間少、誤差可控。
將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。
緩存雪崩是指在某一個時間段，緩存集中過期失效。當某一個時刻出現大規模的緩存失效的情況，那么就會導致大量的請求直接打在數據庫上面，導致數據庫壓力巨大，如果在高并發的情況下，可能瞬間就會導致數據庫宕機。這時候如果運維馬上又重啟數據庫，馬上又會有新的流量把數據庫打死。這就是緩存雪崩。
解決方案
1)過期時間設置隨機值:在原有的失效時間上加上一個隨機值，比如，1-5分鐘隨機。這樣就避免了同一時間大量數據過期現象的發生而導致緩存雪崩。
2)分布式部署且均勻分布熱點數據:如果緩存數據庫是分布式部署，將熱點數據均勻分布在不同搞得緩存數據庫中。同時，分布式集群可以防止Redis宕機導致緩存雪崩的問題。
3)熱點數據永不過期:設置熱點數據永遠不過期。
4)使用熔斷機制。當流量到達一定的閾值時，就直接返回“系統擁擠”之類的提示，防止過多的請求打在數據庫上。至少能保證一部分用戶是可以正常使用，其他用戶多刷新幾次也能得到結果。
5)提高數據庫的容災能力，可以使用分庫分表，讀寫分離的策略。
造成緩存雪崩的關鍵在于在同一時間大規模的key失效。出現這個問題有下面幾種可能：
第一種可能是Redis宕機，
第二種可能是采用了相同的過期時間。
某一個熱點 key，在緩存過期的一瞬間，同時有大量的請求打進來，由于此時緩存過期了，所以請求最終都會走到數據庫，造成瞬時數據庫請求量大、壓力驟增，甚至可能打垮數據庫。
解決方案：
1.加互斥鎖。在并發的多個請求中，只有第一個請求線程能拿到鎖并執行數據庫查詢操作，其他的線程拿不到鎖就阻塞等著，等到第一個線程將數據寫入緩存后，直接走緩存。
2.JVM 鎖保證了在單臺服務器上只有一個請求走到數據庫，通常來說已經足夠保證數據庫的壓力大大降低，同時在性能上比分布式鎖更好。
需要注意的是，無論是使用“分布式鎖”，還是“JVM 鎖”，加鎖時要按 key 維度去加鎖。
Redis通過MULTI、EXEC、WATCH等一組命令集合，來實現事務機制。事務支持一次執行多個命令，一個事務中所有命令都會被序列化。在事務執行過程，會按照順序串行化執行隊列中的命令，其他客戶端提交的命令請求不會插入到事務執行命令序列中。簡言之，Redis事務就是順序性、一次性、排他性的執行一個隊列中的一系列命令。
Redis執行事務的流程如下：開始事務（MULTI）、命令入隊、執行事務（EXEC）、撤銷事務（DISCARD ）。
可以的，Redis提供兩個指令生成RDB，分別是save和bgsave。
如果是save指令，會阻塞，因為是主線程執行的。
如果是bgsave指令，是fork一個子進程來寫入RDB文件的，快照持久化完全交給子進程來處理，父進程則可以繼續處理客戶端的請求。
一般來說， 如果想達到足以媲美PostgreSQL的數據安全性，你應該同時使用兩種持久化功能。在這種情況下，當 Redis 重啟的時候會優先載入AOF文件來恢復原始的數據，因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整。
如果你非常關心你的數據， 但仍然可以承受數分鐘以內的數據丟失，那么你可以只使用RDB持久化。有很多用戶都只使用AOF持久化，但并不推薦這種方式，因為定時生成RDB快照（snapshot）非常便于進行數據庫備份， 并且 RDB 恢復數據集的速度也要比AOF恢復的速度要快，除此之外，使用RDB還可以避免AOF程序的bug。
如果你只希望你的數據在服務器運行的時候存在，你也可以不使用任何持久化方式。
緩存預熱就是系統上線后，將相關的緩存數據直接加載到緩存系統。這樣就可以避免在用戶請求的時候，先查詢數據庫，然后再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！
解決方案
1.直接寫個緩存刷新頁面，上線時手工操作一下；
2.數據量不大，可以在項目啟動的時候自動進行加載；
3.定時刷新緩存；
Redis6.0采用多線程IO，不過命令的執行還是單線程的。
Redis6.0之前，IO線程和執行線程都是單線程的。
分表是EXPIRE和PERSIST命令進行設置。
加鎖重鍵（互斥鎖）：
熱鍵不過期：在緩存中創建一個時間戳，先判斷時間戳是否過期，如果沒有過期返回原數據，過期了則訪問數據源。
官方微信
官方抖音
京公網安備 11030102010736號