Wie Sie bereits erwähnt haben, ist der Speicher in Seiten mit fester Größe aufgeteilt (1 MB oder Max. Projektierte Größe), und jede Seite gehört zu einer Partikelklasse. Am Anfang sind diese Seiten eigentlich keiner bestimmten Tafelklasse zugeordnet. Wann immer Anfragen eingehen, werden Plattenklassen für jeden Größenbereich erstellt und Seiten an sie angehängt.
Die Ermittlung der optimalen Brammenklasse ist der Schlüssel. Der Algorithmus sieht ungefähr so aus:
Überprüfen Sie die letzte Seite (die zuletzt zugewiesene Seite in dieser Slab-Klasse), um zu sehen, ob es offene/freie Chunks hat.
Wenn gefunden, speichern Sie dieses Objekt auf dieser Seite und kehren Sie zurück.
Suchen Sie andernfalls nach einer nicht zugewiesenen Seite und weisen Sie sie dieser Plattenklasse zu.
Wenn keine nicht zugewiesenen Seiten verfügbar sind (dies bedeutet nicht, dass der gesamte Speicher voll ist), machen Sie die LRU-Logik, um einen Chunk freizugeben, der längere Zeit nicht verwendet wurde (oder abgelaufen ist).
Speichern Sie dieses Objekt entweder auf dem gerade freigegebenen Chunk (ab Schritt 4) oder auf der leeren Seite (ab Schritt 3).
Jetzt, , um Ihre Frage zu beantworten.
Verwerfungen treten nur auf, wenn alle Seiten bestimmten Brammenklassen zugeordnet sind. Seither sind alle Seiten mit bestimmten Brammenklassen verbunden und bereit, Objekte/Gegenstände in diesem Größenbereich zu akzeptieren. Der verbleibende freie Speicher kann nicht für Objekte anderer Größe verwendet werden. d.h. sie können nicht in der Größe verändert werden. Dies ist der Einfachheit halber implementiert. Diese Methode eignet sich hervorragend für viele Webanwendungen, bei denen Objektgrößen fast die gleiche Größe haben wie Abfrageergebnisse, gerenderte HTML-Seiten. In diesem Fall weist Memcache alle Seiten, die es enthält, auf sehr wenige verwendete Klassen zu.
Ich erinnere mich irgendwo lesen, Redis ist flexibler in diesem Aspekt der Speichergröße.
Hoffe es hilft!