如今緩存是隨處可見了，如果你的程序還沒有使用到緩存，那可能是你的程序并發(fā)量很低，或?qū)?shí)時(shí)性要求很低。我們公司的ERP在顯示某些報(bào)表時(shí)，每次打開都需要花上幾分鐘的時(shí)間，假如搜索引擎也是這么慢，我想這家搜索引擎早就被淘汰了。
這些ERP報(bào)表是否該引入緩存加速一下呢……
使用緩存，就是在取出數(shù)據(jù)結(jié)果后，暫時(shí)將數(shù)據(jù)存儲在某些可以快速存取的位置（例如各種NoSQL如Redis，HBase，又或MemoryCache等等），于是就可以讓這些耗時(shí)的數(shù)據(jù)結(jié)果多次重復(fù)的利用，不必每次重復(fù)請求相同的數(shù)據(jù)，節(jié)省CPU和I/O，加速程序的響應(yīng)。
使用緩存能讓加載數(shù)據(jù)的延遲降低，I/O操作減少，從而性能得到提高。
緩存使用起來很容易，但是保持緩存的一致性卻困難得多。有一些前人總結(jié)的經(jīng)驗(yàn)和方法，我們可以借鑒一下。
緩存重點(diǎn)在于寫入的時(shí)候，相關(guān)數(shù)據(jù)的更新問題，如果數(shù)據(jù)一直沒有更新或刪除操作，那緩存就不會存在臟數(shù)據(jù)一說了。
關(guān)于緩存寫入，至少有4種寫入的策略。
write-through
這個(gè)動作發(fā)生在Cache層。是指在寫數(shù)據(jù)時(shí)，同時(shí)寫入到緩存和DB中，這個(gè)寫入操作認(rèn)為是一個(gè)單一的事務(wù)，也就是說，在更新Cache時(shí)，我們先更新了Cache中的數(shù)據(jù)，然后接著更新Db中的數(shù)據(jù)。在DB的數(shù)據(jù)完成更新前，程序還不會返回，一直等到數(shù)據(jù)庫存儲的結(jié)果。可想而知，這種做法不會給寫入數(shù)據(jù)帶來更高的性能。
我用向下的箭頭表示一個(gè)函數(shù)的調(diào)用，綠色的虛線表示函數(shù)的返回，我拙劣的語言能力還難以描述清楚，但如果把這個(gè)圖寫成程序，就像這個(gè)樣子：
public class UserLogic
{
public void WriteToDb(UserEntity user)
{
CacheManager cache = GetCacheManager();
cache.WriteToDb(user);
}
}
public class CacheManager
{
public void WriteToDb(UserEntity user)
{
cacheStore.Set(user.cacheKey, user.ToJson());
dbManager.UpdateSqlServer(user);
}
}
UserLogic類放在Cache層之上，非Cache層，比如應(yīng)用層、領(lǐng)域?qū)印⒛衬尺壿媽又悺腤riteToDb函數(shù)內(nèi)部并沒有關(guān)于Db執(zhí)行的代碼，它不關(guān)心Db，它直接調(diào)用了Cache層的CacheManager的WriteToDb()。
CacheManager.WriteToDb()內(nèi)部先去更新了Cache，然后并沒有立刻返回，接著又將user寫入了MSSQL里面。
所以我說，這種做法不會給寫入數(shù)據(jù)帶來更高的性能。
write-around
發(fā)生在Cache層，直接寫入數(shù)據(jù)到數(shù)據(jù)庫，不必寫到緩存中。這個(gè)不必過多的解釋，緩存的數(shù)據(jù)應(yīng)該被立即過期（否則數(shù)據(jù)就會不一致了）
當(dāng)我寫這篇文章的時(shí)候，發(fā)現(xiàn)確實(shí)偽代碼比我無力的中文解釋更清晰，那么write-around的偽代碼呢？
public class UserLogic
{
public void WriteToDb(UserEntity user)
{
cacheStore.Invalidate(user.caheKey);
dbManager.UpdateSqlServer(user);
}
}
應(yīng)用層繞過了Cache層，直接調(diào)用Db寫入了數(shù)據(jù)庫。
write-behind
還是發(fā)生在Cache層，剛開始時(shí)，寫入到緩存中，當(dāng)設(shè)定的緩存容量達(dá)到上限，或等到一定的時(shí)間間隔后，再寫到數(shù)據(jù)庫中。
換句話說，寫入到數(shù)據(jù)庫是有條件的。當(dāng)我們要存入數(shù)據(jù)庫時(shí)，一定是有一批數(shù)據(jù)甚至是一大批數(shù)據(jù)都需要從緩存中寫到數(shù)據(jù)庫中。我們想象這是一個(gè)寫入的隊(duì)列，要寫入的數(shù)據(jù)源源不斷的放入到這個(gè)隊(duì)列中。此時(shí)，我們可以使用服務(wù)器上的另外一個(gè)進(jìn)程獨(dú)立的處理這個(gè)隊(duì)列。
如果在寫入數(shù)據(jù)庫前某些數(shù)據(jù)又發(fā)生了修改，因?yàn)樵摂?shù)據(jù)還沒有被插入到數(shù)據(jù)庫，所以這個(gè)隊(duì)列中對應(yīng)的那個(gè)元素也會發(fā)生相應(yīng)的更改，以保證最后插入到數(shù)據(jù)庫中的是最新的數(shù)據(jù)。
public class UserLogic
{
public void WriteToDb(UserEntity user)
{
CacheManager cache = GetCacheManager();
cache.WriteToDb(user);
}
}
public class CacheManager
{
public void WriteToDb(UserEntity user)
{
cacheStore.AddToQueue(user.cacheKey, user.ToJson());
}
}
public class DbDaemon
{
public void Watch()
{
while(someConditionIsOK())
{
UserEntity user = cacheStore.UserDequeue();
dbManager.WriteToDb(user);
}
}
}
在這種模式里，應(yīng)用層UserLogic照例調(diào)用Cache層進(jìn)行更新，但是CacheManager內(nèi)的WriteToDb函數(shù)已經(jīng)發(fā)生了變化，它將user的內(nèi)容存放在一個(gè)隊(duì)列中（當(dāng)然了，同時(shí)也得更新緩存）。然后程序的就返回了。
可是，數(shù)據(jù)怎么放到Db里面去呢？
這技巧放在DbDaemon里，DbDaemon位于另外一個(gè)exe中，是獨(dú)立的應(yīng)用程序（比如這是個(gè)Windows Service），當(dāng)條件滿足時(shí)，這個(gè)程序到隊(duì)列里面去取值，取出來再放更新到數(shù)據(jù)庫。
于是乎，UserLogic層只是更新了緩存而已，這會最大限度的保證寫入的效率。
write-behind至少帶來這幾點(diǎn)好處：
- 性能的提升，因?yàn)槌绦虿辉傩枰却龜?shù)據(jù)庫的寫入操作，當(dāng)數(shù)據(jù)寫入緩存成功后，程序立刻返回了。
- 降低了數(shù)據(jù)庫的負(fù)載，因?yàn)槊看味际桥康牟迦氲綌?shù)據(jù)庫中。如果在正式插入數(shù)據(jù)庫前，數(shù)據(jù)還有更改，這會讓它的優(yōu)勢更明顯。例如，插入數(shù)據(jù)庫是數(shù)據(jù)是{id:1, name:”張三”}，這條數(shù)據(jù)先被放入隊(duì)列但還沒有被處理。后來這條數(shù)據(jù)又被更改成了李四王五趙六，無論被改了多少次，最終都是以最后的”趙六”為最終結(jié)果，數(shù)據(jù)庫實(shí)際上只有一次插入操作。
- 程序還提高了可靠性。想象如果數(shù)據(jù)庫服務(wù)器發(fā)生了宕機(jī)，程序并不會立即出現(xiàn)問題，緩存的寫入隊(duì)列還在起作用。
- 并發(fā)性能的提高，如果程序需要處理更多的并發(fā)，可以提高寫入數(shù)據(jù)庫的間隔，減少數(shù)據(jù)庫的壓力。
但是，使用write-behind也是有挑戰(zhàn)的，如果要使用write-behind，至少有這幾點(diǎn)要考慮： - 由于數(shù)據(jù)庫的更新是滯后于cache的，這意味著數(shù)據(jù)庫的事務(wù)只能成功不能失敗。我們想象一下客戶已經(jīng)提交了購買訂單，cache更新成功，訂單放入緩存的隊(duì)列，但是20分鐘后，嘗試寫入到SQL數(shù)據(jù)庫時(shí)，出現(xiàn)了數(shù)據(jù)庫插入失敗的尷尬局面。
- 如果第三方的應(yīng)用，或者是人為原因去更新了數(shù)據(jù)庫，這可能導(dǎo)致寫入隊(duì)列中的數(shù)據(jù)與數(shù)據(jù)庫中數(shù)據(jù)出現(xiàn)沖突，從而導(dǎo)致數(shù)據(jù)回寫失敗。比如緩存中的一個(gè)主鍵是97033，正待寫入到數(shù)據(jù)庫。結(jié)果另外的某程序搶先一步插入了97033，那么就悲劇了。
cache-aside
發(fā)生在應(yīng)用層，應(yīng)用層保證緩存結(jié)果同DB的數(shù)據(jù)一致性，應(yīng)用層來負(fù)責(zé)寫入到數(shù)據(jù)庫和整理緩存，緩存層則不必插手此事。
public class UserLogic
{
public void WriteToDb(UserEntity user)
{
cacheStore.Set(user.cacheKey, user);
dbManager.WriteToDb(user);
}
}
在這種模式里，所有動作就在應(yīng)用層里發(fā)生，它自己更新Cache，自己寫到Db，愛怎么干怎么干。
4種寫入數(shù)據(jù)的方式各有各的特點(diǎn)，可以根據(jù)項(xiàng)目自身的特點(diǎn)加以選擇。
數(shù)據(jù)的讀取就簡單得多了，有這樣兩種方式。
read-through
讀取數(shù)據(jù)時(shí)，先嘗試從緩存中取得，如果緩存中沒有，那么再從數(shù)據(jù)庫中讀取，而后也將數(shù)據(jù)放入緩存中，以便下次讀取。
refresh-ahead
簡單的說就是在緩存數(shù)據(jù)過期前，能自動的刷新緩存數(shù)據(jù)。舉個(gè)例子來說，某條數(shù)據(jù)在緩存中，過期時(shí)間是60秒。我們給他設(shè)置一個(gè)參數(shù)，比如是0.8，60x0.8=48秒，那么在前48秒訪問該數(shù)據(jù)，就照正常的取法，直接返回緩存中的數(shù)據(jù)。當(dāng)在48-60秒這個(gè)區(qū)間取數(shù)據(jù)時(shí)，緩存先將之前緩存的結(jié)果返回給外部應(yīng)用程序，然后異步的再從數(shù)據(jù)庫去更新緩存中的值，以盡可能的保證緩存的值是最新的。如果取數(shù)據(jù)的的時(shí)候超過了60秒，就安裝read-through的方式。
Refresh-ahead是對未來數(shù)據(jù)的訪問情形的估算，我們猜測這個(gè)數(shù)據(jù)在過期后，仍然可能被頻繁的訪問，那么這種設(shè)計(jì)的策略獲得的優(yōu)勢會更明顯。
但是，如果有大量的數(shù)據(jù)是用refresh-ahead策略，但是這個(gè)數(shù)據(jù)被重新緩存后，又一次都沒有被訪問過，那這個(gè)策略就是很失算的了。
那么，有人可能會問，既然如此，我把過期的時(shí)間延長不就好了，之前60秒過期，改成6000秒過期，這樣就不會用Refresh-ahead策略來刷新數(shù)據(jù)了。
然而，事實(shí)是緩存的數(shù)據(jù)越久，出現(xiàn)臟數(shù)據(jù)的可能性也就越大，更重要的是，如果你的估算也是失誤的，大量的超期緩存數(shù)據(jù)沒有被實(shí)際訪問，那么你就浪費(fèi)了很多的內(nèi)存，做了無用的事情，這也是應(yīng)該避免的。
緩存策略介紹完畢。再加上偽代碼，相信我還是說得比較清楚了。
