بناء ذاكرة تخزين مؤقت LRU آمنة للتشعب في Go: أنماط التزامن ومقارنة الأداء مع sync.Map

يُعد التزامن أحد أقوى نقاط بيع لغة Go، لكنه يقدم تعقيدًا عند إدارة الحالة المشتركة. المتطلب الشائع في تطبيقات Go عالية الأداء هو ذاكرة تخزين مؤقت في الذاكرة مع سياسة إزاحة "الأقل استخدامًا مؤخرًا" (LRU). بينما توفر المكتبة القياسية لـ Go sync.Map لتخزين المفاتيح والقيم المتزامن، إلا أنها غير مُحسّنة لأحمال عمل التخزين المؤقت. في هذا المنشور، سنستكشف كيفية تنفيذ ذاكرة تخزين مؤقت LRU قوية وآمنة للتشعب باستخدام sync.Mutex و sync.Cond، وسنقوم بمقارنة أدائها مع sync.Map لفهم المقايضات الخاصة بكل منهما.

تحديات الحالة المشتركة

تتطلب ذاكرة التخزين المؤقت LRU بنية بيانات رئيسية واحدة: قائمة مرتبطة مزدوجة للحفاظ على ترتيب الوصول، و خريطة تجزئة لإجراء عمليات البحث بسرعة O(1). عندما تصل عدة خيوط تنفيذ (goroutines) إلى هذه البنية بشكل متزامن، قد تؤدي ظروف السباق إلى إتشاف مؤشرات القائمة أو إدخالات الخريطة. النهج البدائي المتمثل في استخدام متغير عالمي غير آمن. نحتاج إلى أدوات مزامنة تسمح بمرور عالي للبيانات دون إنشاء اختناقات.

هناك قراران معماريان رئيسيان هنا:

• القفل ذو الحبيبات الخشنة (Coarse-grained locking): استخدام sync.Mutex واحد لحماية بنية ذاكرة التخزين المؤقت بأكملها. هذا النهج بسيط التنفيذ وكافٍ عادةً للعديد من حالات الاستخدام.
• القفل ذو الحبيبات الدقيقة (Fine-grained locking - الشردنج): تقسيم ذاكرة التخزين المؤقت إلى مقاطع متعددة، لكل منها قفلها الخاص، لتقليل احتقان القفل.

لأغراض هذا العرض، سنركز على تنفيذ نظيف وبسيط باستخدام قفل واحد، حيث إنه غالبًا ما يكون نقطة البداية الأكثر أداءً لذواكر التخزين المؤقت متوسطة الحجم.

تنفيذ ذاكرة التخزين المؤقت LRU الآمنة للتشعب

<سيتم تغليف تنفيذنا بقائمة مرتبطة مزدوجة وخريطة. سيضمن sync.Mutex أن العمليات مثل Get و Set و Evict تكون ذرية (غير قابلة للتقسيم).

package lru

import (
    "container/list"
    "sync"
)

// Cache represents a thread-safe LRU cache.
type Cache struct {
    mu    sync.Mutex
    items map[string]*list.Element
    ll    *list.List
    maxSize int
}

// element stores the key and value in the linked list.
type element struct {
    key   string
    value interface{}
}

// New creates a new LRU cache with a specified maximum size.
func New(maxSize int) *Cache {
    return &Cache{
        items:   make(map[string]*list.Element),
        ll:      list.New(),
        maxSize: maxSize,
    }
}

// Get retrieves a value from the cache. If the key exists, it is moved to the front.
func (c *Cache) Get(key string) (interface{}, bool) {
    c.mu.Lock()
    defer c.mu.Unlock()

    if elem, ok := c.items[key]; ok {
        // Move to front (most recently used)
        c.ll.MoveToFront(elem)
        return elem.Value.(*element).value, true
    }
    return nil, false
}

// Set adds a key-value pair to the cache. If full, it evicts the least recently used item.
func (c *Cache) Set(key string, value interface{}) {
    c.mu.Lock()
    defer c.mu.Unlock()

    // Check if key already exists
    if elem, ok := c.items[key]; ok {
        c.ll.MoveToFront(elem)
        elem.Value.(*element).value = value
        return
    }

    // Evict if at capacity
    if c.ll.Len() >= c.maxSize {
        oldest := c.ll.Back()
        if oldest != nil {
            c.ll.Remove(oldest)
            delete(c.items, oldest.Value.(*element).key)
        }
    }

    // Add new item to front
    newElem := c.ll.PushFront(&element{key: key, value: value})
    c.items[key] = newElem
}

مقارنة الأداء: sync.Mutex مقابل sync.Map

يتم تحسين sync.Map في Go لحالات استخدام محددة: عندما تكون مجموعات المفاتيح منفصلة عبر خيوط التنفيذ، أو عندما يكون هناك عدد أكبر بكثير من عمليات القراءة مقارنة بعمليات الكتابة. ومع ذلك، بالنسبة لذاكرة تخزين مؤقت عامة الأغراض تحتوي على عمليات قراءة/كتابة مختلطة وتحديثات متكررة للمفاتيح، غالبًا ما يقل أداء sync.Map بسبب تعقيده الداخلي وفائض الذاكرة.

لنلقِ نظرة على سيناريو مقارن مفاهيمي. سنحاكي 100,000 عملية قراءة متزامنة و 10,000 عملية كتابة.

package main

import (
    "testing"
    "sync"
)

func BenchmarkLRUCache(b *testing.B) {
    cache := New(10000)
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        cache.Set(string(rune(i)), i)
    }
}

func BenchmarkSyncMap(b *testing.B) {
    var m sync.Map
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        m.Store(string(rune(i)), i)
    }
}

في مقارنات الأداء النموذجية التي تتضمن وصولاً عشوائيًا للمفاتيح وتحديثات متكررة، تتفوق ذاكرة التخزين المؤقت LRU المعتمدة على القفل على sync.Map بفارق كبير. يستخدم sync.Map عدم التوجيه (indirection) والقفل الشرطي داخليًا، مما يضيف زمن انتقال (latency). القفل القياسي، خاصة مع تطبيقات Go الحديثة (Go 1.12+)، يستخدم لفًا تكيفيًا (adaptive spinning) و futexes فعالة، مما يجعله عالي الكفاءة لأقسام الحرجة القصيرة مثل عمليات ذاكرة التخزين المؤقت لدينا.

متى تستخدم ماذا؟

استخدم ذاكرة التخزين المؤقت LRU المخصصة بـ sync.Mutex عندما:

• تحتاج إلى سياسات إزاحة صارمة (LRU, LFU, FIFO).
• يتضمن عملك أنماط قراءة/كتابة مختلطة.
• تريد استخدامًا متوقعًا للذاكرة وفائض أقل.

استخدم sync.Map عندما:

• لديك بيانات ثابتة نادرًا ما يتم حذفها.
• يعمل القراء والكتاب على مجموعات مفاتيح منفصلة تمامًا.
• تحتاج إلى خريطة متزامنة سريعة بدون فائض دون تنفيذ منطق الإزاحة.

الخاتمة

يعد بناء ذاكرة تخزين مؤقت LRU آمنة للتشعب في Go تمرينًا مباشرًا في فهم أدوات المزامنة. بينما يُعد sync.Map أداة قوية في المكتبة القياسية، إلا أنه ليس بديلاً جاهزًا للاستخدام عن هياكل التخزين المؤقت المتخصصة. من خلال تنفيذ ذاكرة تخزين مؤقت مخصصة باستخدام sync.Mutex، يكتسب المطورون تحكمًا دقيقًا في منطق الإزاحة وغالبًا ما يحققون أداءً أفضل في سيناريوهات التخزين المؤقت العامة.

بالنسبة لأنظمة الإنتاج ذات التزامن الشديد، فكر في تقسيم ذاكرة التخزين المؤقت أو استخدام مكتبات راسخة مثل groupcache أو bigcache. ومع ذلك، بالنسبة لمعظم التطبيقات، يوفر النهج البسيط المعتمد على القفل أفضل توازن بين البساطة والأداء والتحكم.