Auswahl der Datenbanktechnologie basierend auf einem Anwendungsfall

Question

Ich erstelle einen API Limiter, und ich habe Probleme bei der Entscheidung, welches System für die Datenspeicherung verwendet werden soll.

Es ist wirklich klar, dass ich einen flüchtigen Speicher und einen dauerhaften Speicher brauche.

Auf dem flüchtig Ich mag einen Schlüssel-Wert wie folgt speichern:

read:14522145 100 
read:99885669 16 
read:78951585 100 

Dies ist ein Schlüssel ist, bestehend aus: {action}:{client} und ein Integer-Wert (verfügbare Mittel).

Auf der ständigen, möchte ich eine Aufzeichnung aller Ressourcenausfälle zu halten.

Der Algorithmus (Pseudocode) ist ziemlich einfach:

MAX_AMOUNT = 100 
call(action, client, cost) { 
    key = action + ":" + client 
    if (volatileStorage.hasKey(key)) { 
    value = volatileStorage.getValue(key) 
    if (value >= cost) { 
     volatileStorage.setValue(key, value - cost) 
     return true 
    } else { 
     persistentStorage.logOutage(method, client, cost) 
     return false 
    } 
    } else {   
     volatileStorage.setValue(key, MAX_AMOUNT) 
     return call(action, client, cost) 
    } 
} 

Es ist ein paralleler Prozess, der alle N Sekunden für jede method läuft, erhöht, dass alle Tasten {action}:* von M, bis O.

Zusätzlich möchte ich aus dem flüchtigen Speicher alle Elemente entfernen, die älter sind (seit dem nicht geändert) als P Sekunden.

Also im Grunde ist jede Aktion action<N, M, O, P>. Zum Beispiel wird das Lesen von Benutzern alle 1 Sekunde, um 5 Punkte, bis zu 100 erhöht und nach 60 Sekunden Inaktivität entfernt: read_users<1, 5, 100, 60>.

Also muss ich einen flüchtigen Speicher, der:

1. wirklich schnell liest, ohne zu viele Ressourcen zu verbrauchen (was ist der Punkt einen Anruf abzulehnen, wenn der Prozess teurer als der eigene Ruf ist).
2. Ermöglicht TTL für Elemente.
3. Kann, mit guter Leistung, alle Schlüssel zu einem Muster (read_users:*) erhöhen, ohne aus einem definierten Limit zu kommen.

und einem persistenten Speicher, die:

1. auch schnell ist.
2. Kann viele Register verarbeiten.

Jeder Rat ist willkommen.

Answer 1

Dies ist keine Antwort, sondern eine Meinung: Es gibt existierende Frequenzbegrenzer, die Sie besser verwenden würden, anstatt Ihre eigenen zu erstellen. Es ist schwierig, es in Ordnung zu bringen. Eine produktionsbewährte Implementierung ist daher nicht nur einfacher, sondern auch sicherer.

Zum Beispiel die Generic cell rate algorithm ist nichts weniger als Klar Magie und mehrere Redis Implementierungen, zB:

• Als Ruby-Juwel (das verwendet serverseitige Lua): https://github.com/rwz/redis-gcra
• Als (v4) Modul: https://github.com/brandur/redis-cell/

natürlich gibt es viele weitere Redis-basierten Rate Limiter sind - ich Google, sie zu finden verwenden;)