Verbesserung des LRU-Cache mit konfigurierbarer Datenpersistenz

Aufbauend auf den Grundlagen dieses Leitfadens zum Erstellen eines In-Memory-Caches gehen wir noch einen Schritt weiter, indem wir konfigurierbare Datenpersistenz einführen. Durch die Nutzung der Adapter- und Strategiemuster entwerfen wir ein erweiterbares System, das Speichermechanismen von der Caching-Logik entkoppelt und so eine nahtlose Integration von Datenbanken oder Diensten nach Bedarf ermöglicht.

Die Vision: Entkopplung wie ein ORM

Das Ziel besteht darin, den Cache erweiterbar zu machen, ohne seine Kernlogik zu ändern. Inspiriert von ORM-Systemen beinhaltet unser Ansatz eine gemeinsame API-Abstraktion. Dadurch kann Speicher – wie localStorage, IndexedDB oder sogar eine Remote-Datenbank – mit minimalen Codeänderungen austauschbar funktionieren.

Die Basisklasse des Speicheradapters

Hier ist die abstrakte Klasse, die die API für jedes Persistenzsystem definiert:

export abstract class StorageAdapter {
  abstract connect(): Promise<void>;
  abstract add(key: string, value: unknown): Promise<void>;
  abstract get(key: string): Promise<unknown | null>;
  abstract getAll(): Promise<Record<string, unknown>>;
  abstract delete(key: string): Promise<void>;
  abstract clear(): Promise<void>;
}

Jede Speicherlösung muss diese Basisklasse erweitern, um eine konsistente Interaktion sicherzustellen. Hier ist zum Beispiel die Implementierung für IndexedDB:

Beispiel: IndexedDB-Adapter

Dieser Adapter implementiert die StorageAdapter-Schnittstelle, um Cache-Daten in einem IndexedDB-Speicher beizubehalten.

import { StorageAdapter } from './storage_adapter';

/**
 * IndexedDBAdapter is an implementation of the StorageAdapter 
 * interface designed to provide a persistent storage mechanism 
 * using IndexedDB. This adapter can be reused for other cache 
 * implementations or extended for similar use cases, ensuring 
 * flexibility and scalability.
 */
export class IndexedDBAdapter extends StorageAdapter {
  private readonly dbName: string;
  private readonly storeName: string;
  private db: IDBDatabase | null = null;

  /**
   * Initializes the adapter with the specified database and store 
   * names. Defaults are provided to make it easy to set up without 
   * additional configuration.
   */
  constructor(dbName: string = 'cacheDB', storeName: string = 'cacheStore') {
    super();
    this.dbName = dbName;
    this.storeName = storeName;
  }

  /**
   * Connects to the IndexedDB database and initializes it if 
   * necessary. This asynchronous method ensures that the database 
   * and object store are available before any other operations. 
   * It uses the `onupgradeneeded` event to handle schema creation 
   * or updates, making it a robust solution for versioning.
   */
  async connect(): Promise<void> {
    return await new Promise((resolve, reject) => {
      const request = indexedDB.open(this.dbName, 1);

      request.onupgradeneeded = (event) => {
        const db = (event.target as IDBOpenDBRequest).result;
        if (!db.objectStoreNames.contains(this.storeName)) {
          db.createObjectStore(this.storeName, { keyPath: 'key' });
        }
      };

      request.onsuccess = (event) => {
        this.db = (event.target as IDBOpenDBRequest).result;
        resolve();
      };

      request.onerror = () => reject(request.error);
    });
  }

  /**
   * Adds or updates a key-value pair in the store. This method is 
   * asynchronous to ensure compatibility with the non-blocking 
   * nature of IndexedDB and to prevent UI thread blocking. Using 
   * the `put` method ensures idempotency: the operation will 
   * insert or replace the entry.
   */
  async add(key: string, value: unknown): Promise<void> {
    await this._withTransaction('readwrite', (store) => store.put({ key, value }));
  }

  /**
   * Retrieves the value associated with a key. If the key does not 
   * exist, null is returned. This method is designed to integrate 
   * seamlessly with caching mechanisms, enabling fast lookups.
   */
  async get(key: string): Promise<unknown | null> {
    return await this._withTransaction('readonly', (store) =>
      this._promisifyRequest(store.get(key)).then((result) =>
        result ? (result as { key: string; value: unknown }).value : null
      )
    );
  }

  /**
   * Fetches all key-value pairs from the store. Returns an object 
   * mapping keys to their values, making it suitable for bulk 
   * operations or syncing with in-memory caches.
   */
  async getAll(): Promise<Record<string, unknown>> {
    return await this._withTransaction('readonly', (store) =>
      this._promisifyRequest(store.getAll()).then((results) =>
        results.reduce((acc: Record<string, unknown>, item: { key: string; value: unknown }) => {
          acc[item.key] = item.value;
          return acc;
        }, {})
      )
    );
  }

  /**
   * Deletes a key-value pair by its key. This method is crucial 
   * for managing cache size and removing expired entries. The 
   * `readwrite` mode is used to ensure proper deletion.
   */
  async delete(key: string): Promise<void> {
    await this._withTransaction('readwrite', (store) => store.delete(key));
  }

  /**
   * Clears all entries from the store. This method is ideal for 
   * scenarios where the entire cache needs to be invalidated, such 
   * as during application updates or environment resets.
   */
  async clear(): Promise<void> {
    await this._withTransaction('readwrite', (store) => store.clear());
  }

  /**
   * Handles transactions in a reusable way. Ensures the database 
   * is connected and abstracts the transaction logic. By 
   * centralizing transaction handling, this method reduces 
   * boilerplate code and ensures consistency across all operations.
   */
  private async _withTransaction<T>(
    mode: IDBTransactionMode,
    callback: (store: IDBObjectStore) => IDBRequest | Promise<T>
  ): Promise<T> {
    if (!this.db) throw new Error('IndexedDB is not connected');
    const transaction = this.db.transaction([this.storeName], mode);
    const store = transaction.objectStore(this.storeName);
    const result = callback(store);
    return result instanceof IDBRequest ? await this._promisifyRequest(result) : await result;
  }

  /**
   * Converts IndexedDB request events into Promises, allowing for 
   * cleaner and more modern asynchronous handling. This is 
   * essential for making IndexedDB operations fit seamlessly into 
   * the Promise-based architecture of JavaScript applications.
   */
  private async _promisifyRequest<T>(request: IDBRequest): Promise<T> {
    return await new Promise((resolve, reject) => {
      request.onsuccess = () => resolve(request.result as T);
      request.onerror = () => reject(request.error);
    });
  }
}

Integration des Adapters in den Cache

Der Cache akzeptiert einen optionalen StorageAdapter. Falls bereitgestellt, initialisiert es die Datenbankverbindung, lädt Daten in den Speicher und hält den Cache und den Speicher synchron.

private constructor(capacity: number, storageAdapter?: StorageAdapter) {
  this.capacity = capacity;
  this.storageAdapter = storageAdapter;

  if (this.storageAdapter) {
    this.storageAdapter.connect().catch((error) => {
      throw new Error(error);
    });

    this.storageAdapter.getAll().then((data) => {
      for (const key in data) {
        this.put(key, data[key] as T);
      }
    }).catch((error) => {
      throw new Error(error);
    });
  }

  this.hash = new Map();
  this.head = this.tail = undefined;

  this.hitCount = this.missCount = this.evictionCount = 0;
}

Warum Adapter- und Strategiemuster?

Verwendung des Adaptermusters:

• Entkoppeltden Cache von bestimmten Speichermechanismen.
• Gewährleistet Erweiterbarkeit für neue Speicher-Backends.

Kombination mit dem Strategiemuster:

• Ermöglicht die Laufzeitauswahl der Persistenzschicht.
• Vereinfacht das Testen durch Verspotten verschiedener Adapter.

Wichtige Designpraktiken

• Abstrakte API: Hält die Cache-Logik unabhängig von Speicherdetails.
• Singleton-Cache: Stellt die Konsistenz gemeinsamer Zustände sicher.
• Asynchrone Initialisierung: Vermeidet blockierende Vorgänge während der Einrichtung.
• Lazy Loading:Lädt persistente Daten nur, wenn ein Speicheradapter bereitgestellt wird.

Nächste Schritte

Dieses Design ist robust, lässt aber Raum für Verbesserungen:

• Optimieren Sie die Synchronisierungslogik für eine bessere Leistung.
• Experimentieren Sie mit zusätzlichen Adaptern wie Redis oder SQLite.

Probieren Sie es aus! ?

Wenn Sie den Cache in Aktion testen möchten, ist er als npm-Paket verfügbar: adev-lru. Sie können den vollständigen Quellcode auch auf GitHub erkunden: adev-lru-Repository. Ich freue mich über alle Empfehlungen, konstruktives Feedback oder Beiträge, um es noch besser zu machen! ?

Viel Spaß beim Codieren! ?

Das obige ist der detaillierte Inhalt vonVerbesserung des LRU-Cache mit konfigurierbarer Datenpersistenz. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!