So verwenden Sie die Ablaufstrategie und die Speicherbeseitigungsstrategie von Redis

1 Legen Sie den Schlüssel mit der Ablaufzeit fest

expire key seconds
时间复杂度：O（1）

Legen Sie die Ablaufzeit des Schlüssels fest. Nach Ablauf der Zeit wird der Schlüssel automatisch gelöscht. In der Redis-Terminologie ist das mit einem Schlüssel verbundene Timeout flüchtig. key的过期时间。超时后，将会自动删除该key。在Redis的术语中一个key的相关超时是volatile的。

超时后只有对key执行DEL、SET、GETSET时才会清除。 这意味着，从概念上讲所有改变key而不用新值替换的所有操作都将保持超时不变。 例如，使用 INCR 递增key的值，执行 LPUSH 将新值推到 list 中或用 HSET 改变hash的field，这些操作都使超时保持不变。

• 使用 PERSIST 命令可以清除超时，使其变成一个永久key

• 若 key 被 RENAME 命令修改，相关的超时时间会转移到新key

• 若 key 被 RENAME 命令修改，比如原来就存在 Key_A，然后调用 RENAME Key_B Key_A 命令，这时不管原来 Key_A 是永久的还是设为超时的，都会由Key_B的有效期状态覆盖

注意，使用非正超时调用 EXPIRE/PEXPIRE 或具有过去时间的 EXPIREAT/PEXPIREAT 将导致key被删除而不是过期（因此，发出的key事件将是 del，而不是过期）。

1.1 刷新过期时间

对已经有过期时间的key执行EXPIRE操作，将会更新它的过期时间。有很多应用有这种业务场景，例如记录会话的session。

1.2 Redis 之前的 2.1.3 的差异

在 Redis 版本之前 2.1.3 中，使用更改其值的命令更改具有过期集的密钥具有完全删除key的效果。由于现在修复的复制层中存在限制，因此需要此语义。

EXPIRE 将返回 0，并且不会更改具有超时集的键的超时。

1.3 返回值

• 1 如果成功设置过期时间。

• 0 如果key

  Nach dem Timeout wird es nur gelöscht, wenn DEL, SET oder GETSET auf der Taste ausgeführt wird. Dies bedeutet, dass konzeptionell alle Vorgänge, die einen Schlüssel ändern, ohne ihn durch einen neuen Wert zu ersetzen, das Timeout unverändert lassen. Verwenden Sie beispielsweise INCR, um den Wert eines Schlüssels zu erhöhen, führen Sie LPUSH aus, um den neuen Wert in die Liste zu übertragen, oder verwenden Sie HSET zum Ändern Im Feld bleibt das Timeout bei diesen Vorgängen unverändert.
Verwenden Sie den Befehl PERSIST, um die Zeitüberschreitung zu löschen und ihn zu einem permanenten Schlüssel zu machen

• Wenn key durch den Befehl RENAME geändert wird, wird das zugehörige Timeout auf den neuen key übertragen.

• Wenn key wird durch den Befehl <code>RENAME geändert. Beispielsweise ist Key_A ursprünglich vorhanden, und dann wird der Befehl RENAME Key_B Key_A aufgerufen . Zu diesem Zeitpunkt wird der ursprüngliche Key_A ignoriert. Ob dauerhaft ist oder auf Timeout gesetzt ist, wird durch den Gültigkeitsstatus von Key_B außer Kraft gesetzt.

  Beachten Sie, dass der Aufruf von EXPIRE/ PEXPIRE mit einem nicht positiven Timeout oder EXPIREAT/PEXPIREAT mit einer vergangenen Zeit führt dazu, dass der Schlüssel gelöscht wird und nicht abläuft (das ausgegebene Schlüsselereignis ist also del und nicht abgelaufen).

  1.1 Ablaufzeit aktualisieren

  Durch die Ausführung der EXPIRE-Operation für einen Schlüssel, der bereits eine Ablaufzeit hat, wird seine Ablaufzeit aktualisiert. Es gibt viele Anwendungen für dieses Geschäftsszenario, beispielsweise die Sitzungsaufzeichnung.

  1.2 Unterschiede in Redis vor 2.1.3

  In Redis-Versionen vor 2.1.3 hatte das Ändern eines Schlüssels mit einem abgelaufenen Satz mithilfe des Befehls, der seinen Wert ändert, zur Folge, dass der Schlüssel vollständig gelöscht wurde. Diese Semantik ist aufgrund von Einschränkungen in der jetzt festgelegten Replikationsschicht erforderlich.

  EXPIRE gibt 0 zurück und ändert das Timeout für Schlüssel mit einem Timeout-Set nicht.

  1.3 Rückgabewert

  • 1 Wenn die Ablaufzeit erfolgreich festgelegt wurde.

  • 0 Wenn key nicht existiert oder die Ablaufzeit nicht eingestellt werden kann.
    1.4 Beispiel 🎜🎜🎜🎜🎜 Angenommen, es gibt einen Webdienst, der an den letzten N Seiten interessiert ist, die der Benutzer kürzlich besucht hat, sodass jeder benachbarte Seitenaufruf nicht mehr als 60 Sekunden nach der vorherigen Seite liegt. Stellen Sie sich diese Seitenaufrufe konzeptionell als eine Navigationssitzung für den Benutzer vor, die möglicherweise interessante Informationen zu den Produkten enthält, nach denen er gerade sucht, sodass Sie verwandte Produkte empfehlen können. 🎜🎜Dieses Muster kann in Redis mithilfe der folgenden Strategie leicht modelliert werden: Jedes Mal, wenn der Benutzer einen Seitenaufruf ausführt, rufen Sie den folgenden Befehl auf: 🎜

    MULTI
    RPUSH pagewviews.user:<userid> http://.....
    EXPIRE pagewviews.user:<userid> 60
    EXEC</userid></userid>

    🎜Wenn der Benutzer länger als 60 Sekunden inaktiv ist, wird der Schlüssel gelöscht und Es wird nur die Differenz protokolliert. Nachfolgende Seitenaufrufe in weniger als 60 Sekunden. Dieser Modus kann leicht geändert werden, um INCR anstelle einer Liste mit RPUSH zu verwenden. 🎜🎜1,5 Schlüssel mit Ablaufzeit🎜🎜Normalerweise werden Redis-Schlüssel ohne zugehörige Lebensdauer erstellt. Der Schlüssel bleibt bestehen, es sei denn, der Benutzer löscht ihn explizit (z. B. mit dem Befehl DEL). Verwenden Sie den Befehl EXPIRE, um einem bestimmten Schlüssel ein abgelaufenes Element zuzuordnen. Dies führt jedoch dazu, dass der Schlüssel zusätzlichen Speicher belegt. Redis löscht Schlüssel mit abgelaufenen Sätzen nach einer bestimmten Zeit automatisch, um sicherzustellen, dass die Daten nicht ablaufen. Die kritische Lebensdauer kann mit den Befehlen EXPIRE und PERSIST (oder anderen strengen Befehlen) aktualisiert oder vollständig entfernt werden. 🎜🎜1.6 Ablaufzeitgenauigkeit 🎜🎜Ablaufzeiten in Redis 2.4 können ungenau sein und zwischen 0 und 1 Sekunde schwanken. Seit Redis 2.6 liegt der Ablauffehler zwischen 0 und 1 Millisekunden. 🎜🎜1.7 Ablauf und Persistenz🎜🎜 Speichern Sie die Schlüssel abgelaufener Informationen als absolute Unix-Zeitstempel. Die Speichermethode auf Millisekundenebene ist für Redis Version 2.6 und höher geeignet. Dies bedeutet, dass die Zeit auch dann fließt, wenn die Redis-Instanz nicht aktiv ist. Damit der Ablauf gut funktioniert, muss die Computerzeit stabilisiert werden. Wenn Sie eine RDB-Datei von zwei Computern verschieben, deren Uhren stark desynchronisiert sind, können interessante Dinge passieren (z. B. das Laden aller veralteten Schlüssel). Auch beim Ausführen einer Instanz wird die Computeruhr immer überprüft. Wenn Sie beispielsweise einen Schlüssel auf 1000 Sekunden und dann die Computerzeit auf 2000 Sekunden in der Zukunft festlegen, läuft der Schlüssel sofort ab, anstatt 1000 Sekunden lang zu dauern. 🎜🎜2 So verfallen Schlüssel in Redis🎜🎜Es gibt zwei Möglichkeiten, Schlüssel ablaufen zu lassen: passiver Weg – verzögertes Löschen, aktiver Weg – regelmäßiges Löschen. 🎜🎜2.1 Verzögertes Löschen🎜🎜Wenn der Client versucht, auf den Schlüssel zuzugreifen, läuft der Schlüssel passiv ab, das heißt, Redis prüft, ob für den Schlüssel eine Ablaufzeit festgelegt ist, und wenn er abläuft, wird er gelöscht und nichts passiert zurückgegeben. Redis löscht den Schlüssel nicht automatisch, aber bei der Abfrage des Schlüssels prüft Redis träge, ob er gelöscht wurde. Dies ähnelt der verzögerten Initialisierung von Spring. 🎜

    当然，这是不够的，因为有过期的key，永远不会再访问。无论如何，这些key都应过期，因此请定期 Redis 在具有过期集的key之间随机测试几个key。已过期的所有key将从key空间中删除。

    2.2 定期删除

    具体来说，如下 Redis 每秒 10 次：

    1. 测试 20 个带有过期的随机键

    2. 删除找到的所有已过期key

    3. 如果超过 25% 的key已过期，从步骤 1 重新开始

    这是一个微不足道的概率算法，基本上假设我们的样本代表整个key空间，继续过期，直到可能过期的key百分比低于 25%。在任何特定时刻，已失效的最大键数等于每秒最大写入操作数除以4，这是由内存使用所决定的。

    2.3 在复制链路和 AOF 文件中处理过期的方式

    为了在不牺牲一致性的情况下获得正确行为，当key过期时，DEL 操作将同时在 AOF 文件中合成并获取所有附加的从节点。这样做的好处是能够将过时的处理过程集中在主节点中，避免出现一致性错误的可能性。

    但是，虽然连接到主节点的从节点不会独立过期key（但会等待来自master的 DEL），但它们仍将使用数据集中现有过期的完整状态，因此，当选择slave作为master时，它将能够独立过期key，完全充当master。

    由于您没有及时查找和删除大量过期key，这些过期key在Redis中堆积，导致内存严重耗尽

    因此还需有内存淘汰机制！

    3 内存淘汰

    3.1 内存淘汰策略

    

    noeviction（Redis默认策略）

    写请求无法继续服务 (DEL 请求除外)，但读请求可以继续进行。这样 可以保证不会丢失数据，但是会让线上的业务不能持续进行。

    • config.c

    createEnumConfig("maxmemory-policy", NULL, 
    	MODIFIABLE_CONFIG, maxmemory_policy_enum, 
    		server.maxmemory_policy, 
    			MAXMEMORY_NO_EVICTION, NULL, NULL),

    allkeys-random

    当内存不足以容纳新写入数据时，在键空间中，随机移除某key。凭啥随机呢，至少也是把最近最少使用的key删除。

    allkeys-lru(Least Recently Used)

    当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key，没有设置过期时间的 key 也会被淘汰。

    allkeys-lfu(Least Frequently Used)

    LRU的关键是看页面最后一次被使用到发生调度的时间长短，而LFU关键是看一定时间段内页面被使用的频率。

    volatile-lru

    优先淘汰最少使用的 key，其中包括设置了过期时间的 key。 没有设置过期时间的 key 不会被淘汰，这样可以保证需要持久化的数据不会突然丢失。与allkey-lru不同，这种策略仅淘汰过期的键集合。

    volatile-lfu

    volatile-random

    淘汰的 key 是过期 key 集合中随机的 key。

    volatile-ttl

    淘汰的策略不是 LRU，而是 key 的剩余寿命 ttl 的值，ttl 越小越优先被淘汰。

    volatile-xxx 策略只会针对带过期时间的 key 进行淘汰，allkeys-xxx 策略会对所有的 key 进行淘汰。

    • 如果你只是拿 Redis 做缓存，那应该使用 allkeys-xxx，客户端写缓存时不必携带过期时间。

    • 如果你还想同时使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，这样可以保留没有设置过期时间的 key，它们是永久的 key 不会被 LRU 算法淘汰。

    3.2 手写LRU

    确实有时会问这个，因为有些候选人如果确实过五关斩六将，前面的问题都答的很好，那么其实让他写一下LRU算法，可以考察一下编码功底

    你可以现场手写最原始的LRU算法，那个代码量太大了，不太现实

    public class LRUCache<k> extends LinkedHashMap<k> {
        
    private final int CACHE_SIZE;
    
        // 这里就是传递进来最多能缓存多少数据
        public LRUCache(int cacheSize) {
        	//  true指linkedhashmap将元素按访问顺序排序
            super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
            CACHE_SIZE = cacheSize;
        }
    
        @Override
        protected boolean removeEldestEntry(Map.Entry eldest) {
        	 // 当KV数据量大于指定缓存个数时，就自动删除最老数据
            return size() > CACHE_SIZE;
        }
    
    }</k></k>

Das obige ist der detaillierte Inhalt vonSo verwenden Sie die Ablaufstrategie und die Speicherbeseitigungsstrategie von Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!