RabbitMQ und PHP (1) – RabbitMQ-Prinzipien und Betriebsbeispiele

RabbitMQ ist ein beliebtes Open-Source-Nachrichtenwarteschlangensystem, das in Erlang-Sprache entwickelt wurde und AMQP (Advanced Message Queuing Protocol) vollständig implementiert. Die Website ist: http://www.rabbitmq.com/ Es gibt Tutorials und Beispielcodes (Python und Java).
7af40ad162d9f2d36b6bf89fa8ec8a136327cc4c
Das AMPQ-Protokoll ist konzeptionell komplex, um verschiedene Anforderungen an Nachrichtenwarteschlangen zu erfüllen. Zunächst einmal startet RabbitMQ standardmäßig ohne jegliche Konfiguration. Damit es funktioniert, muss der Client eine Verbindung herstellen, den Switch einrichten usw. Werden diese Grundkonzepte nicht geklärt, kommt es leicht zu Problemen bei der späteren Programmierungsgestaltung.
1.vhosts: Virtueller Host.
Eine RabbitMQ-Entität kann mehrere Vhosts haben und Benutzer- und Berechtigungseinstellungen hängen von den Vhosts ab. Für allgemeine PHP-Anwendungen sind keine Benutzerberechtigungseinstellungen erforderlich. Verwenden Sie einfach das standardmäßig vorhandene „/“. Benutzer können das standardmäßig vorhandene „Gast“ verwenden. Ein einfaches Konfigurationsbeispiel:
$conn_args = array(
'host' => '127.0.0.1',
'port' => '5672',
'login' => ; 'guest',
'password' => 'guest',
'vhost'=>'/'
);
2. Verbindung und Kanal
Verbindung bezieht sich auf eine physische Verbindung. Über eine Verbindung können mehrere Kanäle hergestellt werden, was als logische Verbindung verstanden werden kann. In allgemeinen Anwendungen reicht ein Kanal aus und es besteht keine Notwendigkeit, weitere Kanäle zu erstellen. Beispielcode:
//Verbindung und Kanal erstellen
$conn = new AMQPConnection($conn_args);
if (!$conn->connect()) {
die("Verbindung zu nicht möglich der Broker!n");
}
$channel = new AMQPChannel($conn);
3.Exchange and Routingkey: Austausch- und Routingschlüssel
Um verschiedene Arten von Nachrichten zu unterscheiden, legen Sie fest Verstehen Sie die Konzepte von Switches und Routing. Senden Sie beispielsweise eine Nachricht vom Typ A an den Switch mit dem Namen „C1“ und eine Nachricht vom Typ B an den Switch mit dem Namen „C2“. Wenn der Client eine Verbindung zu C1 herstellt, um Warteschlangennachrichten zu verarbeiten, erhält er nur Nachrichten vom Typ A. Wenn es außerdem viele Nachrichten vom Typ A gibt, ist eine weitere Verfeinerung der Unterscheidung erforderlich. Wenn ein Client beispielsweise nur Nachrichten vom Typ A für K-Benutzer verarbeitet, wird zu diesem Zweck Routingkey verwendet.
$e_name = 'e_linvo'; //Schaltername
$k_route = array(0=> 'key_1', 1=> 'key_2'); //Routing-Schlüssel
//Schalter erstellen
$ex = new AMQPExchange($channel);
$ex->setName($e_name);
$ex->setType(AMQP_EX_TYPE_DIRECT); //direkter Typ
$ex- >setFlags(AMQP_DURABLE); //Persistenz
echo „Exchange Status:“.$ex->declare().“n“;
for($i=0; $i<5; $ i ){
echo "Send Message:".$ex->publish($message . date('H:i:s'), $k_route[i%2])."n";
}
Wie Sie dem obigen Code entnehmen können, reicht beim Senden einer Nachricht nur ein „Schalter“ aus. Der Absender muss sich keine Gedanken darüber machen, ob sich hinter dem Switch eine entsprechende Verarbeitungswarteschlange befindet. Routingkey kann eine leere Zeichenfolge sein. Im Beispiel verwende ich zwei Schlüssel, um Nachrichten abwechselnd zu senden, um die Rolle des Weiterleitungsschlüssels unten verständlicher zu machen.
Für Schalter gibt es zwei wichtige Konzepte:
A, Typ. Es gibt drei Typen: Der Fanout-Typ ist der einfachste, dieses Modell ignoriert den Routing-Schlüssel; der direkte Typ wird am häufigsten verwendet und verwendet einen bestimmten Routing-Schlüssel. Wenn Sie bei diesem Modell „key_1“ beim Empfang einer Nachricht binden, erhalten Sie nur die Nachricht von key_1; der letzte ist „Thema“. Dieser Modus ähnelt dem Direktmodus, unterstützt jedoch den Platzhalterabgleich, z. B. „key_*“. Es werden key_1 und key_2 akzeptiert. Das Thema sieht gut aus, kann jedoch zu Ungenauigkeiten führen. Daher wird empfohlen, Direct zu verwenden.
B, Beharrlichkeit. Switches, die für Persistenz angegeben sind, können nur beim Neustart neu erstellt werden, andernfalls muss der Client die Generierung neu deklarieren.
Es bedarf eines besonders klaren Konzepts: Die Persistenz des Schalters ist nicht gleichbedeutend mit der Persistenz der Nachricht. Nur Nachrichten in der Persistenzwarteschlange können beibehalten werden. Wenn keine Warteschlange vorhanden ist, hat die Nachricht selbst bei der Zustellung auch ein Persistenzflag Permanente Nachricht, kein Ad-hoc-Bedarf.
4. Warteschlange: Warteschlange
Nachdem ich so viel geredet habe, habe ich nur über die Warteschlange gesprochen. Tatsächlich ist die Warteschlange nur für den Empfänger (Verbraucher) bestimmt und wird vom Empfänger basierend auf der Nachfrage erstellt. Erst wenn die Warteschlange erstellt wird, sendet der Switch neu empfangene Nachrichten an die Warteschlange. Der Switch stellt keine Nachrichten ein, bevor die Warteschlange erstellt wird. Mit anderen Worten: Alle vor dem Einrichten der Warteschlange gesendeten Nachrichten werden verworfen. Das Bild unten ist klarer als das offizielle RabbitMQ-Bild – Queue ist Teil von ReceiveMessage.
024f78f0f736afc37053e415b219ebc4b7451266
Sehen wir uns ein Beispiel für das Erstellen einer Warteschlange und den Empfang von Nachrichten an:
$e_name = 'e_linvo'; //Name wechseln
$q_name = 'q_linvo'; //Warteschlangenname
$k_route = ''; //Routing-Schlüssel
//Verbindung und Kanal erstellen
$conn = new AMQPConnection($conn_args);
if (!$conn->connect()) {
die("Es kann keine Verbindung zum Broker hergestellt werden!n");
}
$channel = new AMQPChannel($conn);
//Schalter erstellen
$ex = new AMQPExchange($channel);
$ex->setName($e_name);
$ex - >setType(AMQP_EX_TYPE_DIRECT); //direkter Typ
$ex->setFlags(AMQP_DURABLE); //persistence
echo „Exchange Status:“.$ex->declare().“n“ ;
//Warteschlange erstellen
$q = new AMQPQueue($channel);
$q->setName($q_name);
$q->setFlags(AMQP_DURABLE); Persistenz
//Binden Sie den Switch und die Warteschlange und geben Sie den Routing-Schlüssel an
echo 'Queue Bind: '.$q->bind($e_name, $k_route)."n";
// Nachrichten im Blockierungsmodus empfangen
echo "Message:n";
$q->consume('processMessage', AMQP_AUTOACK); //Automatische ACK-Antwort
$conn->disconnect();
/**
* Verbrauchsrückruffunktion
* Nachricht wird verarbeitet
*/
function processMessage($envelope, $queue) {
var_dump($envelope->getRoutingKey);
$msg = $envelope->getBody() ;
echo $msg."n"; //Verarbeitung von Nachrichten
}
Wie Sie dem obigen Beispiel entnehmen können, kann ein Schalter entweder vom Nachrichtensender oder vom Nachrichtenkonsumenten erstellt werden.
Nach dem Erstellen einer Warteschlange (Zeile:20) muss die Warteschlange an den Switch gebunden werden (Zeile:25), bevor die Warteschlange funktionieren kann. Hier wird auch der Routingkey angegeben. Einige Informationen besagen, dass es sich um einen bindenden Schlüssel handelt, aber es ist tatsächlich dasselbe. Die Verwendung zweier Begriffe kann leicht verwechselt werden.
Es gibt zwei Möglichkeiten, Nachrichten zu verarbeiten:
A, einmalig. Bei Verwendung von $q->get([...]) wird die Nachricht sofort zurückgegeben, unabhängig davon, ob sie empfangen wurde oder nicht. Im Allgemeinen wird diese Methode zum Verarbeiten der Nachrichtenwarteschlange mithilfe von Polling verwendet. Mit $q->consum( callback, [...] ) wechselt das Programm in einen kontinuierlichen Überwachungszustand. Jedes Mal, wenn eine Nachricht empfangen wird, wird die durch den Callback angegebene Funktion erst einmal aufgerufen Rückruffunktion gibt FALSE zurück.
Zum Callback noch ein paar Worte: PHPs call_back unterstützt die Verwendung von Arrays, zum Beispiel: $c = new MyClass(); $c->counter = 100; $ c,'myfunc') ) Auf diese Weise können Sie die von Ihnen geschriebene Verarbeitungsklasse aufrufen. Die Parameterdefinition von myfunc in MyClass ist dieselbe wie die von ProcessMessage im obigen Beispiel.
Im obigen Beispiel bedeutet die Verwendung von $routingkey = '' den Empfang aller Nachrichten. Wir können es in $routingkey = 'key_1' ändern, und Sie können sehen, dass der einzige Inhalt im Ergebnis darin besteht, Routingkey auf key_1 zu setzen.
Hinweis: Routingkey = 'key_1' und Routingkey = 'Key_2' sind zwei verschiedene Warteschlangen. Annahme: Client1 und Client2 sind beide mit der Warteschlange von Schlüssel_1 verbunden. Nachdem eine Nachricht von Client1 verarbeitet wurde, wird sie von Client2 nicht verarbeitet. Routingkey = '' ist eine weitere Alternative. client_all ist an '' gebunden. Nachdem alle Nachrichten verarbeitet wurden, gibt es keine Nachrichten auf client1 und client2.
In Bezug auf das Programmdesign müssen Sie den Namen des Austauschs planen, die Verwendung von Schlüsseln zur Unterscheidung verschiedener Tag-Typen planen und den Nachrichtensendecode dort einfügen, wo die Nachricht generiert wird. Die Back-End-Verarbeitung kann einen oder mehrere Clients für jeden Schlüssel starten, um die Echtzeitverarbeitung der Nachrichten zu verbessern. Wie Sie PHP für die Multithread-Nachrichtenverarbeitung verwenden, wird im nächsten Abschnitt beschrieben.
Weitere Nachrichtenmodelle finden Sie unter: http://www.rabbitmq.com/tutorials/tutorial-two-python.html
b03533fa828ba61e15fc0e5f4034970a304e59b4
http://nonfu.me/p/8833. html
Das Obige stellt RabbitMQ und PHP (1) vor – die Prinzipien und Betriebsbeispiele von RabbitMQ, einschließlich relevanter Inhalte. Ich hoffe, es wird für Freunde hilfreich sein, die sich für PHP-Tutorials interessieren.