C# .NET 中的緩存實(shí)現(xiàn)
C# .NET 中的緩存實(shí)現(xiàn)
軟件開發(fā)中最常用的模式之一是緩存。這是一個(gè)簡單但非常有效的概念，這個(gè)想法的核心是記錄過程數(shù)據(jù)，重用操作結(jié)果。當(dāng)執(zhí)行繁重的操作時(shí)，我們會(huì)將結(jié)果保存在我們的緩存容器中。下次我們需要該結(jié)果時(shí)，我們將從緩存容器中拉出它，而不是再次執(zhí)行繁重的操作。
例如，要獲取一個(gè)人的頭像，您可能需要訪問數(shù)據(jù)庫。我們不會(huì)每次都執(zhí)行那次旅行，而是將 Avatar 保存在緩存中，每次需要時(shí)從內(nèi)存中提取它。
緩存非常適用于不經(jīng)常更改的數(shù)據(jù)。或者甚至更好，永遠(yuǎn)不會(huì)改變。不斷變化的數(shù)據(jù)，比如當(dāng)前機(jī)器的時(shí)間不應(yīng)該被緩存，否則你會(huì)得到錯(cuò)誤的結(jié)果。
進(jìn)程內(nèi)緩存、持久性進(jìn)程內(nèi)緩存和分布式緩存
有 3 種類型的緩存：
?In-Memory Cache用于在單個(gè)進(jìn)程中實(shí)現(xiàn)緩存。當(dāng)進(jìn)程終止時(shí)，緩存也隨之終止。如果您在多臺(tái)服務(wù)器上運(yùn)行相同的進(jìn)程，您將為每臺(tái)服務(wù)器提供一個(gè)單獨(dú)的緩存。?持久性進(jìn)程內(nèi)緩存是指在進(jìn)程內(nèi)存之外備份緩存。它可能在文件中，也可能在數(shù)據(jù)庫中。這比較困難，但如果您的進(jìn)程重新啟動(dòng)，緩存不會(huì)丟失。最適合在獲取緩存項(xiàng)的情況下使用范圍廣泛，并且您的進(jìn)程往往會(huì)重新啟動(dòng)很多。?分布式緩存是指您希望為多臺(tái)機(jī)器共享緩存。通常，它將是多個(gè)服務(wù)器。使用分布式緩存，它存儲(chǔ)在外部服務(wù)中。這意味著如果一臺(tái)服務(wù)器保存了一個(gè)緩存項(xiàng)，其他服務(wù)器也可以使用它。像Redis[1]這樣的服務(wù)非常適合這一點(diǎn)。
我們將只討論進(jìn)程內(nèi)緩存。
早期做法
讓我們用 C# 創(chuàng)建一個(gè)非常簡單的緩存實(shí)現(xiàn)：
public class NaiveCache<TItem>{Dictionary<object, TItem> _cache = new Dictionary<object, TItem>();public TItem GetOrCreate(object key, Func<TItem> createItem){if (!_cache.ContainsKey(key)){_cache[key] = createItem();}return _cache[key];}}
用法：
var _avatarCache = new NaiveCache<byte[]>();// ...var myAvatar = _avatarCache.GetOrCreate(userId, () => _database.GetAvatar(userId));
這個(gè)簡單的代碼解決了一個(gè)關(guān)鍵問題。要獲取用戶的頭像，只有第一個(gè)請求才會(huì)真正執(zhí)行到數(shù)據(jù)庫的訪問。然后將頭像數(shù)據(jù) ( byte[]) 保存在進(jìn)程內(nèi)存中。對頭像的所有后續(xù)請求都將從內(nèi)存中提取，從而節(jié)省時(shí)間和資源。
但是，正如編程中的大多數(shù)事情一樣，沒有什么是那么簡單的。由于多種原因，上述解決方案并不好。一方面，這個(gè)實(shí)現(xiàn)不是線程安全的。從多個(gè)線程使用時(shí)可能會(huì)發(fā)生異常。除此之外，緩存的項(xiàng)目將永遠(yuǎn)留在內(nèi)存中，這實(shí)際上非常糟糕。
這就是我們應(yīng)該從緩存中刪除項(xiàng)目的原因：
1.緩存會(huì)占用大量內(nèi)存，最終導(dǎo)致內(nèi)存不足異常和崩潰。2.高內(nèi)存消耗會(huì)導(dǎo)致GC 壓力（又名內(nèi)存壓力）。在這種狀態(tài)下，垃圾收集器的工作量超出其應(yīng)有的水平，從而損害了性能。3.如果數(shù)據(jù)發(fā)生變化，可能需要刷新緩存。我們的緩存基礎(chǔ)設(shè)施應(yīng)該支持這種能力。
為了處理這些問題，緩存框架具有驅(qū)逐策略（又名移除策略）。這些是根據(jù)某些邏輯從緩存中刪除項(xiàng)目的規(guī)則。常見的驅(qū)逐政策有：
?無論如何，絕對過期策略將在固定時(shí)間后從緩存中刪除項(xiàng)目。?如果在固定的時(shí)間段內(nèi)未訪問某個(gè)項(xiàng)目，則滑動(dòng)過期策略將從緩存中刪除該項(xiàng)目。因此，如果我將過期時(shí)間設(shè)置為 1 分鐘，只要我每 30 秒使用一次，該項(xiàng)目就會(huì)一直保留在緩存中。一旦我超過一分鐘不使用它，該物品就會(huì)被驅(qū)逐。?大小限制策略將限制緩存內(nèi)存大小。
現(xiàn)在我們知道我們需要什么，讓我們繼續(xù)尋找更好的解決方案。
更好的解決方案
作為一名博主，令我非常沮喪的是，微軟已經(jīng)創(chuàng)建了一個(gè)很棒的緩存實(shí)現(xiàn)。這剝奪了我自己創(chuàng)建類似實(shí)現(xiàn)的樂趣，但至少我寫這篇博文的工作量減少了。
我將向您展示微軟的解決方案，如何有效地使用它，然后在某些場景中如何改進(jìn)它。
System.Runtime.Caching/MemoryCache 與 Microsoft.Extensions.Caching.Memory
Microsoft 有 2 個(gè)解決方案 2 個(gè)不同的 NuGet 包用于緩存。兩者都很棒。根據(jù) Microsoft 的建議[2]，更喜歡使用，Microsoft.Extensions.Caching.Memory因?yàn)樗c Asp.NET Core 集成得更好。它可以很容易地注入[3]到 Asp .NET Core 的依賴注入機(jī)制中。
這是一個(gè)基本示例Microsoft.Extensions.Caching.Memory：
public class SimpleMemoryCache<TItem>{private MemoryCache _cache = new MemoryCache(new MemoryCacheOptions());public TItem GetOrCreate(object key, Func<TItem> createItem){TItem cacheEntry;if (!_cache.TryGetValue(key, out cacheEntry))// Look for cache key.{// Key not in cache, so get data.cacheEntry = createItem();// Save data in cache._cache.Set(key, cacheEntry);}return cacheEntry;}}
用法：
var _avatarCache = new SimpleMemoryCache<byte[]>();// ...var myAvatar = _avatarCache.GetOrCreate(userId, () => _database.GetAvatar(userId));
這和我自己的非常相似NaiveCache，所以有什么改變？嗯，一方面，這是一個(gè)線程安全的實(shí)現(xiàn)。您可以一次從多個(gè)線程安全地調(diào)用它。
第二件事是MemoryCache允許我們之前談到的所有驅(qū)逐政策。下面是一個(gè)例子：
具有驅(qū)逐策略的 IMemoryCache：
public class MemoryCacheWithPolicy<TItem>{private MemoryCache _cache = new MemoryCache(new MemoryCacheOptions(){SizeLimit = 1024});public TItem GetOrCreate(object key, Func<TItem> createItem){TItem cacheEntry;if (!_cache.TryGetValue(key, out cacheEntry))// Look for cache key.{// Key not in cache, so get data.cacheEntry = createItem();var cacheEntryOptions = new MemoryCacheEntryOptions().SetSize(1)//Size amount//Priority on removing when reaching size limit (memory pressure).SetPriority(CacheItemPriority.High)// Keep in cache for this time, reset time if accessed..SetSlidingExpiration(TimeSpan.FromSeconds(2))// Remove from cache after this time, regardless of sliding expiration.SetAbsoluteExpiration(TimeSpan.FromSeconds(10));// Save data in cache._cache.Set(key, cacheEntry, cacheEntryOptions);}return cacheEntry;}}
1.SizeLimit被添加到MemoryCacheOptions. 這為我們的緩存容器添加了基于大小的策略。大小沒有單位。相反，我們需要在每個(gè)緩存條目上設(shè)置大小數(shù)量。在這種情況下，我們每次將金額設(shè)置為 1 SetSize(1)。這意味著緩存限制為 1024 個(gè)項(xiàng)目。2.當(dāng)我們達(dá)到大小限制時(shí)，應(yīng)該刪除哪個(gè)緩存項(xiàng)？您實(shí)際上可以使用.SetPriority(CacheItemPriority.High). 級別為Low、Normal、High和NeverRemove。3.SetSlidingExpiration(TimeSpan.FromSeconds(2))添加了，它將滑動(dòng)過期時(shí)間設(shè)置為 2 秒。這意味著如果一個(gè)項(xiàng)目在 2 秒內(nèi)未被訪問，它將被刪除。4.SetAbsoluteExpiration(TimeSpan.FromSeconds(10))添加了，將絕對過期時(shí)間設(shè)置為 10 秒。這意味著該項(xiàng)目將在 10 秒內(nèi)被驅(qū)逐，如果它還沒有。
除了示例中的選項(xiàng)之外，您還可以設(shè)置一個(gè)RegisterPostEvictionCallback委托，該委托將在項(xiàng)目被驅(qū)逐時(shí)調(diào)用。
這是一個(gè)非常全面的功能集。它讓你想知道是否還有什么要添加的。實(shí)際上有幾件事。
問題和缺失的功能
在這個(gè)實(shí)現(xiàn)中有幾個(gè)重要的缺失部分。
1.雖然您可以設(shè)置大小限制，但緩存實(shí)際上并不監(jiān)控 gc 壓力。如果真的監(jiān)測，壓力大的時(shí)候可以收緊政策，壓力小的時(shí)候可以放松政策。2.當(dāng)多個(gè)線程同時(shí)請求同一個(gè)項(xiàng)目時(shí)，請求不會(huì)等待第一個(gè)完成。該項(xiàng)目將被創(chuàng)建多次。例如，假設(shè)我們正在緩存頭像，從數(shù)據(jù)庫中獲取頭像需要 10 秒。如果我們在第一次請求后 2 秒請求頭像，它將檢查頭像是否已緩存（尚未緩存），并開始另一次訪問數(shù)據(jù)庫。
關(guān)于GC壓力的第一個(gè)問題：可以使用多種技術(shù)和啟發(fā)式方法來監(jiān)控GC壓力。這篇博文與此無關(guān)，但您可以閱讀我的文章在 C# .NET 中查找、修復(fù)和避免內(nèi)存泄漏：8 個(gè)最佳實(shí)踐[4]以了解一些有用的方法。
第二個(gè)問題更容易解決。事實(shí)上，這是一個(gè)MemoryCache完全解決它的實(shí)現(xiàn)：
public class WaitToFinishMemoryCache<TItem>{private MemoryCache _cache = new MemoryCache(new MemoryCacheOptions());private ConcurrentDictionary<object, SemaphoreSlim> _locks = new ConcurrentDictionary<object, SemaphoreSlim>();public async Task<TItem> GetOrCreate(object key, Func<Task<TItem>> createItem){TItem cacheEntry;if (!_cache.TryGetValue(key, out cacheEntry))// Look for cache key.{SemaphoreSlim mylock = _locks.GetOrAdd(key, k => new SemaphoreSlim(1, 1));await mylock.WaitAsync();try{if (!_cache.TryGetValue(key, out cacheEntry)){// Key not in cache, so get data.cacheEntry = await createItem();_cache.Set(key, cacheEntry);}}finally{mylock.Release();}}return cacheEntry;}}
用法：
var _avatarCache = new WaitToFinishMemoryCache<byte[]>();// ...var myAvatar =await _avatarCache.GetOrCreate(userId, async () => await _database.GetAvatar(userId));
代碼說明
此實(shí)現(xiàn)鎖定項(xiàng)目的創(chuàng)建。鎖是特定于鑰匙的。例如，如果我們正在等待獲取 Alex 的 Avatar，我們?nèi)匀豢梢栽诹硪粋€(gè)線程上獲取 John 或 Sarah 的緩存值。
字典_locks存儲(chǔ)了所有的鎖。常規(guī)鎖不適用于async/await，因此我們需要使用SemaphoreSlim[5].
如果 (!_cache.TryGetValue(key, out cacheEntry))，有 2 次檢查以查看該值是否已被緩存。鎖內(nèi)的那個(gè)是確保只有一個(gè)創(chuàng)建的那個(gè)。鎖外面的那個(gè)是為了優(yōu)化。
何時(shí)使用 WaitToFinishMemoryCache
這個(gè)實(shí)現(xiàn)顯然有一些開銷。讓我們考慮什么時(shí)候甚至有必要。
在以下情況下使用 WaitToFinishMemoryCache：
?當(dāng)項(xiàng)目的創(chuàng)建時(shí)間具有某種成本時(shí)，您希望盡可能減少創(chuàng)建。?當(dāng)一個(gè)項(xiàng)目的創(chuàng)建時(shí)間很長時(shí)。?當(dāng)必須確保每個(gè)鍵都創(chuàng)建一個(gè)項(xiàng)目時(shí)。
在以下情況下不要使用 WaitToFinishMemoryCache：
?沒有多個(gè)線程訪問同一個(gè)緩存項(xiàng)的危險(xiǎn)。?您不介意多次創(chuàng)建該項(xiàng)目。例如，如果對數(shù)據(jù)庫的額外訪問不會(huì)有太大變化。
概括
緩存是一種非常強(qiáng)大的模式，它也很危險(xiǎn)，并且有其自身的復(fù)雜性。緩存太多，可能會(huì)導(dǎo)致 GC 壓力，緩存太少會(huì)導(dǎo)致性能問題。而分布式緩存，這是一個(gè)需要探索的全新世界。軟件開發(fā)職業(yè)就這樣，總是有新的東西要學(xué)習(xí)。
References
[1] Redis: https://redis.io/[2] 建議: https://docs.microsoft.com/en-us/aspnet/core/performance/caching/memory?view=aspnetcore-2.2#systemruntimecachingmemorycache[3] 容易地注入: https://docs.microsoft.com/en-us/aspnet/core/performance/caching/memory?view=aspnetcore-2.2#using-imemorycache[4] 在 C# .NET 中查找、修復(fù)和避免內(nèi)存泄漏：8 個(gè)最佳實(shí)踐: https://michaelscodingspot.com/find-fix-and-avoid-memory-leaks-in-c-net-8-best-practices/[5] SemaphoreSlim: https://blog.cdemi.io/async-waiting-inside-c-sharp-locks/