Verteilte Datenbanken -Persistant Queues

Arno SchmidhauserLetzte Revision: März 2011Email: arno.schmidhauser@bfh.chWebseite: http://www.sws.bfh.ch/db

Nachteile des Two Phase Commit (2PC) in globalen Systemen

• 2PC verfolgt das ACID-Prinzip und erreicht damit eine globale Konsistenz unmittelbar nach jeder Transaktion.

• Die Verfügbarkeit der benötigten Datenbanken ist aber nicht immer kontrollierbar.

• Die Öffnung von Systemresourcen für das 2PC, wie der Zugriff auf die beteiligten Datenbanken, die 2PC-Fähigkeit, die Verfügbarkeit der gewünschten 2PC-API's für den Transaktionsmanager usw., ist nicht immer wünschens-wert oder möglich.

• Die Kontrolle über die Struktur der beteiligten Datenbanken, insbesondere über Unternehmen hinweg, ist nicht immer gegeben.

BASE ergänzt ACID

• Zunehmender Paradigmenwechsel: Eine verfügbare Applikation ist in vielen Fällen wichtiger als globale Konsistenz. Das C im ACID wird abgeschwächt zu:

– Basically Available (Vorrangige Verfügbarkeit)– Soft State (Sichtbare Zwischenzustände erlaubt)– Eventually Consistent (Konsistenz mit Verzögerung)

• Persistent Message Queues (PMQ) sind eine wichtige Realisierung dieses Prinzips

PMQ - Beispiel

• Das Bearbeiten und der Versand einer Bestellung hängen zeitlich unkritisch vom unmittelbaren Einkauf ab.

Shop/Bestellung(Amazon US)

DB 1

Lager/Versand(DE)

DB 2

PMQ Versandaufträge

begin transaction

// Message erstellen

// aus DB1

q.enqueue ( message )

commit

begin transaction

message = q.dequeue()

// Message in DB2

// hinein verarbeiten

commit

PMQ – Grundsätze (1)

• Versenden, Empfangen und Bearbeiten einer Message kann als asynchrone Transaktion auf einem globalen Datenbestand, mit zwischenzeitlich inkonsistentem Zustand, angesehen werden.

• Versand und Empfang können asynchron stattfinden.• Werden die Message selbst in einer Datenbank

abgespeichert, ist deren Verarbeitung nach einer bestimmten Zeit garantiert.

• Die Verarbeitung ist skalierbar durch parallele arbeitende Message-Produzenten und Message-Konsumenten.

PMQ – Grundsätze (2)

• Message Queues haben generische, aplikationsunab-hängige Eigenschaften, was ihre Verwendung einfach macht:– First-in / First-out Prinzip– enqueue() und dequeue() Methoden

• Hilfsmethoden ergänzen das generische Verhalten– Umgang mit vergifteten Messages– Timeouts für nicht abgeholte Meldungen– Filter für Typ, Absender, Empfänger etc.– Sortierung nach Priorität, Zeit etc.

Applikation 2

lokale Transaktion

Applikation 1

lokale Transaktion

Messageing = zeitlich entkoppelte Transaktionen (1)

Messageing-System

DB 1

mDB

DB 2

MessageMessagebegin transaction DB1

// Message erstellen aus DB1

commit DB1

begin transaction mDB

// Message in mDB übertragen

q.enqueue ( message )

commit mDB

begin transaction mDB

// Message konsumieren

message = q.deueue ()

commit mDB

begin transaction DB2

// Message verarbeiten in DB2

commit DB2

Applikation 2

lokale Transaktion

Applikation 1

lokale Transaktion

Messageing = zeitlich entkoppelte Transaktion (2)

Messageing-System

DB 1

mDB

DB 2

MessageMessagebegin transaction DB1

// Message erstellen aus DB1

begin transaction mDB

// Message in mDB übertragen

q.enqueue ( message )

commit mDB

commit DB1

begin transaction DB2

begin transaction mDB

// Message konsumieren

message = q.deueue ()

commit mDB

// Message verarbeiten in DB2

commit DB2

Messageing mit Two Phase Commit

Messageing-System

Applikation 1

DB 1

mDB

Applikation 2

DB 2

MessageMessage

Two Phase CommitTwo Phase Commit

begin transaction DB1, mDB

// Message erstellen aus DB1

// Message in mDB übertragen

q.enqueue ( message )

commit DB1, mDB

begin transaction DB2, mDB

// Message aus mDB konsumieren

message = q.deueue ()

// Message verarbeiten

commit DB2, mDB

Queue DB

PMQ Implementation mit Database API

• Zwei Prozesse greifen via API auf eine Queue-Datenbank zu (enqueue()/dequeue() Operationen über JDBC o.ä.).

• Die Queue-Datenbank befindet sich im lokalen Applikations-Umfeld.• Im einfachsten Fall alle drei DB's identisch.• 2PC ist jeweils zwischen DB1 und QueueDB resp. zwischen QueueDB

und DB2 möglich.

Prozess 1

Prozess DB 1

PMQ-API

Prozess 1

PMQ-API

Prozess DB 2

sql-Befehle

sql-Befehle

PMQ Implementation mit SOA

• Die PMQ ist ein vollständig unabhängiger Dienst, ev. geografisch und unternehmensmässig getrennt von den Message-Produzenten und –Konsumenten.

• PMQ-System wird über REST/HTTP- oder Web-Service angesprochen.

• Die Queue-Datenbank wird von einem unabhängigen Datenbanksystem (Resource Manager) kontrolliert.

• Kein 2PC sinnvoll.• Beispiel Amazon SQS

– HTTP Interface– WSDL Interface

• Viele weitere professionelle Queueing Systeme, z.B. IBM WebSphere MQ, Microsoft, Oracle, Apache usw.

Vollständig sicheres Messageing ohne Two Phase Commit

Messageing-Applikation

Sender

DB 1

Empfänger

DB 2

MessageNr 12

MessageNr 12

LMN

(z.B. 11)