Die Integration von Redis in NestJS-Anwendungen verbessert die Performance erheblich, indem Datenbankabfragen durch In-Memory-Zugriffe ersetzt werden. Die Kombination aus @nestjs/cache-manager für Caching und express-session mit connect-redis für Session-Persistenz deckt die beiden häufigsten Redis-Anwendungsfälle in Backend-Anwendungen ab.

Kernkonzept

Redis-Caching in NestJS reduziert die Datenbanklast durch Speicherung häufig abgerufener Daten im Arbeitsspeicher. Session-Verwaltung mit Redis ermöglicht horizontale Skalierung durch gemeinsame Nutzung des Session-Status über mehrere Instanzen.

Einrichtung von @nestjs/cache-manager mit Redis

Das cache-manager-Modul wurde in NestJS 10 in ein separates Paket ausgelagert. Die Installation erfordert sowohl den NestJS-Wrapper als auch den zugrunde liegenden Cache-Store. Der @keyv/redis-Adapter ist der empfohlene Ansatz für die Redis-Integration mit cache-manager v5.

bash

# Erforderliche Pakete installieren
npm install @nestjs/cache-manager cache-manager @keyv/redis

Die Modulregistrierung konfiguriert die Redis-Verbindung und die Standard-TTL. Die Option isGlobal macht den Cache über alle Module verfügbar, ohne ihn erneut importieren zu müssen.

app.module.tstypescript

import { Module } from '@nestjs/common';
import { CacheModule } from '@nestjs/cache-manager';
import KeyvRedis from '@keyv/redis';

@Module({
  imports: [
    CacheModule.registerAsync({
      isGlobal: true,
      useFactory: () => ({
        stores: [
          new KeyvRedis(process.env.REDIS_URL || 'redis://localhost:6379'),
        ],
        ttl: 60000, // Standard-TTL in Millisekunden
      }),
    }),
  ],
})
export class AppModule {}

Das stores-Array akzeptiert mehrere Cache-Stores für mehrstufiges Caching. Produktionsumgebungen verwenden typischerweise Redis als primären Store mit einem optionalen In-Memory-Fallback für die Entwicklung.

Cache-Injection und Service-Level-Caching

Das CACHE_MANAGER-Token bietet direkten Zugriff auf den Cache für Service-Level-Operationen. Dieser Ansatz bietet mehr Kontrolle als automatisches HTTP-Caching, wenn die Geschäftslogik die Cache-Invalidierung bestimmt.

users.service.tstypescript

import { Injectable, Inject } from '@nestjs/common';
import { CACHE_MANAGER, Cache } from '@nestjs/cache-manager';
import { UsersRepository } from './users.repository';
import { User } from './user.entity';

@Injectable()
export class UsersService {
  constructor(
    @Inject(CACHE_MANAGER) private cache: Cache,
    private usersRepository: UsersRepository,
  ) {}

  async findById(id: string): Promise<User | null> {
    // Zuerst Cache prüfen
    const cacheKey = `user:${id}`;
    const cached = await this.cache.get<User>(cacheKey);
    
    if (cached) {
      return cached;
    }

    // Cache-Miss: aus Datenbank abrufen
    const user = await this.usersRepository.findById(id);
    
    if (user) {
      await this.cache.set(cacheKey, user, 300000); // 5 Minuten TTL
    }

    return user;
  }

  async update(id: string, data: Partial<User>): Promise<User> {
    const user = await this.usersRepository.update(id, data);
    // Cache bei Update invalidieren
    await this.cache.del(`user:${id}`);
    
    return user;
  }
}

Das Cache-Key-Muster user:{id} ermöglicht gezielte Invalidierung. Komplexere Muster wie user:* erfordern Redis-spezifische Befehle über den zugrunde liegenden Client.

CacheInterceptor für automatisches HTTP-Response-Caching

Der integrierte CacheInterceptor cached HTTP-GET-Responses automatisch. Die Anwendung auf Controller-Ebene cached alle GET-Endpunkte, während die Anwendung auf Methodenebene granulare Kontrolle bietet.

products.controller.tstypescript

import { Controller, Get, UseInterceptors, Param } from '@nestjs/common';
import { CacheInterceptor, CacheTTL, CacheKey } from '@nestjs/cache-manager';
import { ProductsService } from './products.service';

@Controller('products')
@UseInterceptors(CacheInterceptor)
export class ProductsController {
  constructor(private productsService: ProductsService) {}

  @Get()
  @CacheTTL(120000) // Standard-TTL überschreiben: 2 Minuten
  async findAll() {
    return this.productsService.findAll();
  }

  @Get(':id')
  @CacheKey('product-detail') // Benutzerdefiniertes Cache-Key-Präfix
  async findOne(@Param('id') id: string) {
    return this.productsService.findById(id);
  }
}

Der Interceptor generiert standardmäßig Cache-Keys aus der Request-URL. Benutzerdefinierte @CacheKey()-Dekoratoren überschreiben dieses Verhalten für Routen, bei denen Query-Parameter das Caching nicht beeinflussen sollten. Weitere Informationen zu NestJS-Interceptoren und Guards sind häufige Themen in technischen Interviews.

Cache-Key-Kollisionen

Der Standard-Cache-Key verwendet die vollständige URL einschließlich Query-Parametern. Zwei Anfragen an /products?page=1 und /products?page=2 erstellen separate Cache-Einträge. Mit @CacheKey() überschreiben, wenn Paginierung keine doppelten gecachten Responses erstellen soll.

Session-Verwaltung mit Redis und express-session

NestJS läuft standardmäßig auf Express, was express-session zur Standardwahl für die Session-Verwaltung macht. Der connect-redis-Adapter speichert Session-Daten in Redis statt im Speicher und ermöglicht Session-Persistenz über Server-Neustarts hinweg.

bash

# Session-Pakete installieren
npm install express-session connect-redis redis
npm install -D @types/express-session

Die Session-Konfiguration erfolgt in main.ts, bevor die Anwendung startet. Der Redis-Client verbindet sich unabhängig vom cache-manager-Setup.

main.tstypescript

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import * as session from 'express-session';
import { createClient } from 'redis';
import RedisStore from 'connect-redis';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  // Redis-Client initialisieren
  const redisClient = createClient({
    url: process.env.REDIS_URL || 'redis://localhost:6379',
  });
  await redisClient.connect();

  // Session-Middleware konfigurieren
  app.use(
    session({
      store: new RedisStore({ client: redisClient }),
      secret: process.env.SESSION_SECRET || 'change-this-in-production',
      resave: false,
      saveUninitialized: false,
      cookie: {
        httpOnly: true,
        secure: process.env.NODE_ENV === 'production',
        maxAge: 24 * 60 * 60 * 1000, // 24 Stunden
      },
    }),
  );

  await app.listen(3000);
}
bootstrap();

Die Option saveUninitialized: false verhindert das Speichern leerer Sessions und reduziert den Redis-Speicherverbrauch. Die Cookie-Einstellung secure: true erfordert HTTPS in der Produktion.

Bereit für deine Node.js / NestJS-Interviews?

Übe mit unseren interaktiven Simulatoren, Flashcards und technischen Tests.

Node.js / NestJS erkunden

Zugriff auf Sessions in Controllern und Guards

Session-Daten sind über das Request-Objekt verfügbar. Ein typisiertes Session-Interface verbessert die Entwicklererfahrung und erkennt Fehler zur Kompilierungszeit.

session.interface.tstypescript

export interface SessionData {
  userId?: string;
  email?: string;
  roles?: string[];
  loginAt?: Date;
}

declare module 'express-session' {
  interface SessionData {
    userId?: string;
    email?: string;
    roles?: string[];
    loginAt?: Date;
  }
}

Der erweiterte Session-Typ macht Session-Eigenschaften mit Autovervollständigung verfügbar.

auth.controller.tstypescript

import { Controller, Post, Body, Req, HttpCode } from '@nestjs/common';
import { Request } from 'express';
import { AuthService } from './auth.service';
import { LoginDto } from './dto/login.dto';

@Controller('auth')
export class AuthController {
  constructor(private authService: AuthService) {}

  @Post('login')
  @HttpCode(200)
  async login(@Body() loginDto: LoginDto, @Req() req: Request) {
    const user = await this.authService.validateUser(
      loginDto.email,
      loginDto.password,
    );

    // Benutzerdaten in Session speichern
    req.session.userId = user.id;
    req.session.email = user.email;
    req.session.roles = user.roles;
    req.session.loginAt = new Date();

    return { message: 'Erfolgreich angemeldet' };
  }

  @Post('logout')
  @HttpCode(200)
  async logout(@Req() req: Request) {
    return new Promise((resolve, reject) => {
      req.session.destroy((err) => {
        if (err) reject(err);
        resolve({ message: 'Erfolgreich abgemeldet' });
      });
    });
  }
}

Ein Guard schützt Routen durch Überprüfung der Session-Gültigkeit. Dieses Muster integriert sich nahtlos in das NestJS-Autorisierungs- und RBAC-System.

session.guard.tstypescript

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { Request } from 'express';

@Injectable()
export class SessionGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest<Request>();
    return !!request.session?.userId;
  }
}

Cache-Invalidierungsstrategien für NestJS-Anwendungen

Cache-Invalidierung ist das schwierigere Problem beim Caching. Drei Strategien eignen sich für unterschiedliche Szenarien:

Zeitbasierte Ablauf (TTL) funktioniert für Daten, die sich vorhersehbar ändern oder bei denen leichte Veralterung akzeptabel ist. Produktkataloge, Konfigurationswerte und öffentliche Inhalte passen zu diesem Muster.

Ereignisbasierte Invalidierung löscht Cache-Einträge, wenn sich die zugrunde liegenden Daten ändern. Dies erfordert explizite cache.del()-Aufrufe in Update- und Delete-Operationen.

Musterbasierte Invalidierung entfernt mehrere verwandte Keys. Redis unterstützt Musterlöschung durch SCAN- und DEL-Befehle, aber cache-manager abstrahiert dies.

cache-invalidation.service.tstypescript

import { Injectable, Inject } from '@nestjs/common';
import { CACHE_MANAGER, Cache } from '@nestjs/cache-manager';

@Injectable()
export class CacheInvalidationService {
  constructor(@Inject(CACHE_MANAGER) private cache: Cache) {}

  // Einzelne Key-Invalidierung
  async invalidateUser(userId: string): Promise<void> {
    await this.cache.del(`user:${userId}`);
  }

  // Mehrere verwandte Keys
  async invalidateUserRelated(userId: string): Promise<void> {
    const keys = [
      `user:${userId}`,
      `user:${userId}:profile`,
      `user:${userId}:preferences`,
    ];
    
    await Promise.all(keys.map((key) => this.cache.del(key)));
  }

  // Gesamten Cache leeren (sparsam verwenden)
  async clearAll(): Promise<void> {
    await this.cache.reset();
  }
}

Die reset()-Methode löscht alle gecachten Daten, nützlich während Deployments oder Datenmigrationen, aber gefährlich in der Produktion, wenn sie versehentlich aufgerufen wird.

Redis-Connection-Pooling und Cluster-Unterstützung

Produktions-Deployments erfordern Connection-Pooling, um gleichzeitige Anfragen effizient zu verarbeiten. Die ioredis-Bibliothek bietet Cluster-Unterstützung und Connection-Pooling out of the box.

redis.config.tstypescript

import { Injectable } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import Redis, { Cluster } from 'ioredis';

@Injectable()
export class RedisConfig {
  constructor(private configService: ConfigService) {}

  createClient(): Redis | Cluster {
    const clusterNodes = this.configService.get<string>('REDIS_CLUSTER_NODES');

    if (clusterNodes) {
      // Cluster-Modus
      const nodes = clusterNodes.split(',').map((node) => {
        const [host, port] = node.split(':');
        return { host, port: parseInt(port, 10) };
      });

      return new Redis.Cluster(nodes, {
        redisOptions: {
          password: this.configService.get('REDIS_PASSWORD'),
        },
      });
    }

    // Standalone-Modus
    return new Redis({
      host: this.configService.get('REDIS_HOST', 'localhost'),
      port: this.configService.get('REDIS_PORT', 6379),
      password: this.configService.get('REDIS_PASSWORD'),
      maxRetriesPerRequest: 3,
    });
  }
}

Für Anwendungen, die TypeORM oder Prisma verwenden, sollten Datenbank- und Cache-Verbindungen separat mit eigenen Connection-Pools konfiguriert werden.

NestJS Redis Interviewfragen

Technische Interviews zu Node.js-Caching decken sowohl konzeptionelles Verständnis als auch praktische Implementierung ab. Diese Fragen treten häufig auf:

Warum Redis statt In-Memory-Caching verwenden?

In-Memory-Caching persistiert nicht über Neustarts hinweg und kann nicht über mehrere Instanzen geteilt werden. Redis bietet Persistenz, Replikation und gemeinsamen Zustand für horizontal skalierte Anwendungen. Der Kompromiss ist Netzwerklatenz im Vergleich zu lokalem Speicherzugriff.

Wie unterscheidet sich cache-manager von direkter Redis-Nutzung?

Die cache-manager-Bibliothek bietet eine einheitliche API über verschiedene Cache-Stores hinweg. Der Wechsel von In-Memory zu Redis erfordert nur die Änderung der Store-Konfiguration ohne Modifikation des Service-Codes. Direkte Redis-Nutzung bietet mehr Redis-spezifische Funktionen wie Pub/Sub, Sorted Sets und Lua-Scripting.

Was ist Cache-Stampede und wie wird sie verhindert?

Cache-Stampede tritt auf, wenn ein beliebter Cache-Eintrag abläuft und viele gleichzeitige Anfragen die Datenbank gleichzeitig treffen. Präventionsstrategien umfassen:

Lock-basierte Aktualisierung: Eine Anfrage aktualisiert den Cache, während andere warten
Probabilistische frühe Ablauf: Zufällige Aktualisierung vor TTL-Ablauf
Hintergrund-Aktualisierung: Ein separater Prozess aktualisiert ablaufende Einträge

Wann sollte CacheInterceptor vs. Service-Level-Caching verwendet werden?

CacheInterceptor eignet sich für zustandslose GET-Endpunkte, bei denen die Response nur von der URL abhängt. Service-Level-Caching behandelt Szenarien, in denen Cache-Invalidierung bei Datenänderungen erfolgen muss oder bei denen Nicht-GET-Operationen Caching benötigen.

Wie werden Session-Fixation-Angriffe mit Redis-Sessions verhindert?

Die Session-ID nach der Authentifizierung regenerieren. req.session.regenerate() vor dem Speichern von Benutzeranmeldedaten aufrufen, um Angreifer daran zu hindern, Prä-Authentifizierungs-Session-IDs zu verwenden.

typescript

// Sichere Anmeldung mit Session-Regenerierung
async login(@Body() loginDto: LoginDto, @Req() req: Request) {
  const user = await this.authService.validateUser(
    loginDto.email,
    loginDto.password,
  );

  return new Promise((resolve, reject) => {
    req.session.regenerate((err) => {
      if (err) reject(err);
      
      req.session.userId = user.id;
      req.session.email = user.email;
      resolve({ message: 'Erfolgreich angemeldet' });
    });
  });
}

Interview-Einblick

Senior-Kandidaten erklären die Kompromisse zwischen Caching-Strategien. Ein Junior könnte sagen "Caching verbessert die Performance." Ein Senior erklärt, wann Caching Komplexität ohne Nutzen hinzufügt, wie bei hochgradig personalisierten oder sich schnell ändernden Daten.

Performance-Monitoring und Redis-Metriken

Produktionsanwendungen benötigen Einblick in die Cache-Performance. Wichtige Metriken umfassen:

Hit-Rate: Prozentsatz der Anfragen, die aus dem Cache bedient werden. Unter 80% deutet auf TTL- oder Key-Strategie-Probleme hin.
Speichernutzung: Der Redis-Befehl INFO memory zeigt aktuellen und maximalen Speicher.
Verbindungsanzahl: Zu viele Verbindungen deuten auf fehlendes Pooling hin.
Eviction-Anzahl: Nicht-null Evictions bedeuten, dass der Cache voll ist und Einträge verwirft.

redis-health.service.tstypescript

import { Injectable } from '@nestjs/common';
import Redis from 'ioredis';

@Injectable()
export class RedisHealthService {
  constructor(private redis: Redis) {}

  async getMetrics() {
    const info = await this.redis.info('stats');
    const memory = await this.redis.info('memory');
    
    const stats = this.parseInfo(info);
    const mem = this.parseInfo(memory);

    const hits = parseInt(stats.keyspace_hits, 10);
    const misses = parseInt(stats.keyspace_misses, 10);
    const hitRate = hits / (hits + misses) || 0;

    return {
      hitRate: (hitRate * 100).toFixed(2) + '%',
      usedMemory: mem.used_memory_human,
      connectedClients: stats.connected_clients,
      evictedKeys: stats.evicted_keys,
    };
  }

  private parseInfo(info: string): Record<string, string> {
    return info.split('\n').reduce((acc, line) => {
      const [key, value] = line.split(':');
      if (key && value) acc[key.trim()] = value.trim();
      return acc;
    }, {} as Record<string, string>);
  }
}

Diese Metriken über einen Health-Check-Endpunkt bereitstellen oder mit Prometheus für Produktions-Monitoring integrieren.

Redis-Caching und Sessions in Produktions-NestJS-Deployments

Das Deployment von NestJS mit Redis erfordert Aufmerksamkeit für mehrere betriebliche Aspekte:

Connection-String-Verwaltung: Redis-URLs in Umgebungsvariablen speichern, nicht im Code. Secrets-Management für Passwörter verwenden.
Graceful Shutdown: Redis-Verbindungen während des Anwendungs-Shutdowns schließen, um Connection-Leaks zu verhindern.
Retry-Logik: Exponentielles Backoff für Redis-Verbindungsfehler konfigurieren.
Separate Redis-Instanzen: Separate Redis-Instanzen für Cache und Sessions in Betracht ziehen. Cache-Eviction sollte Session-Daten nicht beeinflussen.

graceful-shutdown.tstypescript

import { Injectable, OnModuleDestroy } from '@nestjs/common';
import Redis from 'ioredis';

@Injectable()
export class RedisCleanup implements OnModuleDestroy {
  constructor(private redis: Redis) {}

  async onModuleDestroy() {
    await this.redis.quit();
  }
}

Für Microservices-Architekturen dient Redis auch als Message-Broker über die integrierte Transport-Schicht von NestJS und vereint Caching, Sessions und Inter-Service-Kommunikation.