摘要：分布式緩存應(yīng)用和緩存分離，緩存多帶帶作為一個系統(tǒng)多帶帶部署，多個應(yīng)用可以共享的訪問緩存。通過靜態(tài)變量一次獲取所有的數(shù)據(jù)緩存起來避免頻繁的讀取。類似的分布式緩存實現(xiàn)方案還有的集群方案，其實現(xiàn)思想和的實現(xiàn)思想大相徑庭。

提到緩存，那么緩存是什么，為什么需要緩存？

如果知道一點點計算機方面的知識就會知道，計算機的構(gòu)造也是由多級緩存->硬盤一起來構(gòu)造計算機的數(shù)據(jù)存儲。當(dāng)然這里不是來撥開計算機的神秘面紗來看透緩存的本質(zhì)設(shè)計的，此篇想來講講我們在軟件構(gòu)造的過程中為了讓系統(tǒng)能提高數(shù)據(jù)的讀寫效率，同時減少網(wǎng)絡(luò)/IO延遲而進行的緩存設(shè)計。

命中率--緩存中取到數(shù)據(jù)的請求/總的數(shù)據(jù)請求次數(shù)

緩存空間--既然是緩存肯定緩存的數(shù)據(jù)存儲量不夠?qū)嶋H的存儲系統(tǒng)（文件系統(tǒng)、數(shù)據(jù)庫等）那么大，如何定義緩存的存儲上限。

淘汰策略--既然緩存有命中率、最大數(shù)據(jù)存儲空間，那就不可避免的引入了當(dāng)存儲空間接近最大存儲空間的時候如何將一些緩存數(shù)據(jù)從緩存中清除出去，采用什么樣的策略。

淘汰策略

FIFO 先進來的優(yōu)先淘汰。應(yīng)用場景：時效性要求比較高的場景，優(yōu)先保障最新的數(shù)據(jù)能被緩存命中。

LFU（least frequently used） 最近最少頻次使用的數(shù)據(jù)被優(yōu)先淘汰。應(yīng)用場景：在保障高頻數(shù)據(jù)可用的場景可以選用這類策略。

LRU（least recently used） 最近最少使用的數(shù)據(jù)優(yōu)先淘汰。應(yīng)用場景：熱點數(shù)據(jù)使用場景

從硬件角度進行區(qū)分：內(nèi)存、硬盤

從技術(shù)實現(xiàn)上進行區(qū)分：內(nèi)存、硬盤文件、數(shù)據(jù)庫

緩存從大類上可以分為本地緩存和分布式緩存。
本地緩存：本地緩存和應(yīng)用在同一個進程里面，數(shù)據(jù)請求沒有額外的網(wǎng)絡(luò)開銷，能快速得到響應(yīng)，對于單應(yīng)用沒有集群支持的系統(tǒng)或者擁有集群的情況下但是集群中各個節(jié)點的緩存無需互通的場景下比較合適。缺點：應(yīng)用進程和本地緩存是強綁定在一起的，對于多應(yīng)用的情況下，每個應(yīng)用程序都要維護一套多帶帶的緩存，無法共享各自的緩存對內(nèi)存資源是一種浪費。
分布式緩存：應(yīng)用和緩存分離，緩存多帶帶作為一個系統(tǒng)多帶帶部署，多個應(yīng)用可以共享的訪問緩存。

本地緩存相信大家在進行編程的過程中會經(jīng)常使用到。非常簡單的場景下會直接通過Map結(jié)構(gòu)在局部對象中直接構(gòu)建緩存存儲結(jié)構(gòu)，局部變量實現(xiàn)緩存。

private ConcurrentHashMap localCache = new ConcurrentHashMap();

這種局部緩存只能在類自身的作用域中能訪問到，而且這種簡單的緩存數(shù)據(jù)結(jié)構(gòu)無需關(guān)注存取、淘汰緩存等策略。
應(yīng)用場景：在一次請求的過程中緩存此次請求中的重復(fù)數(shù)據(jù)請求，避免過多的無用請求、序列化反序列話對CPU造成的壓力，請求結(jié)束后清空緩存。
靜態(tài)變量實現(xiàn)緩存，基本實現(xiàn)思路和上面的局部緩存一樣的原理，主要是將其可見度擴大到了本應(yīng)用程序，在本引用程序都是可見的。通過靜態(tài)變量一次獲取所有的數(shù)據(jù)緩存起來避免頻繁的I/O讀取。
應(yīng)用場景：一次緩存所有的數(shù)據(jù)，如應(yīng)用配置信息、一些數(shù)據(jù)量不大但是應(yīng)用需要頻繁使用到的一些數(shù)據(jù)，通過開關(guān)推送的方式來refresh內(nèi)存。

這里通過redis作為緩存實現(xiàn)來探討下分布式緩存。
根據(jù)應(yīng)用對緩存的數(shù)據(jù)存儲量的需求，可以通過redis單機或者集群的方式來實現(xiàn)緩存。下面我們主要是來聊聊通過redis集群的方式來實現(xiàn)分布式緩存：

統(tǒng)一接入層暴露統(tǒng)一的操作緩存的API，客戶端通過API像和使用單機緩存一樣透明的使用分布式緩存集群。

類似的分布式緩存實現(xiàn)方案還有memcache的集群方案，其實現(xiàn)思想和redis的實現(xiàn)思想大相徑庭。memcache主要是通過客戶端的的一致性Hash算法來實現(xiàn)集群實例選址操作。

Redis是一個內(nèi)存存儲系統(tǒng)，通常情況下都是被使用作為緩存系統(tǒng)，但是它本身是支持對內(nèi)存中的數(shù)據(jù)進行持久化的操作的，其支持兩種持久化的方式：

snapshot--save/bgsave兩個命令可以對其進行持久化操作。save是主進程進行的操作會將所有的對外服務(wù)操作全部block掉；bgsave采用子線程寫時復(fù)制技術(shù)進行持久化，主進程繼續(xù)對外提供服務(wù)，但是寫時復(fù)制技術(shù)在寫入請求達到一個量級的過程中可能會出現(xiàn)內(nèi)存瞬間翻倍的情況，所以在一般情況下Redis的內(nèi)存使用量不能操作物理內(nèi)存的二分之一，不然會存在潛在的數(shù)據(jù)丟失的風(fēng)險。同時在進行持久化得過程中也會有大量的I/O操作會對系統(tǒng)造成負載壓力大。

aof--在文件末尾追加對內(nèi)存的修改操作。這也會存在個嚴重的問題：當(dāng)count++循環(huán)100次的時候是不是在aof文件末尾追加了100條同樣的+1的操作，其實可以用一個語句count+=100來進行替換。所以像這種情況下aof文件中的語句會出現(xiàn)逐漸龐大的情況，需要定期去rewrite aof文件。在rewrite aof文件的過程中，對內(nèi)存的修改語句沒法寫入到aof文件，所以Redis會將rewrite期間對內(nèi)存修改的命令寫入緩存，最后統(tǒng)一寫入aof文件中。

Redis的持久化方案使用了buffer I/O，即會使用物理內(nèi)存的page cache。計算機在發(fā)現(xiàn)page cache不足的時候會對cache和硬盤進行swap的操作，在持久化的同時可能會導(dǎo)致系統(tǒng)的不穩(wěn)定或者崩潰的現(xiàn)象，所以Redis需要實時針對內(nèi)存的使用量進行監(jiān)控告警。大多數(shù)的數(shù)據(jù)庫存儲系統(tǒng)會使用Direct I/O來繞過page cache并自行維護一個數(shù)據(jù)的cache。

Redis主從同步方式中包含全量/增量數(shù)據(jù)同步。第3步ACK之前都是同步snapshot文件，通過snapshot文件快速構(gòu)建一個和Master一直的內(nèi)存數(shù)據(jù)，后面增量同步的過程中按照追加到aof文件中的內(nèi)存修改命令進行同步修改Slave中的內(nèi)存數(shù)據(jù)。

Redis中會多帶帶針對帶有過期時間的Key進行統(tǒng)一存儲，針對這些帶有過期時間的Key有三種淘汰策略。

被動刪除。對Key進行訪問時，檢查超時時間，如果超時則刪除K-V。

主動刪除。定期調(diào)用清理過期Key的方法。
a) 隨機抽取100個Key
b) 刪除過期Key
c) 若刪除過期key數(shù)量>25則重復(fù)a)
整個主動刪除是有時間限制限制的，否則時間太長會影響緩存對外服務(wù)的吞吐量。

內(nèi)存空間達到Maxmemory時進行清理。阻塞服務(wù)對Key進行過期刪除操作，直到低于Maxmemory值，否則服務(wù)一直阻塞。

spring提供了注解緩存的實現(xiàn)方案，目前還沒有實踐過，后面對spring進行深入學(xué)習(xí)其注解緩存實現(xiàn)方案后更新。