一篇文章了解Redis數據庫

文章原創於公眾號：程序猿周先森。本平台不定時更新，喜歡我的文章，歡迎關注我的微信公眾號。

redis是一個key-value存儲系統。它支持存儲的value類型相對更多，包括string(字符串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash(哈希類型)。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，redis支持各種不同方式的排序。為了保證效率，數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁盤或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了主從同步。簡單來說 Redis 就是一個數據庫，不過與傳統數據庫不同的是 Redis 的數據是存在內存中的，所以存寫速度非常快，因此 Redis 被廣泛應用於緩存方向。Redis 也經常用來做分布式鎖。Redis 提供了多種數據類型來支持不同的業務場景。除此之外，Redis 支持事務 、持久化、LUA 腳本、LRU 驅動事件、多種集群方案。

本篇文章將從下列幾個方向講解 Redis：

• 為什么要用 Redis實現緩存?

• 為什么要用 Redis 而不用 map/guava 做緩存

• Redis 和 Memcached 的區別

• Redis 常見數據結構以及使用場景分析

• Redis 設置過期時間

• Redis 內存淘汰機制

• Redis 持久化機制

• Redis 事務

• 緩存雪崩和緩存穿透問題解決方案

• 如何解決 Redis 的並發競爭 Key 問題

• 如何保證緩存與數據庫數據一致性

• 為什么要用 Redis 做緩存？

第一個問題先拋出來，既然選擇使用Redis作緩存，其實主要從“高性能”和“高並發”來進行理解。

高性能

1. 用戶首次訪問數據，從數據庫讀取，效率較低

2. 將用戶訪問數據保存緩存中，二次讀取則可以直接從緩存中讀取，效率更高

3. 數據庫若數據發生改變，則同步更新緩存中數據即可。

因為從數據庫讀取數據，是從硬盤中讀取數據，所以效率較低。如果將數據存入緩存中，二次讀取從緩存讀取，從緩存讀取數據是直接操作內存，所以效率非常之高。

高並發

直接操作緩存能夠承受的請求是遠遠大於直接訪問數據庫的，所以我們可以考慮把數據庫中的部分數據轉移到緩存中去，這樣用戶的一部分請求可以不用操作數據庫，提高高並發能力。

為什么要用 Redis 而不用 map/guava 做緩存

緩存分為本地緩存和分布式緩存。以 Java 為例，使用自帶的 map /guava 實現的是本地緩存，最主要的特點是輕量以及快速，生命周期隨着 JVM 的銷毀而結束。而且在多實例狀態下緩存不具有唯一性。使用 Redis 作緩存稱為分布式緩存，在多實例狀態下共用一份緩存數據，緩存具有一致性。

Redis 和 Memcached 的區別

• Redis支持常見數據類型：Redis 不僅僅支持簡單的 key/value 類型的數據，同時還提供string(字符串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash(哈希類型)等數據結構的存儲。而Memcache 只支持簡單的數據類型 String。

• Redis 支持數據的持久化，可以將內存中的數據保持在磁盤中，重啟的時候可以再次加載進行使用，而 Memecache 把數據全部存在內存之中。

• 集群模式：Memcached 沒有原生的集群模式，需要依靠客戶端來實現往集群中分片寫入數據；但是 Redis 目前是原生支持 Cluster 模式的。

• Memcached 是多線程，非阻塞 IO 復用的網絡模型；Redis 使用單線程的多路 IO 復用模型。

貼一張對比圖可能看起來更加明顯：

Redis 常見數據結構以及使用場景分析

String

• 常用命令：set、get、decr、incr、mget 等。

String 數據結構是簡單的 Key-Value 類型，Value 可以是string或者數字。常規 Key-Value 緩存應用；常規計數：博客數，閱讀數等。

Hash

• 常用命令：hget、hset、hgetall 等。

Hash 特別適合用於存儲對象。

List

• 常用命令：lpush、rpush、lpop、rpop、lrange 等。

鏈表是 Redis 最重要的數據結構之一，Redis List 為一個雙向鏈表，支持反向查找和遍歷，更方便操作，不過帶來了額外的內存開銷。

Set

• 常用命令：sadd、spop、smembers、sunion 等。

Set 其實和List都是列表的選項，Set 是可以自動去重的。當需要存儲一個不出現重復數據的列表數據，Set 是一個最好的選擇。你可以基於 Set 輕易實現交集、並集、差集的操作。

Sorted Set

• 常用命令：zadd、zrange、zrem、zcard 等。

Sorted Set 相比Set增加了一個權重參數 Score，使得集合中的元素能夠按 Score 進行有序排列。

Redis 設置過期時間

Redis可以對存儲在緩存中的數據設置過期時間。作為一個緩存數據庫，這是非常實用的功能。之前寫過一篇前后端交互的文章講過，Token 或者一些登錄信息，尤其是短信驗證碼都是有時間限制的，按照傳統的數據庫處理方式，一般都是自己判斷過期，這樣無疑會嚴重影響項目性能。而有一個好的方案其實就是將這些驗證信息存入Redis設置過期時間，如果設置了存活時間30分鍾，那么半小時之后這些數據就會從Redis中進行刪除。那說到刪除，Redis是如果做到對這些數據進行刪除的呢：

• 定期刪除：Redis 默認是每隔 100ms 就隨機抽取一些設置了過期時間的 Key，檢查其是否過期，如果過期就刪除。為什么是隨機抽取而不是檢查所有key？因為你如果設置的key成千上萬，每100毫秒都將所有存在的key檢查一遍，會給CPU帶來比較大的壓力。

• 惰性刪除 ：定期刪除可能會導致很多過期 Key 到了時間並沒有被刪除掉。用戶在獲取key的時候，redis會檢查一下，這個key如果設置過期時間那么是否過期了，如果過期就刪除這個key。

但是只是使用定期刪除 + 惰性刪除的刪除機制還是存在一個致命問題：如果定期刪除漏掉了很多過期 Key，而且用戶長時間也沒有使用到這些過期key，就會導致這些過期key堆積在內存里，導致Redis內存塊被消耗殆盡。所以有了Redis內存淘汰機制的誕生。

Redis 內存淘汰機制

Redis 提供 6 種數據淘汰策略：

• volatile-lru：從已設置過期時間的數據集中挑選最近最少使用的數據淘汰。

• volatile-ttl：從已設置過期時間的數據集中挑選將要過期的數據淘汰。

• volatile-random：從已設置過期時間的數據集中任意選擇數據淘汰。

• allkeys-lru：當內存不足以容納新寫入數據時移除最近最少使用的key。

• allkeys-random：從數據集中任意選擇數據淘汰。

• no-enviction：當內存不足以容納新寫入數據時，新寫入操作會報錯。

Redis 持久化機制

怎么保證 Redis 宕機之后再重啟Redis后數據可以進行恢復？很多時候我們需要持久化數據也就是將內存中的數據寫入到硬盤里面。Redis持久化支持兩種不同的持久化操作。接下來，我們來簡單聊聊Redis的兩種持久化機制RDB和AOF。

快照持久化（RDB）

RDB持久化是指在指定的時間間隔內將內存中的數據集快照寫入磁盤，實際操作過程是fork一個子進程，先將數據集寫入臨時文件，寫入成功后，再替換之前的文件，用二進制壓縮存儲。RDB是Redis默認的持久化方式，會在對應的目錄下生產一個dump.rdb文件，重啟會通過加載dump.rdb文件恢復數據。

優點：

• 只有一個文件dump.rdb，方便持久化；

• 容災性好，一個文件可以保存到安全的磁盤；

• 性能最大化，fork子進程來完成寫操作，讓主進程繼續處理命令，所以是IO最大化（使用單獨子進程來進行持久化，主進程不會進行任何IO操作，保證了redis的高性能) ；

• 如果數據集偏大，RDB的啟動效率會比AOF更高。

缺點：

• 數據安全性低。

• 如果當數據集較大時，可能會導致整個服務器停止服務幾百毫秒，甚至是1秒鍾。

快照持久化是 Redis 默認采用的持久化方式，在 redis.conf 配置文件中已經進行配置：

• save 900 1：在15分鍾內，如果至少有1個key發生變化，Redis就會自動觸發BGSAVE命令創建快照。

• save 300 10：在5分鍾內，如果至少有10個key發生變化，Redis就會自動觸發BGSAVE命令創建快照。

• save 60 10000：在1分鍾之后，如果至少有10000個key發生變化，Redis就會自動觸發BGSAVE命令創建快照。

AOF持久化

AOF持久化是以日志的形式記錄服務器所處理的每一個寫、刪除操作，查詢操作不會記錄，以文本的方式記錄，文件中可以看到詳細的操作記錄。她的出現是為了彌補RDB的不足（數據的不一致性），所以它采用日志的形式來記錄每個寫操作，並追加到文件中。Redis 重啟的會根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作。與快照持久化相比，AOF 持久化的實時性更好，因此已成為主流的持久化方案。 默認情況下 Redis 沒有開啟 AOF持久化，可以通過設置 appendonly 參數開啟：

• appendonly yes

開啟 AOF 持久化后每執行一條會更改 Redis 中的數據的命令，Redis 就會將該命令寫入硬盤中的 AOF 文件。AOF 文件的保存位置和 RDB 文件的位置相同，都是通過 dir 參數設置的，默認的文件名是 appendonly.aof。

在 Redis 的配置文件中存在三種不同的 AOF 持久化方式，它們分別是：

• appendfsync always：每次有數據修改發生時都會寫入AOF文件

• appendfsync everysec：每秒鍾同步一次，將多個寫命令同步到硬盤

• appendfsync no：讓操作系統決定何時進行同步

用戶可以使用appendfsync everysec選項 ，讓 Redis 每秒同步一次 AOF 文件，這樣Redis性能幾乎不會受到影響，而且這樣即使出現宕機，用戶最多只會丟失一秒之內產生的數據。當硬盤忙於執行寫入操作的時候，Redis 還會優雅的放慢自己的速度以便適應硬盤的最大寫入速度。

優點：

• 數據安全性更高，AOF持久化可以配置appendfsync屬性

• 通過append模式寫文件，即使中途服務器宕機，可以通過redis-check-aof工具解決數據一致性問題。

• AOF機制的rewrite模式。

缺點：

• AOF文件比RDB文件大，且恢復速度慢；數據集大的時候，比rdb啟動效率低。

• 根據同步策略的不同，AOF在運行效率上往往會慢於RDB。

Redis 4.0 對於持久化機制的優化

• Redis 4.0支持 RDB 和 AOF 的混合持久化，不過默認是關閉狀態。

• 開啟混合持久化，AOF 重寫的時候就直接把 RDB 的內容寫到 AOF 文件開頭。

• AOF 里面的 RDB 部分是壓縮格式不再是 AOF 格式，可讀性較差。

Redis 事務

• 命令：MULTI、EXEC、WATCH等。

事務提供了一種按順序地執行多個命令的機制。並且在事務執行期間，服務器會將事務中的所有命令都執行完畢，然后才去處理其他客戶端的命令請求。事務總是具有原子性、一致性和隔離性，並且當 Redis 運行在某種特定的持久化模式下時，事務也具有持久性。

緩存雪崩

緩存處理過程：接收到請求請求，先從緩存中取數據，取到直接返回結果，取不到時從數據庫中取，數據庫取到更新緩存，並返回結果，數據庫也沒取到，那直接返回空結果。

緩存雪崩：緩存雪崩是指緩存中數據大批量到過期時間，而查詢數據量巨大，引起數據庫壓力過大甚至down機。

解決辦法：

• 緩存數據的過期時間設置隨機，防止同一時間大量數據過期現象發生。

• 如果緩存數據庫是分布式部署，將熱點數據均勻分布在不同搞得緩存數據庫中。

• 設置熱點數據永遠不過期。

緩存穿透

簡介：緩存穿透是指緩存和數據庫中都沒有的數據，而用戶不斷發起請求，如發起為id為“-1”的數據或id為特別大不存在的數據。這時的用戶很可能是攻擊者，攻擊會導致數據庫壓力過大。

解決辦法：

• 接口層增加校驗，如用戶鑒權校驗，id做基礎校驗，id<=0的直接攔截；

• 從緩存取不到的數據，在數據庫中也沒有取到，這時也可以將key-value對寫為key-null，緩存有效時間可以設置30秒

緩存擊穿

**簡介： **緩存擊穿是指緩存中沒有但數據庫中有的數據，這時由於並發用戶特別多，同時讀緩存沒讀到數據，又同時去數據庫去取數據，引起數據庫壓力瞬間增大

解決方法：

• 設置熱點數據永遠不過期。

• 加互斥鎖

解決 Redis 並發競爭 Key 問題

問題描述：多客戶端同時並發寫一個key，可能本來應該先到的數據后到了，導致數據版本錯了。或者是多客戶端同時獲取一個key，修改值之后再寫回去，只要順序錯了，數據就錯了。一個key的值是1，本來按順序修改為2,3,4，最后是4，但是順序變成了4,3,2，最后變成了2.

我個人認為比較好的方案是分布式鎖+時間戳：

1.整體技術方案

這種情況，主要是准備一個分布式鎖，大家去搶鎖，加鎖的目的實際上就是把並行讀寫改成串行讀寫的方式，從而來避免資源競爭。利用SETNX非常簡單地實現分布式鎖。

2.時間戳

由於key的操作需要順序執行，所以需要保存一個時間戳判斷順序。假設系統B先搶到鎖，將key1設置為{ValueB 7:05}。接下來系統A搶到鎖，發現自己的key1的時間戳早於緩存中的時間戳（7:00<=7:05），那就不做set操作了。

3.什么是分布式鎖

分布式鎖可以基於很多種方式實現，比如zookeeper、redis等，不管哪種方式實現，基本原理是不變的：用一個狀態值表示鎖，對鎖的占用和釋放通過狀態值來標識。

保證緩存與數據庫雙寫時的數據一致性

可能對大部分來說最先想到的方案就是讀請求和寫請求串行化，串到一個內存隊列里去。但是這個方案有着特別大的缺點：它也會導致系統的吞吐量大幅度降低，用比正常情況下多幾倍的機器去支撐線上的一個請求。

最經典的緩存+數據庫讀寫的模式。

讀的時候，先讀緩存，緩存沒有的話，就讀數據庫，然后取出數據后放入緩存，同時返回響應。

更新的時候，先更新數據庫，然后再刪除緩存。

如果喜歡我的文章，歡迎關注我的個人公眾號：程序猿周先森。
****