Ich habe die Dokumentation der neuesten Version (veröffentlicht am 30. Juni 2016) von etcd3, die viele Verbesserungen gegenüber etcd2 hat. Es gehörtAusführlicher Vergleich zwischen Apache Kurator und etcd3
- Multiplex-Streaming-Uhren über eine einzige TCP-Verbindung
- inkrementelle Snapshots Leistungsverschlechterungen zu vermeiden, wenn Erstellen von Snapshots.
- Grpc Anrufe zur Verbesserung der Client-Leistung
- gemultiplexte Streaming-Leasing, um die Netzwerkauslastung zu verringern.
Wenn es um apache curator geschrieben oben auf apache zookeeper, die Vorteile davon sind ein zuverlässiges, ausgereiftes Projekt mit vielen aktiven Kunden ist es in der Produktion verwendet wird.
Zookeeper verwenden separate TCP-Verbindung pro Uhr und verwenden separate TCP-Verbindung pro Leasing. Darüber hinaus benachrichtigt der Watch-Watch-Service nur ein Ereignis pro Watch-Anfrage und wir müssen eine weitere Watch-Anfrage stellen, wenn wir kontinuierlich einen bestimmten Knoten beobachten wollen. Da etcd3 Streams mit Multiplexing verwendet, erschöpft es das Netzwerk nicht mit überschüssigen TCP-Verbindungen.
Auch etcd3 und zookeeper verwenden zwei verschiedene Algorithmen für Konsens, ZAB und raft, wo Floß ist weniger komplex.
Ich möchte distributed locks, (use) watches and need to write a mechanism to share commands throughout the cluster using the watch api implementieren. Diese Implementierung wird an einen ESB angeschlossen, der in Java geschrieben ist.
Jetzt ist meine Frage, welche von denen (Kurator/etcd3) sollte ich für meine Implementierung wählen und warum?
Ich würde gerne eine gute Erklärung sehen, da ich keinen direkten Vergleich dieser beiden Implementierungen finden konnte.
Vielen Dank im Voraus!
Eine einfache Frage ist, in welcher Sprache Ihr Client sein wird. Ich glaube nicht, dass es einen guten Java-Client für etcd oder Konsul gibt. Umgekehrt glaube ich nicht, dass es einen guten Go-Client für ZooKeeper gibt. – Randgalt
Nein, "Kunde" oder die Sprache des Kunden ist eigentlich keine Frage. Wenn es eine gute API hat, ist das Schreiben eines Clients nur eine Frage der Zeit. Was mich betrifft, sind "Pros" und "Nachteile" jeder Implementierung gegenüber der anderen. –
"Wenn es eine gute API hat" - groß "if". Selbst mit einer guten API gibt es normalerweise Idiome/Rezepte usw., die das Schreiben von erfolgreichen Anwendungen schwierig oder einfach machen können. Stellen Sie sich eine Datenbank ohne einen guten Treiber vor. – Randgalt