Heute habe ich festgestellt, dass die Standardverbindungsmethode von Jedis jedis = new Jedis ("localhost", 6379) ist und es immer zu einem Verbindungszeitlimit kommt. Später habe ich festgestellt, dass das Jedis-Klassenpaket auch eine Möglichkeit hat, die maximale Verbindungszeit festzulegen.
1->Um eine Jedis-Instanz zu erhalten, muss sie von JedisPool bezogen werden;
2->Nachdem die Jedis-Instanz aufgebraucht ist, müssen Sie sie an JedisPool zurückgeben.
3->Wenn Jedis während der Verwendung einen Fehler macht, muss dieser ebenfalls an JedisPool zurückgegeben werden;
Der Code lautet wie folgt
Kopieren Sie den Codecode wie folgt:
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxActive(100);
config.setMaxIdle(20);
config.setMaxWait(1000l);
JedisPool-Pool;
pool = new JedisPool(config, "2xx.xx.xx.14", 6379);
boolean commitOrOprSuccess = true;
versuchen {
jedis = pool.getResource();
// do redis opt by instance
} Catch (JedisConnectionException e) {
BorrowOrOprSuccess = false;
if (jedis != null)
pool.returnBrokenResource(jedis);
} Endlich {
if (borrowOrOprSuccess)
pool.returnResource(jedis);
}
jedis = pool.getResource();
JedisPool hängt vom Apache-Klassenpaket ab
commons-pool-1.5.6.jar
1->Obwohl JedisConnectionException ausgelöst wird, gibt es tatsächlich zwei Arten von Fehlern: Der eine ist pool.getResource(), der eine verfügbare jedis-Instanz nicht abrufen kann; der andere besteht darin, dass Fehler während jedis.set/get ebenfalls diese Ausnahme auslösen. Um die Unterscheidung zu realisieren, wird sie basierend darauf implementiert, ob die Instanz null ist. Wenn sie null ist, beweist dies, dass die Instanz überhaupt nicht initialisiert wurde, sodass keine Notwendigkeit besteht, sie an den Pool zurückzugeben ist nicht null, es beweist, dass es an den Pool zurückgegeben werden muss;
2->Wenn ein Instanzfehler auftritt, muss auch returnBrokenResource aufgerufen werden, um ihn an den Pool zurückzugeben. Andernfalls befinden sich beim nächsten Mal möglicherweise noch Daten im Puffer der über getResource abgerufenen Instanz, und es kann ein Problem auftreten!
Die Konfigurationsparameter von JedisPool hängen weitgehend von den tatsächlichen Anwendungsanforderungen sowie den Software- und Hardwarefunktionen ab. Ich habe Commons-Pool noch nie zuvor verwendet, daher habe ich dieses Mal einen ganzen Raum damit verbracht, mich mit der Bedeutung dieser Parameter zu befassen. . . Die meisten Konfigurationsparameter von JedisPool werden durch die entsprechenden Elemente von JedisPoolConfig zugewiesen.
maxActive: Steuert, wie viele Jedis-Instanzen einem Pool zugewiesen werden können. Wenn der Wert -1 ist, bedeutet dies, dass es keine Begrenzung gibt, wenn der Pool maxActive-Jedis-Instanzen zugewiesen hat Dieses Mal wird erschöpft, in JedisPoolConfig
maxIdle: Steuert die maximale Anzahl von Jedis-Instanzen im Leerlaufzustand, die ein Pool haben kann;
whenExhaustedAction: Gibt die vom Pool auszuführende Aktion an, wenn alle Jedis-Instanzen im Pool zugewiesen wurden. Standardmäßig gibt es drei Arten von WHEN_EXHAUSTED_FAIL (was bedeutet, dass es direkt ausgelöst wird, wenn keine Jedis-Instanz vorhanden ist).
NoSuchElementException), WHEN_EXHAUSTED_BLOCK (bedeutet, dass es blockiert ist oder eine JedisConnectionException geworfen wird, wenn maxWait erreicht ist), WHEN_EXHAUSTED_GROW (bedeutet, dass eine neue Jedis-Instanz erstellt wird, was bedeutet, dass der Satz maxActive nutzlos ist);
maxWait: gibt die maximale Wartezeit beim Ausleihen einer Jedis-Instanz an. Wenn die Wartezeit überschritten wird, wird direkt eine JedisConnectionException ausgelöst.
testOnBorrow: Legt beim Ausleihen einer Jedis-Instanz fest, ob die Alidate-Operation im Voraus ausgeführt werden soll. Wenn dies zutrifft, sind die erhaltenen Jedis-Instanzen verfügbar.
testOnReturn: ob der Validierungsvorgang im Voraus ausgeführt werden soll, wenn zum Pool zurückgekehrt wird;
testWhileIdle: Wenn true, bedeutet dies, dass ein Leerlaufobjekt-Evitor-Thread das Leerlaufobjekt scannt. Wenn die Validierung fehlschlägt, ist dieses Element nur dann von Bedeutung, wenn timeBetweenEvictionRunsMillis größer als 0 ist.
timeBetweenEvictionRunsMillis: gibt die Anzahl der Millisekunden an, die der Evitor für inaktive Objekte zwischen zwei Scans in den Ruhezustand versetzen muss;
numTestsPerEvictionRun: Gibt die maximale Anzahl von Objekten an, die jedes Mal vom inaktiven Objekt-Evitor gescannt werden;
minEvictableIdleTimeMillis: Gibt die Mindestzeit an, die ein Objekt mindestens im Leerlaufzustand verbleibt, bevor es vom Leerlaufobjekt-Evitor gescannt und entfernt werden kann. Dieses Element ist nur dann von Bedeutung, wenn timeBetweenEvictionRunsMillis größer als 0 ist.
softMinEvictableIdleTimeMillis: Basierend auf minEvictableIdleTimeMillis werden mindestens minIdle-Objekte zum Pool hinzugefügt. Bei -1 werden bei „evicted“ keine Objekte basierend auf der Leerlaufzeit entfernt. Wenn minEvictableIdleTimeMillis>0 ist, ist diese Einstellung bedeutungslos und nur dann sinnvoll, wenn timeBetweenEvictionRunsMillis größer als 0 ist.
lifo: Wenn BorrowObject ein Objekt zurückgibt, wird DEFAULT_LIFO (Last In First Out, die am häufigsten verwendete Warteschlange ähnlich dem Cache) verwendet. Wenn es False ist, bedeutet dies, dass es sich um eine FIFO-Warteschlange handelt.
Die Standardeinstellungen von JedisPoolConfig für einige Parameter lauten wie folgt:
testWhileIdle=true
minEvictableIdleTimeMills=60000
timeBetweenEvictionRunsMillis=30000
numTestsPerEvictionRun=-1