1 Geschwindigkeit verstehen MQ
Einführung Rabbitmg für die verteilte Transaktion zu lösen müssen die fünf Kernkonzepte beherrschen
Eine verteilte Messaging - Middleware, Netz hohe Parallelität Verarbeitung basierend auf Erlang Sprachentwicklung, mit dem Sprachniveau. Und das Spring Framework ist die gleiche Firma.
Unterstützung Ausdauer, hohe Verfügbarkeit
Fünf Kernkonzepte:
- Queue: Lokale realen Daten speichern
- Austausch: Empfangen einer Anforderung, die Daten-Dump
- Bind: Nach dem Empfang der Anforderung, wo zu speichern
- Anwendungsdaten übertragen: Meldung Produzent
- Nachricht Verbraucher: Entfernen Sie die Anwendungsdaten-Verarbeitungs
2, verteilte Transaktionsfragen
Verteilte Transaktion ist ein Business-Problem, nicht von der spezifischen Szene geschieden werden.
Mehrere Lösungen 2.1 verteilte Transaktionen
● basierte Datenbank XA / JTA Art und Weise einer Vereinbarung
bedarf die Datenbank - Anbieter zu unterstützen; JAVA - Komponente hat atomikos usw.
● asynchrone Korrektur liest die Art und Weise Daten
Alipay, Mikro-Kanal Pay Initiative Zahlungsstatus zu überprüfen, in Form von Rechnungen;
● Lösungen basieren auf zuverlässige Quellen (MQ) von
asynchronen Szene; universal stark; Ausbau der höher
● TCC Programmierlösungen
sorgfältig ausgewählt, Ali, Ameisen Goldkleid eigenes Paket DTX
Dieser Artikel Ziel: für alle die Menschen, lernen , das Problem der verteilten Transaktionen basierend auf verlässlichen Quellen zu lösen.
Lösungen für die verteilte Transaktion, sehr gezielte Geschäft ist es wichtig , Ideen anstelle des Kopierens
- US-Mission Kommentar Systemarchitektur
Verteilte Transaktionsprobleme zwischen mehreren Systemen 2.2
- Single-User-generierten Aufträge
- Bestellungen müssen Daten zu übergeben, damit zwei Transaktionskonsistenz Fragen zu erzeugen
Falscher Fall
Wenn der Schnittstellen Aufruf fehlschlägt, wird die Transaktion zurückzuAuftragsSystem gerollt, wird der Benutzer aufgefordert, den Betrieb versagt
误以为这样的接口调用写法，就不会有分布式事务问题
Interface Aufruf Erfolg oder Misserfolg, wird eine verteilte Transaktion Probleme haben:
- Schnittstellen-Aufruf erfolgreich ist, das Auftragssystem Datenbank Transaktionscommit fehlschlägt, wird das System nicht die waybill zurückrollen, erzeugen Daten
- Schnittstelle ruft ein Timeout, die Rollback-Bestellsystem Datenbanktransaktion, waybill Systemschnittstelle weiterhin Daten zu erzeugen,
In beiden Fällen kann es zu inkonsistenten Daten führen
3 zu erreichen, eine verteilte Transaktion - Fünf-Step
Lösen Sie verteilte Transaktionen über MQ 5 Stufen, sowie lokale verteilte Transaktionsverarbeitung Kenntnis zu nehmen
- Vor dem System der Bestellung der gesamte HTTP-Anforderungs-Schnittstelle waybill-System zu senden, ein Problem!
- Daher betrachten wir eine Nachricht an MQ asynchrone Grund auf neu!
3.1 Gesamtkonzept
Nach Aufträge Catering, waybill Erzeugungs Rechenzentrum langsam wartet, ist nicht zwingend Gleichzeitigkeit
- Zuverlässige Produktion: um sicherzustellen, dass die Nachricht an den Dienst Rabitmq gesendet werden müssen
- Zuverlässige Verbrauch: um sicherzustellen, dass die Nachricht die richtige verbraucht nehmen müssen
Und schließlich zu Mehrparteien-Daten Konsens zu erreichen.
3.2 Schritt 1 - zuverlässige Informationen aufgezeichnete Nachricht Herstellung
- Es gibt versteckte Gefahren - möglich, Nachrichten fehlgeschlagen es zu senden!
Um den Erfolg bestimmter Daten sicherzustellen , wird den MQ gesendet.
In der gleichen Transaktion ein Rekordanstieg in dem OP - Tisch, der Datensatz 每一条发往MQ的数据以及它的发送状态
so fügen wir einen lokalen Informationstabelle in der Reihenfolge System
So in der Praxis des Code, nicht durch das HTTP-Schnittstelle Aufruf Abrechnungssysteme Schnittstellen, aber die Verwendung von MQ
Wenn Aufträge zu erzeugen, sondern auch speichert die lokale Informationstabelle
3.3 Schritt 2 - Herstellung Reliable Messaging (Modifikationsnachricht Übertragungszustand)
- Verwendung RabbitMQ Transaktionsveröffentlichung Bestätigungsmechanismus (Bestätigen)
nach dem Öffnen, MQ genaue Annahmenachricht Empfangsbestät
- Dann in der Lage sein zu wissen, wie die lokale Informationstabelle aktualisieren
- Bestätigen Mechanismus, um sicherzustellen, offen in SB
- Wenn die Bestätigung nicht empfangen wird, die Nachricht fehlgeschlagen Modifikationszustand und andere besondere Umstände
兜底方案:定时检查消息表，超时没发送成功，再次重发
3.4 Schritt 3 - Reliable Messaging Verarbeitung (normale Verarbeitung)
- Nach waybill System empfängt geht die Nachrichtendaten plötzlich nach unten, oder die waybill besuchen, wenn DB, plötzlich ausfällt, wird die Nachricht über Sie erhobenen Daten nicht verloren !!!
Also brauchen wir die folgenden Eigenschaften:
Idempotent
verhindern doppelte Verarbeitung der Nachrichtendaten, eine Benutzeroperation, Datenzeitverarbeitung nur an entsprechende 
offenen 手动ACK模式
vom Verbraucher Steuernachricht Neuübertragung / Entfernen / Verwerfen
3.5 Schritt 4 - Reliable Messaging (Nachrichtenverbreitung)
Die Verbraucher Verarbeitung fehlschlägt, müssen wir wieder MQ wieder an den Verbraucher.
Abnormalitäten in der Regel mehrmals wiederholen durch die Verbraucher selbst die Rekordzahl von Wiederholungen, und die Anzahl der Kontrollen (nicht immer wiederholen!)
Fünfter Schritt 3.6 - Reliable Messaging (Nachrichten Discard)
Verbraucher Handhabung Versagen oder verworfen direkt an eine Warteschlange für unzustellbare übertragen (die DLQ)重试次数过多、消息内容格式错误等情况，通过线上预警机制通知运维人员
4 Zusammenfassung und Erweiterungen
Vor- und Nachteile von 4.1 MQ-Programm
Eröffnungsvorteil
- Vielseitigkeit
- Entwicklung und starke
- ausgereiftes Programm
Mouth Mängel
- Message-basierte Middleware, nur für asynchrone Szenarien
- Die Nachrichtenverarbeitung verzögert wird, müssen in der Lage sein auf die Unternehmen zu tolerieren
Versuchen Sie verteilte Transaktion zu vermeiden,
versuchen asynchrone Nicht-Kerngeschäfte zu machen;
4.2 Erweiterung
Theoretische Grundlage für die verteilte Transaktionslösungen
CAP Theorie
BASE Theorie
2PC Protokoll
3pc Protokoll
Paxos - Algorithmus.
Raft Kohärenzprotokoll
