前言：

簡單來說Redis就是一個數據庫，不過與傳統的資料庫不同的是Redis的資料是存在與記憶體中的，所以存寫速度非常快，因此Redis被廣泛應用於快取方向。另外Redis也經常用來做分散式鎖。Redis提供了多種資料型別來支援不同的業務場景需求。除此之外，Redis還支援事務、持久化、LUA指令碼、LRU驅動事件、多種叢集方案。

正文：

question：

那麼為什麼要用快取呢？或者為什麼要用Redis呢？

原因主要有兩點：

一、高效能

二、高併發

 為什麼要用Redis而不用map或者guava做快取？

快取分為本地快取和分散式快取。

以 Java 為例，使用自帶的 map 或者 guava 實現的是本地快取，最主要的特點是輕量以及快速

使用 redis 或 memcached 之類的稱為分散式快取，在多例項的情況下，各例項共用一份快取資料，快取具有一致性。缺點是需要保持 redis 或 memcached服務的高可用，整個程式架構上較為複雜。

Redis和Memcached的區別？

Redis 記憶體淘汰機制？（MySQL裡有2000w資料，Redis中只存 20w的資料，如何保證Redis中的資料都是熱點資料？）

Redis中有個設定時間過期的功能，即對儲存在 redis 資料庫中的值可以設定一個過期時間。作為一個快取資料庫，這是非常實用的。（定期刪除、惰性刪除）

但是僅僅通過設定過期時間還是存在問題的，例如定期刪除漏掉很多過期的key，並且也沒有及時的查，也就是沒有走惰性刪除，那麼過期的key存在與記憶體中，就會導致Redis記憶體耗盡。

 Redis提供了6種資料淘汰策略：

1. volatile-lru：從已設定過期時間的資料集（server.db[i].expires）中挑選最近最少使用的資料淘汰

2. volatile-ttl：從已設定過期時間的資料集（server.db[i].expires）中挑選將要過期的資料淘汰

3. volatile-random：從已設定過期時間的資料集（server.db[i].expires）中任意選擇資料淘汰

4. allkeys-lru：當記憶體不足以容納新寫入資料時，在鍵空間中，移除最近最少使用的key（這個是最常用的）.

5. allkeys-random：從資料集（server.db[i].dict）中任意選擇資料淘汰

6. no-eviction：禁止驅逐資料，也就是說當記憶體不足以容納新寫入資料時，新寫入操作會報錯。

怎麼保證 redis 掛掉之後再重啟資料可以進行恢復？

Redis不同於Memcached很重要的一點就是，Redis支援持久化，而且支援兩種不同的持久化操作，而Memcached不支援持久化。Redis的一種持久

化方式叫快照（snapshotting，RDB）,另一種方式是隻追加檔案（append-only fifile,AOF）

 1.快照（snapshotting）持久化（RDB）

 快照持久化是Redis預設採用的持久化方式，在redis.conf配置檔案中預設有此下配置：

save 900 1 //在900秒(15分鐘)之後，如果至少有1個key發生變化，Redis就會自動觸發BGSAVE命令 建立快照。
save 300 10 //在300秒(5分鐘)之後，如果至少有10個key發生變化，Redis就會自動觸發BGSAVE命令創 建快照。 
save 60 10000 //在60秒(1分鐘)之後，如果至少有10000個key發生變化，Redis就會自動觸發BGSAVE命令創 建快照。

2.AOF（append-only fifile）持久化  

與快照持久化相比，AOF持久化 的實時性更好，因此已成為主流的持久化方案。預設情況下Redis沒有開啟 AOF（append only fifile）方式的持久化，可以通過appendonly引數開啟：  

appendonly yes

開啟AOF持久化後每執行一條會更改Redis中的資料的命令，Redis就會將該命令寫入硬碟中的AOF檔案。AOF檔案的 儲存位置和RDB檔案的位置相同，都是通過dir引數設定的，預設的檔名是appendonly.aof。

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

appendfsync always //每次有資料修改發生時都會寫入AOF檔案,這樣會嚴重降低Redis的速度 
appendfsync everysec //每秒鐘同步一次，顯示地將多個寫命令同步到硬碟(建議)
appendfsync no //讓作業系統決定何時進行同步

補充：Redis 4.0 對於持久化機制的優化

Redis 4.0 開始支援 RDB 和 AOF 的混合持久化（預設關閉，可以通過配置項 aof-use-rdb-preamble 開啟）。

如果把混合持久化開啟，AOF 重寫的時候就直接把 RDB 的內容寫到 AOF 檔案開頭。這樣做的好處是可以結合 RDB

和 AOF 的優點, 快速載入同時避免丟失過多的資料。當然缺點也是有的， AOF 裡面的 RDB 部分是壓縮格式不再是

AOF 格式，可讀性較差。

小結：

後面會繼續分享Redis的事務、快取雪崩、快取穿透、併發競爭key、雙寫時資料一致性等問題，歡迎繼續關注！