Arbeite mit zwei separaten Redis-Instanzen mit sidekiq?

8

Guten Tag,

Ich habe zwei separate, aber verwandte Apps. Sie sollten beide ihre eigenen Hintergrundwarteschlangen haben (lesen: separate Sidekiq- und Redis-Prozesse) . Ich würde jedoch gelegentlich in der Lage sein, Jobs von app2 auf die Warteschlange von app1 zu schieben.

Von einer einfachen Warteschlangen- / Push-Perspektive aus wäre es einfach, dies zu tun, wenn app1 keinen vorhandenen Sidekiq / Redis-Stack hätte:

%Vor%

Aber da ich bereits Sidekiq.configure_client und Sidekiq.configure_server von app1 aufgerufen hätte, gibt es wahrscheinlich einen Schritt dazwischen, wo etwas passieren muss.

Offensichtlich könnte ich einfach den Serialisierungs- und Normalisierungscode direkt aus Sidekiq nehmen und manuell auf% cis_de% 's Redis Queue schieben, aber das scheint eine spröde Lösung zu sein. Ich würde gerne die Funktionalität app2 verwenden können.

Ich nehme an, meine ideale Lösung wäre etwa so:

Client.push SidekiqTWO.configure_client { remote connection..... }

Oder sogar:

SidekiqTWO::Client.push(job....)

$redis_remote = remote_connection.....

Offensichtlich ein bisschen witzig, aber das ist mein idealer Anwendungsfall.

Danke!

    
Brandon 07.02.2013, 00:47
quelle

3 Antworten

8
___ qstnhdr ___ Arbeite mit zwei separaten Redis-Instanzen mit sidekiq? ___ answer40074762 ___

Ich bin auf dieses Problem gestoßen und habe einige Probleme festgestellt, weil ich Redis::Distributed verwende, was das Lesen von Nachrichten aus der Warteschlange erschwert.

Aufbauend auf der Antwort von ARO benötigen Sie weiterhin das set redis_pool:

remote_sidekiq.rb

%Vor%

config / initializers / remote_sidekiq.rb

%Vor%

Jetzt erstellen wir anstelle des Arbeiters einen ActiveJob-Adapter, um die Anfrage in die Warteschlange zu stellen:

lib / aktiver_job / queue_adapters / remote_sidekiq_adapter.rb

%Vor%

Ich kann den Adapter verwenden, um die Ereignisse jetzt in die Warteschlange zu stellen:

%Vor%

Ich kann den Job jetzt mit der normalen ActiveJob API einreihen. Egal, welche App diese aus der Warteschlange liest, muss eine passende %code% verfügbar haben, um die Aktion auszuführen.

    
___ tag123redis ___ Redis ist eine Open-Source-Datenbank in Schlüssel-Wert-Speicher. Es wird oft als Datenstrukturserver bezeichnet, da Schlüsselwerte verschiedene Typen enthalten können: Strings, Hashes, Listen, Sets, sortierte Sets, Geospatial, HyperLogLogs, Bitfelder. Es bietet auch Pub-Sub-Funktion. ___ tag123rubyonrails ___ Ruby on Rails ist ein Open-Source-Full-Stack-Webanwendungsframework, das in Ruby geschrieben wurde. Es folgt dem populären MVC-Framework-Modell und ist bekannt für seinen "convention over configuration" -Ansatz für die Anwendungsentwicklung. ___ tag123queue ___ Eine Queue ist eine geordnete First-in-first-out-Datenstruktur. Typische Implementierungen von Warteschlangen unterstützen das Schieben von Elementen nach hinten und das Herausspringen von der vorderen Position. ___ tag123sidekiq ___ Sidekiq ist ein Framework für die Hintergrundverarbeitung von Ruby. ___ antwort19886023 ___

Eine Sache ist also Laut den FAQ , "Das Sidekiq-Nachrichtenformat ist ziemlich einfach und stabil : es ist nur ein Hash im JSON-Format." Hervorhebung meins-- Ich glaube nicht, JSON zu sidekiq zu schicken ist zu spröde, um es zu tun. Besonders wenn Sie eine genaue Steuerung wünschen, um welche Redis-Instanz Sie die Jobs senden, wie in der OP-Situation, würde ich wahrscheinlich nur einen kleinen Wrapper schreiben, der mir eine Redis-Instanz zusammen mit dem Job in die Warteschlange geben würde. p>

Für Kevin Bedells allgemeinere Situation, wenn es darum geht, Aufträge an Redis-Instanzen zu übertragen, würde ich mir vorstellen, dass Sie nicht die Kontrolle darüber haben wollen, welche Redis-Instanz verwendet wird - Sie wollen nur Enqueue und lassen Sie die Verteilung automatisch verwalten. Es sieht so aus, als ob bisher nur eine Person dies angefordert hat , und Sie haben eine Lösung gefunden , die %code% :

%Vor%

Eine weitere Sache, die Sie bei Ihrer Suche nach Hochverfügbarkeit und Fail-Over in Betracht ziehen sollten, ist Sidekiq Pro , die Zuverlässigkeitsfunktionen enthält: "Der Sidekiq Pro-Client kann vorübergehenden Redis-Ausfällen standhalten. Er wird Jobs bei Fehlern lokal in die Warteschlange einreihen und versuchen, diese Jobs zu liefern, sobald die Verbindung wiederhergestellt ist." Da sidekiq ohnehin für Hintergrundprozesse gedacht ist, sollte eine kurze Verzögerung, wenn eine Redis-Instanz ausfällt, Ihre Anwendung nicht beeinträchtigen. Wenn eine Ihrer beiden Redis-Instanzen ausfällt und Sie Round-Robin verwenden, haben Sie immer noch einige Jobs verloren, es sei denn, Sie verwenden diese Funktion.

    
___ qstntxt ___

Guten Tag,

Ich habe zwei separate, aber verwandte Apps. Sie sollten beide ihre eigenen Hintergrundwarteschlangen haben (lesen: separate Sidekiq- und Redis-Prozesse) . Ich würde jedoch gelegentlich in der Lage sein, Jobs von %code% auf die Warteschlange von %code% zu schieben.

Von einer einfachen Warteschlangen- / Push-Perspektive aus wäre es einfach, dies zu tun, wenn %code% keinen vorhandenen Sidekiq / Redis-Stack hätte:

%Vor%

Aber da ich bereits %code% und %code% von %code% aufgerufen hätte, gibt es wahrscheinlich einen Schritt dazwischen, wo etwas passieren muss.

Offensichtlich könnte ich einfach den Serialisierungs- und Normalisierungscode direkt aus Sidekiq nehmen und manuell auf% cis_de% 's Redis Queue schieben, aber das scheint eine spröde Lösung zu sein. Ich würde gerne die Funktionalität %code% verwenden können.

Ich nehme an, meine ideale Lösung wäre etwa so:

%code% %code%

Oder sogar:

%code%

%code%

Offensichtlich ein bisschen witzig, aber das ist mein idealer Anwendungsfall.

Danke!

    
___ answer29891095 ___

Wie Carols10cents sagt es ist ziemlich einfach, aber wie ich immer gerne die Fähigkeit kapseln und in der Lage sein, es in anderen Projekten wieder zu verwenden, habe ich eine Idee von einem Blog vom Hotel Tonight . Diese folgende Lösung verbessert das Hotel Tonight, das Rails 4.1 & amp; Frühling preloader.

Momentan begnüge ich mich mit dem Hinzufügen der folgenden Dateien zu %code% :

remote_sidekiq.rb

%Vor%

remote_sidekiq_worker.rb

%Vor%

Sie müssen einen Initialisierer erstellen, der redis_pool

setzt

config / initializers / remote_sidekiq.rb

%Vor%

Sie können dann einfach das %code% Modul wo immer Sie wollen. Arbeit erledigt!

**** FÜR GRÖSSERE UMGEBUNGEN ****

Das Hinzufügen von RemoteWorker-Modellen bietet zusätzliche Vorteile:

  1. Sie können die RemoteWorker überall wiederverwenden, einschließlich des Systems, das Zugriff auf die target sidekiq Worker hat. Dies ist für den Aufrufer transparent. Um das Formular "RemoteWorkers" im Sidekiq-Zielsystem zu verwenden, verwenden Sie einfach keinen Initialisierer, da standardmäßig der lokale Sidekiq-Client verwendet wird.
  2. Mit RemoteWorker können Sie sicherstellen, dass immer korrekte Argumente gesendet werden (der Code = Dokumentation)
  3. Die Skalierung durch Erstellen komplizierterer Sidekiq-Architekturen ist für den Aufrufer transparent.

Hier ist ein Beispiel für RemoteWorker

%Vor%     
___
carols10cents 10.11.2013, 03:40
quelle
1

Wie Carols10cents sagt es ist ziemlich einfach, aber wie ich immer gerne die Fähigkeit kapseln und in der Lage sein, es in anderen Projekten wieder zu verwenden, habe ich eine Idee von einem Blog vom Hotel Tonight . Diese folgende Lösung verbessert das Hotel Tonight, das Rails 4.1 & amp; Frühling preloader.

Momentan begnüge ich mich mit dem Hinzufügen der folgenden Dateien zu lib/remote_sidekiq/ :

remote_sidekiq.rb

%Vor%

remote_sidekiq_worker.rb

%Vor%

Sie müssen einen Initialisierer erstellen, der redis_pool

setzt

config / initializers / remote_sidekiq.rb

%Vor%

Sie können dann einfach das include RemoteSidekiqWorker Modul wo immer Sie wollen. Arbeit erledigt!

**** FÜR GRÖSSERE UMGEBUNGEN ****

Das Hinzufügen von RemoteWorker-Modellen bietet zusätzliche Vorteile:

  1. Sie können die RemoteWorker überall wiederverwenden, einschließlich des Systems, das Zugriff auf die target sidekiq Worker hat. Dies ist für den Aufrufer transparent. Um das Formular "RemoteWorkers" im Sidekiq-Zielsystem zu verwenden, verwenden Sie einfach keinen Initialisierer, da standardmäßig der lokale Sidekiq-Client verwendet wird.
  2. Mit RemoteWorker können Sie sicherstellen, dass immer korrekte Argumente gesendet werden (der Code = Dokumentation)
  3. Die Skalierung durch Erstellen komplizierterer Sidekiq-Architekturen ist für den Aufrufer transparent.

Hier ist ein Beispiel für RemoteWorker

%Vor%     
ARO 27.04.2015 08:49
quelle
0

Ich bin auf dieses Problem gestoßen und habe einige Probleme festgestellt, weil ich ActiveJob verwende, was das Lesen von Nachrichten aus der Warteschlange erschwert.

Aufbauend auf der Antwort von ARO benötigen Sie weiterhin das set redis_pool:

remote_sidekiq.rb

%Vor%

config / initializers / remote_sidekiq.rb

%Vor%

Jetzt erstellen wir anstelle des Arbeiters einen ActiveJob-Adapter, um die Anfrage in die Warteschlange zu stellen:

lib / aktiver_job / queue_adapters / remote_sidekiq_adapter.rb

%Vor%

Ich kann den Adapter verwenden, um die Ereignisse jetzt in die Warteschlange zu stellen:

%Vor%

Ich kann den Job jetzt mit der normalen ActiveJob API einreihen. Egal, welche App diese aus der Warteschlange liest, muss eine passende RemoteJob verfügbar haben, um die Aktion auszuführen.

    
Wheeyls 16.10.2016 19:54
quelle

Tags und Links