Dieser Artikel stellt Ihnen eine Zusammenfassung der häufigsten Redis-Client-Ausnahmen vor (Jedis-Artikel). Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird für alle hilfreich sein.
【Einführung】Jedis ist die Client-Implementierung der Java-Version von Redis. Unabhängig davon, ob der Client während der Verwendung des Redis-Clients nicht ordnungsgemäß verwendet wird oder ein Problem mit dem Redis-Server vorliegt, reagiert der Client auf einige Ausnahmen. In diesem Artikel werden häufige Ausnahmen bei der Verwendung von Jedis analysiert. [Verwandte Empfehlungen: Redis-Video-Tutorial]
1. Es kann keine Verbindung aus dem Verbindungspool hergestellt werden
Die Anzahl der Jedis-Objekte in JedisPool ist begrenzt und der Standardwert ist 8. Es wird hier davon ausgegangen, dass die Standardkonfiguration verwendet wird und der Anrufer, wenn er Jedis von JedisPool ausleihen möchte, warten muss (wenn dies beispielsweise der Fall ist, ist maxWaitMillis>0 festgelegt). noch innerhalb der maxWaitMillis-Zeit. Wenn das Jedis-Objekt nicht abgerufen werden kann, wird die folgende Ausnahme ausgelöst.
redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool … Caused by: java.util.NoSuchElementException: Timeout waiting for idle object at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:449)
Es gibt eine andere Situation: Wenn blockWhenExhausted = false festgelegt ist, wird sofort eine Ausnahme ausgelöst, wenn der Aufrufer feststellt, dass sich keine Ressourcen im Pool befinden. Die folgende Ausnahme ist die Auswirkung von blockWhenExhausted = FALSCH.
redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool … Caused by: java.util.NoSuchElementException: Pool exhausted at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:464)
Bei diesem Problem muss besprochen werden, warum der Verbindungspool keine Ressourcen hat. Es gibt viele mögliche Gründe für den Mangel an Ressourcen
1: Die Einstellung des Verbindungspools ist bei hoher Parallelität und Versorgung zu klein Der Bedarf liegt über dem Bedarf, sodass der obige Fehler auftritt. Unter normalen Umständen muss er jedoch nur über der standardmäßigen maximalen Anzahl von Verbindungen (8) liegen, da die Verarbeitungseffizienz von JedisPool und Jedis unter normalen Umständen hoch genug ist.
2. Client: Der Verbindungspool wird nicht korrekt verwendet, z. B. nicht freigegeben, wie im folgenden Code gezeigt: Definieren Sie JedisPool und verwenden Sie die Standardkonfiguration des Verbindungspools.
GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();
JedisPool jedisPool = new JedisPool(poolConfig, "127.0.0.1", 6379);
//向JedisPool借用8次连接，但是没有执行归还操作。
for (int i = 0; i < 8; i++) {
Jedis jedis = null;
try {
jedis = jedisPool.getResource();
jedis.ping();
} catch (Exception e) {
e.printStackTrace();
}
}Wenn der Anrufer Jedis aus dem Verbindungspool ausleiht (wie folgt), wird eine Ausnahme ausgelöst:
jedisPool.getResource().ping();
3. Es gibt langsame Abfragevorgänge und die Rückgabegeschwindigkeit von Jedis-Objekten, die von diesen langsamen Abfragen gehalten werden wird sein Es ist relativ langsam, was dazu führt, dass der Pool voll ist.
4. Server: Der Client ist normal, aber der Redis-Server blockiert aus bestimmten Gründen den Client-Befehlsausführungsprozess, was auch dazu führt, dass der Client diese Ausnahme auslöst. Es ist ersichtlich, dass es viele Gründe für diese Ausnahme gibt. Lassen Sie sich nicht vom Auftreten der Ausnahme täuschen. Entwicklung, Betrieb und Wartung können ihr Verständnis von Redis nur kontinuierlich stärken Finden Sie nach und nach das Problem, indem Sie den Hinweisen folgen.
2. Client-Lese- und Schreib-Timeout
Wenn Jedis Redis aufruft und ein Lese- und Schreib-Timeout auftritt, wird die folgende Ausnahme angezeigt:
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out
Die Gründe für diese Ausnahme sind auch wie folgt:
Lesen und schreiben Das Timeout ist zu kurz eingestellt.
Der Befehl selbst ist relativ langsam.
Das Netzwerk zwischen Client und Server ist abnormal.
Redis selbst ist blockiert.
3. Client-Verbindungs-Timeout
Wenn Jedis Redis aufruft und ein Lese- und Schreib-Timeout auftritt, wird die folgende Ausnahme angezeigt:
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: connect timed out
Es gibt auch die folgenden Gründe für diese Ausnahme:
Verbindungs-Timeout-Einstellung ist ebenfalls vorhanden kurz.
Redis ist blockiert, wodurch das TCP-Backlog voll ist und neue Verbindungen fehlschlagen.
Das Netzwerk zwischen Client und Server ist abnormal.
4. Client-Puffer-Ausnahme
Wenn Jedis Redis aufruft und eine Client-Datenfluss-Ausnahme auftritt, tritt die folgende Ausnahme auf.
redis.clients.jedis.exceptions.JedisConnectionException: Unexpected end of stream.
Die Gründe für diese Ausnahme können folgende sein:
1 Der Ausgabepuffer ist voll. Stellen Sie beispielsweise den Ausgabepuffer eines normalen Clients auf 1M 1M 60 ein:
config set client-output-buffer-limit "normal 1048576 1048576 60 slave 268435456 67108864 60 pubsub 33554432 8388608 60"
Wenn Sie den Befehl get verwenden, um einen Bigkey (z. B. 3M) abzurufen, tritt diese Ausnahme auf.
2. Wenn die Verbindung, die längere Zeit inaktiv war, vom Server aktiv getrennt wird, können Sie die Timeout-Konfigurationseinstellungen überprüfen und prüfen, ob die eigene Verbindungspoolkonfiguration eine Leerlauferkennung erfordert.
3. Abnormales gleichzeitiges Lesen und Schreiben: Das Jedis-Objekt wird gleichzeitig von mehreren Threads betrieben, und die obige Ausnahme kann auftreten.
5. Lua-Skript wird ausgeführt
Wenn Redis derzeit ein Lua-Skript ausführt und das Lua-Zeitlimit überschreitet, erhält Jedis die folgende Ausnahme. Wie man mit dieser Art von Problem umgeht (die Lua-Lua-Time-Limit-Konfiguration wurde im vorherigen Kapitel vorgestellt) Dann wird die folgende Ausnahme empfangen.
redis.clients.jedis.exceptions.JedisDataException: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
7. Der von Redis verwendete Speicher überschreitet die maximale Speicherkonfiguration. Wenn Jedis Redis aufruft, um einen Schreibvorgang durchzuführen, wird die folgende Ausnahme empfangen Zeit sollte maxmemory angepasst und der Speicher gefunden werden, der das Problem verursacht (maxmemory wurde im vorherigen Kapitel vorgestellt)
redis.clients.jedis.exceptions.JedisDataException: LOADING Redis is loading the dataset in memory
8. Die Anzahl der Client-Verbindungen ist zu groß
Wenn der Wenn die Anzahl der Client-Verbindungen max. Clients überschreitet, wird die folgende Ausnahme in der neu angewendeten Verbindung angezeigt:
redis.clients.jedis.exceptions.JedisDataException: OOM command not allowed when used memory > 'maxmemory'.Zu diesem Zeitpunkt. Wenn ein neuer Client eine Verbindung herstellt, um einen Befehl auszuführen, lauten die zurückgegebenen Ergebnisse wie folgt:
127.0.0.1:6379> get hello (error) ERR max number of clients reached
这个问题可能会比较棘手，因为此时无法执行Redis命令，一般来说可以从两个方面进行着手。
1.客户端：如果maxclients参数不是很小的话，应用方的客户端连接数基本不会超过maxclients，通常来看是由于应用方对于Redis客户端使用不当造成的。此时如果应用方是分布式结构的话，可以通过下线部分应用节点(例如占用连接较多的节点)，使得Redis的连接数先降下来。从而让绝大部分节点可以正常运行，此时在再通过查找程序bug或者调整maxclients进行问题的修复。
2.服务端：如果此时客户端无法处理，而当前Redis为高可用模式(例如Redis Sentinel和Redis Cluster)，可以考虑将当前Redis做故障转移。
此问题不存在确定的解决方式，但是无论从哪个方面进行处理，故障的快速恢复极为重要，当然更为重要的是找到问题的所在，否则一段时间后客户端连接数依然会超过maxclients。
附赠GenericObjectPoolConfig的重要属性
原文地址：https://mp.weixin.qq.com/s?__biz=MjM5NTk0MTM1Mw==&mid=2650650677&idx=1&sn=cbb1cb9fefdf9641a4a7c775660114e8&chksm=bef9c6b3898e4fa5a31ac6e572dca4c20a37d6c1dcb41004d831b34300c5c9ae0ed8c3a1bb45&scene=21#wechat_redirect 作者：付磊
更多编程相关知识，请访问：编程教学！！
Das obige ist der detaillierte Inhalt vonHäufige Client-Ausnahmen bei der Verwendung von Jedis (Zusammenfassung). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
