緩存設計

緩存方案

• 普通緩存

查詢數據時，先查找緩存，如果有延長緩存時間并返回。如果沒有，再去查找數據庫，將查詢的數據再寫到緩存，同時設置過期時間。如果是靜態熱點數據，可以不設置緩存失效時間。

• 冷熱分離

在服務降級時，根據冷熱數據做不同的處理。

• 多級緩存

比如在redis前再加一級緩存JVM，一般是通過map存儲數據。可以類似redis方案更新緩存，也可以使用redis的發布訂閱功能、MQ、canal來實現與數據庫的同步。也可以單獨部署熱點緩存系統，監測到熱點數據主動同步到分布式系統中。
多級緩存時，就不要考慮絕對一致了，否則會增加更大的維護成本。

• 緩存預熱

熱點重建緩存時，通過雙重鎖檢查重建緩存：先查詢，不存在需要重建緩存，重建緩存邏輯加入分布式鎖，僅有一個請求能重建緩存，重建完成后，后面的請求都能獲取到數據了；

緩存問題

緩存穿透

• 什么是緩存穿透

訪問大量不存在的key，緩存和數據庫都沒有，從而導致大量的請求打到數據庫，可能導致數據庫抖動甚至掛掉。

• 導致緩存穿透的原因

通常處于容錯的考慮，存儲層找不到數據不會寫入都緩存層。正常情況是沒問題的，可能導致緩存穿透的的情況如下：
1）自身業務代碼或數據出現問題；
2）一些惡意攻擊、爬蟲等造成大量空命中；

• 如何解決

1）緩存空值且設置過期時間；
2）布隆過濾器
布隆過濾器有個特性：能判斷一個值是否一定不存在，但是不能判斷一個值是否存在。
使用布隆過濾器需要把所有數據提前放入布隆過濾器，并且在增加數據時也要往布隆過濾器里放。通過布隆過濾器判斷key是否存在，如果不存在則直接返回空。
注意：布隆過濾器不能刪除數據，如果要刪除得重新初始化數據。

具體布隆過濾器的工作原理，請參考單獨介紹布隆過濾器的文章。
傳送門：https://blog.csdn.net/u010355502/article/details/132271795

緩存擊穿（失效）

• 什么是緩存擊穿

也叫緩存失效，大量key同時失效導致大量請求同時訪問到數據庫，可能造成數據庫抖動甚至掛掉。

• 導致緩存擊穿的原因

大量已存在的key同時失效。

• 如何解決

批量添加緩存時，分散緩存過期時間，避免相同時間段大量緩存失效。

緩存雪崩

• 什么是緩存雪崩

緩存雪崩指的是緩存層支撐不住或宕掉后，流量會像奔逃的野牛一樣，打向后端存儲層。由于緩存層承載著大量請求，有效地保護了存儲層，但是如果緩存層由于某些原因不能提供服務（比如超大并發過來，緩存層支撐不住，或者由于緩存設計不好，類似大量請求訪問bigkey，導致緩存能支撐的并發急劇下降），于是大量請求都會打到存儲層，存儲層的調用量會暴增，造成存儲層也會級聯宕機的情況。

• 導致緩存雪崩的原因

緩存層沒有起到緩存作用，或者緩存作用沒有達到預期。

• 如何解決

1）保證緩存服務的高可用，比如搭建redis集群。
2）使用隔離組件為后端應用限流、降級。比如使用Sentinel或Hystrix組件，區分非核心數據和核心數據的處理方式。
3）提前演練。在項目上線前， 演練緩存層宕掉后， 應用以及后端的負載情況以及可能出現的問題， 在此基 礎上做一些預案設定。

熱點緩存key重建優化

開發人員使用“緩存+過期時間”的策略既可以加速數據讀寫，又保證數據的定期更新，這種模式基本能夠滿足絕大部分需求。但是有兩個問題如果同時出現，可能就會對應用造成致命的危害：
1）當前key是一個熱點key（例如一個熱門的娛樂新聞），突發性并發量非常大。
2）重建緩存不能在短時間完成，可能是一個復雜計算，例如復雜的SQL、多次IO、多個依賴等。
在緩存失效的瞬間，有大量線程來重建緩存，造成后端負載加大，甚至可能會讓應用崩潰。要解決這個問題主要就是要避免大量線程同時重建緩存。我們可以利用互斥鎖來解決，此方法只允許一個線程重建緩存，其他線程等待重建緩存的線程執行完，重新從緩存獲取數據即可。
偽代碼示例：

String get(String key) {// 從Redis中獲取數據String value = redis.get(key);// 如果value為空，則開始重構緩存if (value == null) {// 只允許一個線程重建緩存，使用nx，并設置過期時間exString mutexKey = "mutext:key:" + key;if (redis.set(mutexKey, "1", "ex 180", "nx")) {// 從數據源獲取數據value = db.get(key);// 回寫Redis，并設置過期時間redis.setex(key, timeout, value);// 刪除key_mutexredis.delete(mutexKey);} else {// 其他線程休息50毫秒后重試Thread.sleep(50);get(key);}}return value;
}

緩存與數據庫雙寫不一致

在大并發下，同時操作數據庫與緩存會存在數據不一致性問題。

• 不一致場景

1）雙寫不一致情況：寫數據庫后更新緩存。線程A將數值10寫數據庫并開始執行更新緩存，此時B將最新數值11寫數據庫并更新了緩存（在線程A更新緩存之前執行完），此時線程A將數值10更新到緩存。那么就有問題了，最新的數值11被歷史數值10覆蓋了，導致數據庫數據與緩存數據不一致。
2）讀寫并發不一致：寫數據庫后刪除緩存，讀數據庫后更新緩存。線程A寫數值10到數據庫后刪除緩存，線程C查詢緩存為空于是查詢數據庫數值為10，再線程C更新緩存之前線程B將數值11（最新值）寫入數據庫并更新緩存成功，此時線程B才將之前查詢到的數值10寫入換存。那么問題來了，最新的數值11被歷史數值10覆蓋了，導致數據庫數據與緩存數據不一致。

• 解決方案

1）對于并發幾率很小的數據（如個人維度的訂單數據、用戶數據等），這種幾乎不用考慮這個問題，很少會發生緩存不一致，可以給緩存數據加上過期時間，每隔一段時間觸發讀的主動更新即可。
2）就算并發很高，如果業務上能容忍短時間的緩存數據不一致（如商品名稱，商品分類菜單等），緩存加上過期時間依然可以解決大部分業務對于緩存的要求。
3）如果不能容忍緩存數據不一致，可以通過加分布式讀寫鎖保證并發讀寫或寫寫的時候按順序排好隊，讀讀的 時候相當于無鎖。
4）也可以用阿里開源的canal通過監聽數據庫的binlog日志及時的去修改緩存，但是引入了新的中間件，增加了系統的復雜度。

• 總結

以上我們針對的都是讀多寫少的情況加入緩存提高性能，如果寫多讀多的情況又不能容忍緩存數據不一致，那就沒必要加緩存了，可以直接操作數據庫。當然，如果數據庫抗不住壓力，還可以把緩存作為數據讀寫的主存儲，異步將數據同步到數據庫，數據庫只是作為數據的備份。放入緩存的數據應該是對實時性、一致性要求不是很高的數據。切記不要為了用緩存，同時又要保證絕對的一致性做大量的過度設計和控制，增加系統復雜性！

key名設計

• 【建議】可讀性和可管理性

以業務名(或數據庫名)為前綴(防止key沖突)，用冒號分隔，比如業務名:表名:id

trade:order:1 

• 【建議】簡潔性

保證語義的前提下，控制key的長度，當key較多時，內存占用也不容忽視，例如：

user:{uid}:friends:messages:{mid} 
簡化為
u:{uid}:fr:m:{mid}

• 【強制】不要包含特殊字符

反例：包含空格、換行、單雙引號以及其他轉義字符

value設計

• 【強制】拒絕大key

什么是bigkey：
在Redis中，一個字符串最大512MB，一個二級數據結構（例如hash、list、set、zset）可以存儲大約40億個（2^32-1）個元素，但實際中如果下面兩種情況，我就會認為它是bigkey。
1）字符串類型
它的big體現在單個value值很大，一般認為超過10KB就是bigkey。
2）非字符串類型
哈希、列表、集合、有序集合，它們的big體現在元素個數太多，元素個數大于5000就是bigkey。
反例：一個包含200萬個元素的list。
非字符串的bigkey，不要使用del刪除，使用hscan、sscan、zscan方式漸進式刪除，同時要注意防止bigkey過期時間自動刪除問題（例如一個200萬的zset設置1小時過期，會觸發del操作，造成阻塞）。

bigkey的危害：
1）導致redis阻塞
2）網絡擁塞
bigkey也就意味著每次獲取要產生的網絡流量較大，假設一個bigkey為1MB，客戶端每秒訪問量為1000，那么每秒產生1000MB的流量，對于普通的千兆網卡（按照字節算是128MB/s）的服務器來說簡直是滅頂之災，而且一般服務器會采用單機多實例的方式來部署，也就是說一個bigkey可能會對其他實例也造成影響，其后果不堪設想。
3）過期刪除
有個bigkey，它安分守己（只執行簡單的命令，例如hget、lpop、zscore等），但它設置了過期時間，當它過期后，會被刪除，如果沒有使用Redis 4.0的過期異步刪除lazyfree-lazy-expire yes，就會存在阻塞Redis的可能性。

bigkey的產生：
一般來說，bigkey的產生都是由于程序設計不當，或者對于數據規模預料不清楚造成的，來看幾個例子：
1）社交類
粉絲列表，如果某些明星或者大v不精心設計，必是bigkey。
2）統計類
例如按天存儲某項功能或者網站的用戶集合，除非沒幾個人用，否則必是bigkey。
3）緩存類
將數據從數據庫load出來序列化放到Redis里，這個方式非常常用，但有兩個地方需要注意，第一，是不是有必要把所有字段都緩存；第二，有沒有相關關聯的數據，有的同學為了圖方便把相關數據都存一個key下，產生bigkey。

bigkey優化：
1）拆
big list： list1、list2、…listN
big hash：可以講數據分段存儲，比如一個大的key，假設存了1百萬的用戶數據，可以拆分成200個key，每個key下面存放5000個用戶數據。
2）不要一次性操作全部數據
如果bigkey不可避免，也要思考一下要不要每次把所有元素都取出來（例如有時候僅僅需要hmget，而不是hgetall），刪除也是一樣，盡量使用優雅的方式來處理。

• 【推薦】選擇合適的數據結構

比如存儲一個對象及屬性時，通過set而不是string設置多次，例如：

set user:1:name tom
set user:1:age 19
set user:1:favor football
改成：
hmset user:1 name tom age 19 favor football

• 【推薦】控制key的生命周期

redis不是垃圾桶，建議使用expire設置過期時間（條件允許可以打散過期時間，防止集中過期，從而導致緩存擊穿）。

命令使用

• 【推薦】 O(N)命令關注N的數量

例如hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明確N的值。有遍歷的需求可以使用hscan、sscan、zscan代替。

• 【推薦】禁用命令

禁止線上使用keys（一次性獲取所有key）、flushall（清空整個redis實例數據）、flushdb（清空當前db的數據）等，通過redis的rename機制禁掉命令，或者使用scan的方式漸進式處理。

• 【推薦】合理使用select

redis的多數據庫較弱，使用數字進行區分，很多客戶端支持較差，同時多業務用多數據庫實際還是單線程處理，會有干擾。并發量大時，還是建議使用redis集群。

• 【推薦】使用批量操作提高效率

注意控制一次批量操作的元素個數（例如500以內，實際也和元素字節數有關）。
1）原生命令
建議使用mget、mset，原生命令是原子操作。
2）非原生命令
可以使用pipeline提高效率，非原子操作。 pipeline需要客戶端和服務端同時支持。

• 【建議】Redis事務功能較弱，不建議過多使用，可以用lua替代

客戶端使用

• 【推薦】避免多個應用使用一個Redis實例

正例：不相干的業務拆分，公共數據做服務化。

• 【推薦】使用帶有連接池的數據庫

使用帶有連接池的數據庫，可以有效控制連接，同時提高效率。
標準使用方式：

JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
jedisPoolConfig.setMaxTotal(5); // 最大連接數
jedisPoolConfig.setMaxIdle(2); // 最大存活數
jedisPoolConfig.setTestOnBorrow(true);JedisPool jedisPool = new JedisPool(jedisPoolConfig, "127.0.0.1", 6379, 3000, null);Jedis jedis = null;
try {jedis = jedisPool.getResource();// 具體的命令jedis.executeCommand()
} catch (Exception e) {logger.error("op key {} error: " + e.getMessage(), key, e);
} finally {// 注意這里不是關閉連接，在JedisPool模式下，Jedis會被歸還給資源池。if (jedis != null) jedis.close();
}

連接池參數：

參數名	含義	默認值	使用建議
maxTotal	資源池中最大連接數	8	設置建議見下面
maxIdle	資源池允許最大空閑的連接數	8	設置建議見下面
minIdle	資源池確保最少空閑的連接數	0	設置建議見下面
blockWhenExhausted	當資源池用盡后，調用者是否要等待。只有當為true時，下面的maxWaitMillis才會生效	true	建議使用默認值
maxWaitMillis	當資源池連接用盡后，調用者的最大等待時間（單位為毫秒）	-1：表示永不超時	不建議使用默認值
testOnBorrow	向資源池借用連接時是否做連接有效性檢測（ping），無效連接會被移除	false	業務量很大時候建議設置為false（多一次ping的開銷）。
testOnReturn	向資源池歸還連接時是否做連接有效性檢測（ping），無效連接會被移除	false	業務量很大時候建議設置為false（多一次ping的開銷）。
jmxEnabled	是否開啟jmx監控，可用于監控	true	建議開啟，但應用本身也要開啟

參數設置建議：

1. maxTotal

最大連接數，早期的版本叫maxActive。
實際上這個是一個很難回答的問題，考慮的因素比較多：
1）業務希望Redis并發量
2）客戶端執行命令時間
3）Redis資源：例如 nodes(例如應用個數) * maxTotal 是不能超過redis的最大連接數maxclients（單個redis實例允許的最大連接數）。
4）資源開銷：例如雖然希望控制空閑連接（連接池此刻可馬上使用的連接），但是不希望因為連接池的頻繁釋放創建連接造成不必靠開銷。
以一個例子說明，假設:

一次命令時間（borrow|return resource + Jedis執行命令(含網絡) ）的平均耗時約為1ms，一個連接的QPS大約是1000；
業務期望的QPS是50000；

那么理論上需要的資源池大小是50000 / 1000 = 50個連接。但事實上這是個理論值，還要考慮到要比理論值預留一些資源，通常來講maxTotal可以比理論值大一些。
但這個值不是越大越好，一方面連接太多占用客戶端和服務端資源，另一方面對于Redis這種高QPS的服務器，一個大命令的阻塞即使設置再大資源池仍然會無濟于事。

2. maxIdle和minIdle

maxIdle實際上才是業務需要的最大連接數，maxTotal是為了給出余量，所以maxIdle不要設置過小，否則會有new Jedis（新連接）開銷。
連接池的最佳性能是maxTotal = maxIdle，這樣就避免連接池伸縮帶來的性能干擾。但是如果并發量不大或者maxTotal設置過高，會導致不必要的連接資源浪費。一般推薦maxIdle可以設置為按上面的業務期望QPS計算出來的理論連接數，maxTotal可以再放大一倍。
minIdle（最小空閑連接數），與其說是最小空閑連接數，不如說是"至少需要保持的空閑連接數"，在使用連接的過程中，如果連接數超過了minIdle，那么繼續建立連接，如果超過了maxIdle，當超過的連接執行完業務后會慢慢被移出連接池釋放掉。
如果系統啟動完馬上就會有很多的請求過來，那么可以給redis連接池做預熱，比如快速的創建一些redis連接，執行簡單命令，類似ping()，快速的將連接池里的空閑連接提升到minIdle的數量。
代碼示例：

List<Jedis> minIdleJedisList = new ArrayList<Jedis>(jedisPoolConfig.getMinIdle());for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {Jedis jedis = null;try {jedis = pool.getResource();minIdleJedisList.add(jedis);jedis.ping();} catch (Exception e) {logger.error(e.getMessage(), e);} finally {// 注意，這里不能馬上close將連接還回連接池，否則最后連接池里只會建立1個連接。// jedis.close();}
}
// 統一將預熱的連接還回連接池
for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {Jedis jedis = null;try {jedis = minIdleJedisList.get(i);// 將連接歸還回連接池jedis.close();} catch (Exception e) {logger.error(e.getMessage(), e);} finally {}
}

總之，要根據實際系統的QPS和調用redis客戶端的規模整體評估每個節點所使用的連接池大小。

• 【建議】高并發下建議客戶端添加熔斷功能（例如sentinel、hystrix）

• 【推薦】設置合理的密碼，如有必要可以使用SSL加密訪問

• 【建議】合理配置key過期清除策略，參考key過期清除策略詳細說明

key過期清除策略

Redis對于過期鍵有三種清除策略：

• 被動刪除

當讀/寫一個已經過期的key時，會觸發惰性刪除策略，直接刪除掉這個過期key。

• 定期主動刪除

由于惰性刪除策略無法保證冷數據被及時刪掉，所以Redis會定期（默認每100ms）主動淘汰一批已過期的key，這里的一批只是部分過期key，所以可能會出現部分key已經過期但還沒有被清理掉的情況，導致內存并沒有被釋放。

• 當前已用內存超過maxmemory限定時，觸發主動清理策略

主動清理策略在Redis 4.0之前一共實現了6種內存淘汰策略，在4.0之后，又增加了2種策略，總共8種：
a) 針對設置了過期時間的key做處理：

volatile-ttl：在篩選時，會針對設置了過期時間的鍵值對，根據過期時間的先后進行刪除，越早過期的越先被刪除。
volatile-random：就像它的名稱一樣，在設置了過期時間的鍵值對中，進行隨機刪除。
volatile-lru：會使用 LRU 算法篩選設置了過期時間的鍵值對刪除。
volatile-lfu：會使用 LFU 算法篩選設置了過期時間的鍵值對刪除。

b) 針對所有的key做處理：

allkeys-random：從所有鍵值對中隨機選擇并刪除數據。
allkeys-lru：使用 LRU 算法在所有數據中進行篩選刪除。
allkeys-lfu：使用 LFU 算法在所有數據中進行篩選刪除。

c) 不處理：

noeviction：不會剔除任何數據，拒絕所有寫入操作并返回客戶端錯誤信息(error) OOM command not allowed when used memory，此時Redis只響應讀操作。

LRU 算法（Least Recently Used，最近最少使用）：
強調時效。淘汰很久沒被訪問過的數據，以最近一次訪問時間作為參考。

LFU 算法（Least Frequently Used，最不經常使用）：
強調使用頻率。淘汰最近一段時間被訪問次數最少的數據，以次數作為參考。

當存在熱點數據時，LRU的效率很好，但偶發性的、周期性的批量操作會導致LRU命中率急劇下降，緩存污染情況比較嚴重。這時使用LFU可能更好點。

根據自身業務類型，配置好maxmemory-policy（默認是noeviction），推薦使用volatile-lru。如果不設置最大內存，當 Redis 內存超出物理內存限制時，內存的數據會開始和磁盤產生頻繁的交換 (swap)，會讓 Redis 的性能急劇下降。
當Redis運行在主從模式時，只有主結點才會執行過期刪除策略，然后把刪除操作”del key”同步到從結點刪除數據。

系統內核參數優化

• vm.swapiness

swap對于操作系統來說比較重要，當物理內存不足時，可以將一部分內存頁進行swap到硬盤上，以解燃眉之急。但世界上沒有免費午餐，swap空間由硬盤提供，對于需要高并發、高吞吐的應用來說，磁盤IO通常會成為系統瓶頸。在Linux中，并不是要等到所有物理內存都使用完才會使用到swap，系統參數swppiness會決定操作系統使用swap的傾向程度。swappiness的取值范圍是0~100，swappiness的值越大，說明操作系統可能使用swap的概率越高，swappiness值越低，表示操作系統更加傾向于使用物理內存。swappiness的取值越大，說明操作系統可能使用swap的概率越高，越低則越傾向于使用物理內存。

如果linux內核版本<3.5，那么swapiness設置為0，這樣系統寧愿swap也不會oom killer（殺掉進程）
如果linux內核版本>=3.5，那么swapiness設置為1，這樣系統寧愿swap也不會oom killer

一般需要保證redis不會被kill掉：

cat /proc/version  # 查看linux內核版本
echo 1 > /proc/sys/vm/swappiness
echo vm.swapiness=1 >> /etc/sysctl.conf

OOM killer 機制是指Linux操作系統發現可用內存不足時，強制殺死一些用戶進程（非內核進程），來保證系統有足夠的可用內存進行分配。

• vm.overcommit_memory（默認0）

0：表示內核將檢查是否有足夠的可用物理內存（實際不一定用滿）供應用進程使用。如果有足夠的可用物理內存，內存申請允許。否則，內存申請失敗，并把錯誤返回給應用進程 。
1：表示內核允許分配所有的物理內存，而不管當前的內存狀態如何。

如果是0的話，可能導致類似fork等操作執行失敗，申請不到足夠的內存空間。
Redis建議把這個值設置為1，就是為了讓fork操作能夠在低內存下也執行成功。

cat /proc/sys/vm/overcommit_memory
echo "vm.overcommit_memory=1" >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1

合理設置文件句柄數

操作系統進程試圖打開一個文件（或者叫句柄），但是現在進程打開的句柄數已經達到了上限，繼續打開會報錯：Too many open files。

ulimit -a  # 查看系統文件句柄數，看open files那項
ulimit -n 65535  # 設置系統文件句柄數

Redis慢日志

Redis慢日志命令說明:
config get slow* # 查詢有關慢日志的配置信息
config set slowlog-log-slower-than 20000  # 設置慢日志使時間閾值,單位微秒，此處為20毫秒，即超過20毫秒的操作都會記錄下來，生產環境建議設置1000，也就是1ms，這樣理論上redis并發至少達到1000，如果要求單機并發達到1萬以上，這個值可以設置為100
config set slowlog-max-len 1024  # 設置慢日志記錄保存數量，如果保存數量已滿，會刪除最早的記錄，最新的記錄追加進來。記錄慢查詢日志時Redis會對長命令做截斷操作，并不會占用大量內存，建議設置稍大些，防止丟失日志
config rewrite # 將服務器當前所使用的配置保存到redis.conf
slowlog len # 獲取慢查詢日志列表的當前長度
slowlog get 5 # 獲取最新的5條慢查詢日志。慢查詢日志由四個屬性組成：標識ID，發生時間戳，命令耗時，執行命令和參數
slowlog reset # 重置慢查詢日志

Redis高性能

redis單線程理解

Redis 的單線程主要是指 Redis 的網絡 IO 和鍵值對讀寫是由一個線程來完成的，這也是 Redis 對外提供鍵值存儲服務的主要流程。但 Redis 的其他功能，比如持久化、異步刪除、集群數據同步等，其實是由額外的線程執行的。

• Redis 單線程為什么還能這么快？

因為它所有的數據都在內存中，所有的運算都是內存級別的運算，而且單線程避免了多線程的切換性能損耗問題。正因為 Redis 是單線程，所以要小心使用 Redis 指令，對于那些耗時的指令(比如keys)，一定要謹慎使用，一不小心就可能會導致 Redis 卡頓。

• Redis 單線程如何處理那么多的并發客戶端連接？

Redis的IO多路復用：redis利用epoll來實現IO多路復用，將連接信息和事件放到隊列中，依次放到文件事件分派器，事件分派器將事件分發給事件處理器。

# 查看redis支持的最大連接數，在redis.conf文件中可修改，# maxclients 10000
127.0.0.1:6379> CONFIG GET maxclients
1) "maxclients"
2) "10000"

Redis與Memcached比較

	redis	memcached
是否基于內存	是	是
值類型	string set hash list …	string
數據持久	有	無
過期策略	有	有
性能	高	高
是否支持虛擬內存	是	否