Eine kurze Analyse der Verwendung von Nachrichtenwarteschlangen in Redis

Dieser Artikel führt Sie durch die erweiterte Verwendung von Redis – Nachrichtenwarteschlange und stellt die Verzögerungswarteschlange in Redis vor. Ich hoffe, er wird Ihnen hilfreich sein!

Apropos Nachrichtenwarteschlangen-Middleware: Wir alle denken an RabbitMQ, RocketMQ und Kafka, um asynchrone Messaging-Funktionen für Anwendungen zu implementieren. Hierbei handelt es sich um spezialisierte Middleware für Nachrichtenwarteschlangen mit mehr Funktionen, als wir verstehen können.

Diese Nachrichten-Middleware ist kompliziert zu verwenden, wie z. B. RabbitMQ. Bevor Sie eine Nachricht senden, müssen Sie Exchange und Warteschlange durch einige Regeln binden. Beim Senden einer Nachricht müssen Sie das Routing formulieren . -key, steuern Sie auch die Header-Nachricht. Dies gilt nur für Produzenten. Außerdem müssen Verbraucher die oben genannten umständlichen Schritte erneut durchlaufen, bevor sie Nachrichten konsumieren.

Für diejenigen, die keine 100-prozentige Zuverlässigkeit benötigen und einfache Anforderungen an die Nachrichtenwarteschlange implementieren möchten, können wir Redis verwenden, um uns von den umständlichen Schritten der Nachrichtenwarteschlangen-Middleware zu befreien.

Die Nachrichtenwarteschlange von Redis ist keine professionelle Nachrichtenwarteschlange. Sie verfügt weder über viele erweiterte Funktionen in der Nachrichtenwarteschlange noch über eine Bestätigungsgarantie. Wenn Sie das ultimative Streben nach Nachrichtenzuverlässigkeit haben, wenden Sie sich bitte an professionelle MQ-Middleware. [Verwandte Empfehlungen: Redis-Video-Tutorial]

Asynchrone Nachrichtenwarteschlange

Ausgehend von der einfachsten asynchronen Nachrichtenwarteschlange wird die Listendatenstruktur von Redis üblicherweise als asynchrone Nachrichtenwarteschlange verwendet und über lrpush/lpush in die Warteschlange gestellt. lpop zum Entfernen aus der Warteschlange.

Problem 1: Leere Warteschlange

Wenn beim Pop-Vorgang die Nachrichtenwarteschlange leer ist, gerät der Client in eine Endlosschleife von Pop, was zu einer Menge lebensverschwendender leerer Abfragen führt, was den Client dazu veranlasst Die CPU wird erhöht und der QPS von Redis wird ebenfalls erhöht.

Die Lösung für das obige Problem besteht darin, blpop/brpop der Listenstruktur zum Entfernen aus der Warteschlange zu verwenden, wobei das Präfix b für Blockieren und Blockieren des Lesens steht. Beim Blockieren von Lesevorgängen wechselt es in den Ruhezustand, wenn sich keine Daten in der Warteschlange befinden, und wacht auf, sobald die Daten eintreffen. Löst das oben genannte Problem perfekt.

Problem 2: Die Leerlaufverbindung wird getrennt

Die Lösung zum Blockieren von Lesevorgängen scheint perfekt zu sein, führt aber sofort zu einem anderen Problem: der Leerlaufverbindung. Wenn der Thread irgendwo weiterhin blockiert, wird die Redis-Client-Verbindung zu einer inaktiven Verbindung. Wenn die Leerlaufzeit zu lang ist, trennt der Redis-Server aktiv die Verbindung, um die Ressourcennutzung im Leerlauf zu reduzieren. Zu diesem Zeitpunkt löst blpop/brpop eine Ausnahme aus.

Wir müssen also beim Schreiben von Client-(Anwendungs-)Verbrauchern vorsichtig sein, auf das Abfangen von Ausnahmen achten und es erneut versuchen.

Anwendung 1: Verzögerungswarteschlange

In verteilten Redis-Sperren gibt es im Allgemeinen drei Strategien, um mit Sperrfehlern umzugehen:

• Eine Ausnahme direkt auslösen, und das Frontend erinnert den Benutzer daran, ob der Vorgang fortgesetzt werden soll

• Schlafen Sie und versuchen Sie es nach einer Weile erneut.

• Stellen Sie die Anfrage in die Verzögerungswarteschlange und versuchen Sie es nach einer Weile erneut.

Was die Verzögerungswarteschlange in Redis betrifft, können wir die zset (geordnete Liste) verwenden. Datenstruktur zu erreichen. Wir serialisieren die Nachricht als Zeichenfolge als Wert von zse und die Ablaufzeit der Verarbeitung (Verzögerungszeit) der Nachricht als Bewertung. Fragen Sie dann zset ab, um die Ablaufzeit für die Verarbeitung zu erhalten, und verwenden Sie zrem, um den Schlüssel aus zset zu entfernen, um den erfolgreichen Verbrauch darzustellen, und verarbeiten Sie dann die Aufgabe.

Der Kerncode lautet wie folgt:

// 生产\
public void delay(T msg) {\
  TaskItem task = new TaskItem();\
  task.id = UUID.randomUUID().toString(); // 分配唯一的 uuid\
  task.msg = msg;\
  String s = JSON.toJSONString(task); // fastjson 序列化\
  jedis.zadd(queueKey, System.currentTimeMillis() + 5000, s); // 塞入延时队列 ,5s 后再试\
}\
// 消费\
public void loop() {\
  while (!Thread.interrupted()) {\
   // zrangeByScore参数中0, System.currentTimeMills()代表从redis中去score范围在0到系统当前时间的数据， 0，1表示从0开始取1个 拓展传入的score为-inf, +inf 分别表示zset中的最大值和最小值，当你不知道zset中的score最值时就可以使用inf作为参数变量\
   Set values = jedis.zrangeByScore(queueKey, 0, System.currentTimeMillis(), 0, 1);\
   if (values.isEmpty()) {\
     try {\
       Thread.sleep(500); // 歇会继续\
    }\
     catch (InterruptedException e) {\
       break;\
    }\
     continue;\
  }\
   String s = values.iterator().next();  //消费队列\
   if (jedis.zrem(queueKey, s) > 0) { // 抢到了，要考虑到多线程下锁争抢的情况，只有rem成功代表成功的消费了一条消息。\
     TaskItem task = JSON.parseObject(s, TaskType); // fastjson 反序列化\
     this.handleMsg(task.msg);\
  }\
}\
}

Der obige Code wird im Multithreading für den Fall verwendet, dass dieselbe Aufgabe von mehreren Threads ausgeführt wird, obwohl die Aufgabe nach zrem verarbeitet werden kann, um die Situation einer Aufgabe zu vermeiden mehrfach konsumiert. Aber für die Threads, die die Aufgabe erhalten, sie aber nicht erfolgreich verarbeiten konnten, war es Zeitverschwendung, die Aufgabe zu erhalten. Daher können Sie erwägen, diese Logik durch Lua-Skripting zu optimieren. Durch das gemeinsame Verschieben von zrangeByScore und zrem auf den Server für atomare Operationen wird das Problem perfekt gelöst.

Weitere Kenntnisse zum Thema Programmierung finden Sie unter: Einführung in die Programmierung! !

Das obige ist der detaillierte Inhalt vonEine kurze Analyse der Verwendung von Nachrichtenwarteschlangen in Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!