Dezentralisierte Systeme und peer-to-peer (P2P) Computing werden als technologische Voraussetzungen zukünftiger Internetanwendungen gesehen. Obwohl sich die Infrastrukturen unterscheiden, sind die Aufgaben der Anwendungen gleich oder ähnlich zu denjenigen Anwendungen, die den klassischen Client/Server-Ansatz benutzen: Bearbeitung und Speicherung von Daten. Abgesehen vom derzeitig populären P2P File-sharing gibt es viele Anwendungsszenarios, die eine Datenverwaltung benötigen, die ähnlich zu einer verteilten Datenverwaltung ist. Gleichzeitig muss sie aber in hoch-dynamischen Umgebungen funktionieren. Das größte Problem der P2P-Datenverwaltung ist die Gewährleistung und Konsistenzhaltung der Daten. Üblicherweise werden Daten bei der Erstellung repliziert und man hofft, dass mindestens eine der Repliken verfügbar ist, wenn sie gebraucht wird. Aufgrund unvorhersehbaren Verhalten der Peers garantiert die konfigurierte Anzahl der Repliken oft nicht die gewünschte Datenverfügbarkeit. Statt einer vordefinierten Anzahl von Repliken sollte sich die Anzahl der Repliken während der Laufzeit voll-autonom an die aktuelle Peerverfügbarkeit anpassen. Diese Doktorarbeit präsentiert ein dezentralisiertes und selbst-adaptives Replikationsprotokoll, das voll-transparent eine hohe Datenverfügbarkeit und -konsistenz mittels einer dynamischen verteilten Hash-Tabelle (DHT -- Distributed Hash Tables auf Englisch) garantiert. Die Lösung ist voll generisch und auf alle DHT-Implementierungen anwendbar, die DHT API bieten. Wenn sich die Peerverfügbarkeit ändert, dann muss das Protokoll in der Lage sein, dies festzustellen. Auf Basis der aktuellen Werte wird der Replikationsfaktor verändert, um die gewünschte Verfügbarkeit und Konsistenz zu behalten. Das Replikationsprotokoll basiert auf zwei wichtigen Aufnahmen: (1) ein Vermögen um ein dezentralisiertes Replikenverzeichnis aufzubauen und zu pflegen, und (2) ein Vermögen um genau die aktuelle Peerverfügbarkeit im System zu messen. Das Replikenverzeichnis benutzt die verteilte Hash-Tabelle als Basis und generiert mit der Hilfe einer definierten Funktion Schlüssel. Repliken sind mit zusätzlichen Systeminformationen wie ihre Version und Ordnungszahl unter den Schlüsseln gespeichert. Der Ansatz macht ermöglicht es, später eine Messmethode für die Peerverfügbarkeit zu definieren. Weil das gemeine DHT API keine Information über die Systemtopologie publiziert, ist es nicht möglich die Verfügbarkeit von den Peers direkt zu prüfen. Stattdessen prüft die vorgeschlagene Messmethode die Verfügbarkeit der Repliken. Es ist möglich mit der Hilfe der Konfidenzintervalltheorie zu berechnen, wie viele Proben ausreichen, dass die Messgebnisse einen niedrigen Fehler haben. Schließlich werden zwei Varianten des Protokolls definiert: Die erste nimmt an, dass Daten unveränderlich bleiben. Die zweite erlaubt, dass Daten während der Laufzeit modifiziert werden dürfen. Um festzulegen wie viele Repliken für gewisse konfigurierte Garantien gebraucht werden, wird ein analytisches Modell entwickelt. Wenn ein Peer feststellt, dass die aktuelle Peerverfügbarkeit und die Anzahl der Repliken nicht die gewünschte Garantien liefern, wird ein neuer Replikationsfaktor berechnet. Jetzt weiß der Peer, wie viele zusätzliche Repliken der Daten eingefügt werden sollen. Andererseits löschen Peers unnötige Repliken aus ihren Speichern, wenn die gleichen Garantien mit weniger Repliken auch erreicht werden. Datenreplikation erschwert die Erhaltung der Datenkonsistenz. Jede logische Datenaktualisierung wird in der Aktualisierung von mehreren Repliken übersetzt. Viele dieser Repliken können nicht zu jedem Zeitpunkt gefunden werden, da Peers, bei denen die Repliken gespeichert sind, nicht verfügbar sein können. Solche Bedingungen erlauben nur, dass die Daten eine schwache Konsistenz haben, bis alle Repliken aktualisiert sind. Vor der Aktualisierung kann keine Aussage über die Konsistenz der gefunden Daten gemacht werden. Das Replikationsprotokoll dieser Arbeit implementiert ein schwach-konsistentes Modell, aber mit einem Unterschied zu den bestehenden: Es bietet eine hohe Wahrscheinlichkeit, dass die gefundenen Daten, die vor allen Repliken aktualisiert werden, konsistent sind. So etwas ist möglich, wenn alle verfügbaren Repliken aktualisiert werden und dazu eine neue Version aller Offline-Repliken eingefügt werden. Sobald diese Repliken wieder online sind, werden über verpassende Updates informiert werden, werden die alten und neuen Versionen vereinigt. Deswegen garantiert das Protokoll mit einer hohen Wahrscheinlichkeit, dass mindestens eine konsistente Replik verfügbar ist. Der Ansatz wird mit Hilfe eines selbst-entwickeltes Simulators evaluiert. Die Ergebnisse zeigen, dass die Datenverfügbarkeit und -konsistenz voll-garantiert sind, wenn die Peerverfügbarkeit stabil oder ansteigend ist. Bei absteigender Verfügbarkeit, werden die Garantien nur bei langsamen Änderungen voll gepflegt. Bei schneller Senkung der Peerverfügbarkeit fallen die Garantien für einen gewissen Zeitabschnitt, aber nach der Stabilisierung des Systems werden wieder genug Repliken generiert, um die gewünschte Datenverfügbarkeit und -konsistenz wieder zu bekommen.