討論一下LRU緩存的實現算法
業務模型
讀、寫、刪的比例大致是7:3:1,至少要支持500w條緩存,平均每條緩存6k,要求設計一套性能比較好的緩存算法。
算法分析
不考慮MemCached,Velocity等現成的key-value緩存方案,也不考慮脫離.NET gc自己管理內存,不考慮隨機讀取數據及順序讀取數據的場景,目前想到的有如下幾種LRU緩存方案
算法 |
分析 |
SortedDictionary |
.NET自帶的,內部用二叉搜索樹(應該不是普通樹,至少是做過優化的樹)實現的,檢索為O(log n),比普通的Dictionay(O(1))慢一點。 |
Dictionary + PriorityQueue |
Dictionay可以保證檢索是O(1); |
Dictionay + Binary heap |
二叉堆也是優先隊列,分析應該同上,我沒有詳細評估。 |
b樹 |
查找,刪除,插入效率都很好,數據庫都用它,但實現復雜,寫一個沒有BUG的B樹幾乎不可能。有人提到stl:map是自頂向下的紅黑樹,查找,刪除,插入都是O(log n),但咱不懂c++,沒做詳細測試。 |
Dictionay + List |
Dict用來檢索; |
Dictionay + LinkedList |
Dict用來檢索; |
目前幾種方案在多線程下應該都需要加鎖,不太好設計無鎖的方案,下面這個鏈接是一個支持多線程的方案,但原理至今沒搞特明白
A High Performance Multi-Threaded LRU Cache
http://www.codeproject.com/KB/recipes/LRUCache.aspx
用普通鏈表簡單實現LRU緩存
以下是最后一種方案的簡單實現,大家討論下這個方案值不值得優化,或者其它的哪個方案比較合適
- public class LRUCacheHelper
{ - readonly Dictionary
_dict; - readonly LinkedList
_queue = new LinkedList(); - readonly object _syncRoot = new object();
- private readonly int _max;
- public LRUCacheHelper(int capacity, int max) {
- _dict = new Dictionary
(capacity); - _max = max;
- }
- public void Add(K key, V value) {
- lock (_syncRoot) {
- checkAndTruncate();
- _queue.AddFirst(key); //O(1)
- _dict[key] = value; //O(1)
- }
- }
- private void checkAndTruncate() {
- lock (_syncRoot) {
- int count = _dict.Count; //O(1)
- if (count >= _max) {
- int needRemoveCount = count / 10;
- for (int i = 0; i < needRemoveCount; i++) {
- _dict.Remove(_queue.Last.Value); //O(1)
- _queue.RemoveLast(); //O(1)
- }
- }
- }
- }
- public void Delete(K key) {
- lock (_syncRoot) {
- _dict.Remove(key); //(1)
- _queue.Remove(key); // O(n)
- }
- }
- public V Get(K key) {
- lock (_syncRoot) {
- V ret;
- _dict.TryGetValue(key, out ret); //O(1)
- _queue.Remove(key); //O(n)
- _queue.AddFirst(key); //(1)
- return ret;
- }
- }
- }
_dict.TryGetValue(key, out ret); //O(1)
ret.Next.Previous = ret.Previous //O(1)
ret. Previous.Next. = ret.Next //O(1)
_queue.AddFirst(key); //O(1)
我改進后的鏈表就差不多滿足需求了,
操作 |
基本操作 |
復雜度 |
讀取 |
Dict.Get Queue.Move |
O 1 O 1 |
刪除 |
Dict.Remove Queue.Remove |
O 1 O 1 |
增加 |
Dict.Add Queue.AddFirst |
O 1 O 1 |
截斷 |
Dict.Remove Queue.RemoveLast |
O k O k K表示截斷緩存元素的個數 |
其中截斷的時候可以指定當緩存滿的時候截斷百分之多少的最少使用的緩存項。
其它的就是多線程的時候鎖再看看怎么優化,字典有線程安全的版本,就把.NET 3.0的讀寫鎖扣出來再把普通的泛型字典保證成ThreadSafelyDictionay就行了,性能應該挺好的。
鏈表的話不太好用讀寫鎖來做線程同步,大不了用互斥鎖,但得考慮下鎖的粒度,Move,AddFirst,RemoveLast的時候只操作一兩個節點,是不是想辦法只lock這幾個節點就行了,Truncate的時候因為要批量操作很多節點,所以要上個大多鏈表鎖,但這時候怎么讓其它操作停止得考慮考慮,類似數據庫的表鎖和行鎖。
LRU緩存實現代碼
- public class DoubleLinkedListNode
{ - public T Value { get; set; }
程序初始化200w條緩存,然后不斷的加,每加到500w,截斷掉10分之一,然后繼續加。
測試模型中每秒鐘的讀和寫的比例是7:3,以下是依次在3個時間點截取的性能計數器圖。
圖1
圖2
圖3
內存最高會達到1g,cpu也平均百分之90以上,但測試到后期會發現每隔一段時間,就會有一兩秒,吞吐量為0,如最后一張截圖,后來觀察發現,停頓的那一兩秒是二代內存在回收,等不停頓的時候# gen 2 collections就會加1,這個原因應該是鏈表引起的,對鏈表中節點的添加和刪除是很耗費GC的,因為會頻繁的創建和銷毀對象。
LRU緩存后續改進
1、 用游標鏈表來代替普通的雙頭鏈表,程序起來就收工分配固定大小的數組,然后用數組的索引來做鏈表,省得每次添加和刪除節點都要GC的參與,這相當于手工管理內存了,但目前我還沒找到c#合適的實現。
2、 有人說鏈表不適合用在多線程環境中,因為對鏈表的每個操作都要加互斥鎖,連讀寫鎖都用不上,我目前的實現是直接用互斥鎖做的線程同步,每秒的吞吐量七八十萬,感覺lock也不是瓶頸,如果要改進的話可以把Dictionary用ThreadSafelyDictionary來代替,然后鏈表還用互斥鎖(剛開始設想的鏈表操作只鎖要操作的幾個節點以降低并發沖突的想法應該不可取,不嚴謹)。
3、 還有一個地方就是把鎖細分以下,鏈表還用鏈表,但每個鏈表的節點是個HashSet,對HashSet的操作如果只有讀,寫,刪,沒有遍歷的話應該不需要做線程同步(我感覺不用,因為Set就是一個集合,一個線程往里插入,一個線程往里刪除,一個線程讀取應該沒問題,頂多讀進來的數據可能馬上就刪除了,而整個Set的結構不會破壞)。然后新增數據的時候往鏈表頭頂Set里插入,讀取某個數據的時候把它所在的節點的Set里刪除該數據,然后再鏈表頭的Set里插入一個數據,這樣反復操作后,鏈表的最后一個節點的Set里的數據都是舊數據了,可以安全的刪除了,當然這個刪除的時候應該是要鎖整個鏈表的。每個Set應該有個大小上限,比如20w,但set不能安全的遍歷,就不能得到當前大小,所以添加、刪除Set的數據的時候應該用Interlocked.Decrement()和 Interlocked.Increment()維護一個Count,一遍一個Set滿的時候,再到鏈表的頭新增一個Set節點。
LRU緩存性能測試腳本
- class Program {
- private static PerformanceCounter _addCounter;
- private static PerformanceCounter _getCounter;
- static void Main(string[] args) {
- SetupCategory();
- _addCounter = new PerformanceCounter("wawasoft.lrucache", "add/sec", false);
- _getCounter = new PerformanceCounter("wawasoft.lrucache", "get/sec", false);
- _addCounter.RawValue = 0;
- _getCounter.RawValue = 0;
- Random rnd = new Random();
- const int max = 500 * 10000;
- LRUCacheHelper<int, int> cache = new LRUCacheHelper<int, int>(200 * 10000, max);
- for (int i = 10000*100000 - 1; i >= 0; i--)
- {
- if(i % 10 > 7)
- {
- ThreadPool.QueueUserWorkItem(
- delegate
- {
- cache.Add(rnd.Next(0, 10000), 0);
- _addCounter.Increment();
- });
- }
- else
- {
- ThreadPool.QueueUserWorkItem(
- delegate
- {
- int pop = cache.Get(i);
- _getCounter.Increment();
- });
- }
- }
- Console.ReadKey();
- }
- private static void SetupCategory() {
- if (!PerformanceCounterCategory.Exists("wawasoft.lrucache")) {
- CounterCreationDataCollection CCDC = new CounterCreationDataCollection();
- CounterCreationData addcounter = new CounterCreationData();
- addcounter.CounterType = PerformanceCounterType.RateOfCountsPerSecond32;
- addcounter.CounterName = "add/sec";
- CCDC.Add(addcounter);
- CounterCreationData getcounter = new CounterCreationData();
- getcounter.CounterType = PerformanceCounterType.RateOfCountsPerSecond32;
- getcounter.CounterName = "get/sec";
- CCDC.Add(getcounter);
- PerformanceCounterCategory.Create("wawasoft.lrucache","lrucache",CCDC);
- }
- }
- }
【編輯推薦】