Ich bin sicher, Sie haben das kommen sehen, "Es kommt darauf an".
Es hängt von allem ab. Und die Lösung für die gemeinsame Nutzung von Kundendaten für Abteilung A kann völlig anders sein als für die gemeinsame Nutzung von Kundendaten für Abteilung B.
Mein Lieblingskonzept, das im Laufe der Jahre entstanden ist, ist das Konzept der "Eventual Consistency". Der Begriff stammt von Amazon und spricht von verteilten Systemen.
Die Prämisse ist, dass der Zustand der Daten in einem verteilten Unternehmen zwar jetzt nicht vollkommen konsistent sein kann, dies aber „irgendwann“ der Fall sein wird.
Wenn beispielsweise ein Kundendatensatz auf System A aktualisiert wird, sind die Kundendaten von System B jetzt veraltet und stimmen nicht überein. Aber "schließlich" wird der Datensatz von A durch einen Prozess an B gesendet. Letztendlich werden die beiden Instanzen also übereinstimmen.
Wenn Sie mit einem einzigen System arbeiten, haben Sie kein "EC", sondern sofortige Updates, eine einzige "Quelle der Wahrheit" und normalerweise einen Sperrmechanismus, um Race-Conditions und Konflikte zu handhaben.
Je besser Ihr Betrieb mit "EC"-Daten arbeiten kann, desto einfacher ist es, diese Systeme zu trennen. Ein einfaches Beispiel ist ein vom Vertrieb genutztes Data Warehouse. Sie verwenden die DW, um ihre täglichen Berichte zu erstellen, aber sie erstellen ihre Berichte nicht vor dem frühen Morgen, und sie sehen sich immer die Daten von „gestern“ (oder früher) an. Das DW muss also nicht unbedingt in Echtzeit mit dem täglichen Betriebssystem übereinstimmen. Es ist vollkommen akzeptabel, dass ein Prozess zum Beispiel bei Geschäftsschluss ausgeführt wird und Transaktionen und Aktivitäten über die Tage hinweg massenhaft in einem großen, einzelnen Aktualisierungsvorgang verschiebt.
Sie können sehen, wie diese Anforderung viele Probleme lösen kann. Es gibt keinen Streit um die Transaktionsdaten, keine Sorge, dass sich einige Berichtsdaten während der Erfassung der Statistik ändern werden, da der Bericht zwei separate Abfragen an die Live-Datenbank durchführte. Es ist nicht erforderlich, dass das hochdetaillierte Geschwätz tagsüber die Netzwerk- und CPU-Verarbeitung usw. aufsaugt.
Nun, das ist ein extremes, vereinfachtes und sehr grobes Beispiel für EC.
Aber denken Sie an ein großes System wie Google. Als Nutzer der Suche haben wir keine Ahnung, wann oder wie lange es dauert, bis ein Suchergebnis, das Google sammelt, auf einer Suchseite so weit oben ist. 1 ms? 1s? 10er? 10 Std.? Es ist leicht vorstellbar, dass Sie, wenn Sie auf die Server von Google an der Westküste zugreifen, möglicherweise ein anderes Suchergebnis erhalten, als wenn Sie auf die Server an der Ostküste zugreifen. Zu keinem Zeitpunkt sind diese beiden Instanzen vollständig konsistent. Aber im Großen und Ganzen sind sie meistens konsistent. Und für ihren Anwendungsfall sind ihre Verbraucher nicht wirklich von der Verzögerung und Verzögerung betroffen.
Betrachten Sie E-Mail. A möchte eine Nachricht an B senden, aber dabei wird die Nachricht durch die Systeme C, D und E geleitet. Jedes System nimmt die Nachricht an, übernimmt die volle Verantwortung dafür und übergibt sie dann an ein anderes. Der Absender sieht, wie die E-Mail ihren Weg geht. Der Empfänger vermisst es nicht wirklich, weil er nicht unbedingt weiß, dass es kommt. Es kann also ein großes Zeitfenster dauern, bis sich diese Nachricht durch das System bewegt, ohne dass jemand, der davon betroffen ist, weiß oder sich darum kümmert, wie schnell sie ist.
Andererseits hätte A mit B telefonieren können. "Ich habe es gerade gesendet, hast du es schon bekommen? Jetzt? Jetzt? Jetzt bekommen?"
Es gibt also eine Art zugrundeliegendes, implizites Leistungs- und Reaktionsniveau. Am Ende, "irgendwann", stimmt der Postausgang von A mit dem Posteingang von B überein.
Diese Verzögerungen, die Annahme veralteter Daten, ob sie einen Tag oder 1-5 Sekunden alt sind, steuern die endgültige Kopplung Ihrer Systeme. Je lockerer diese Anforderung, desto lockerer die Kopplung und desto mehr Gestaltungsspielraum steht Ihnen zur Verfügung.
Dies gilt bis zu den Kernen in Ihrer CPU. Moderne Anwendungen mit mehreren Kernen und mehreren Threads, die auf demselben System ausgeführt werden, können unterschiedliche Ansichten der „gleichen“ Daten haben, die nur um Mikrosekunden veraltet sind. Wenn Ihr Code korrekt mit Daten arbeiten kann, die möglicherweise nicht miteinander übereinstimmen, dann frohen Tag, es zischt mit. Wenn nicht, müssen Sie besonders darauf achten, dass Ihre Daten vollständig konsistent sind, indem Sie Techniken wie flüchtige Speicherqualifizierungen oder Sperrkonstrukte usw. verwenden. All dies kostet auf ihre Weise Leistung.
Das ist also die Grundüberlegung. Alle anderen Entscheidungen beginnen hier. Die Beantwortung dieser Frage kann Ihnen sagen, wie Sie Anwendungen zwischen Computern partitionieren, welche Ressourcen gemeinsam genutzt werden und wie sie gemeinsam genutzt werden. Welche Protokolle und Techniken sind verfügbar, um die Daten zu verschieben, und wie viel es in Bezug auf die Verarbeitung kosten wird, um die Übertragung durchzuführen. Replikation, Lastausgleich, Datenfreigabe usw. usw. Alles basiert auf diesem Konzept.
Bearbeiten, als Antwort auf den ersten Kommentar.
Richtig, genau. Das Spiel hier zum Beispiel, wenn B Kundendaten nicht ändern kann, was schadet es dann mit geänderten Kundendaten? Können Sie "riskieren", dass es für kurze Zeit veraltet ist? Vielleicht kommen Ihre Kundendaten so langsam herein, dass Sie sie sofort von A nach B replizieren können. Angenommen, die Änderung wird in eine Warteschlange gestellt, die aufgrund des geringen Volumens leicht abgeholt wird (<1 s), aber selbst dann wäre sie mit der ursprünglichen Änderung "außerhalb der Transaktion", und daher gibt es ein kleines Fenster, in dem A hätte Daten, die B nicht hat.
Jetzt fangen die Gedanken wirklich an zu kreisen. Was passiert während dieser 1s der "Verzögerung", was ist das schlimmstmögliche Szenario. Und können Sie es umgehen? Wenn Sie eine Verzögerung von etwa 1 Sekunde entwickeln können, können Sie möglicherweise eine Verzögerung von etwa 5 Sekunden, 1 Minute oder sogar länger entwickeln. Wie viele der Kundendaten verwenden Sie tatsächlich auf B? Vielleicht ist B ein System, das die Kommissionierung von Bestellungen aus dem Bestand erleichtern soll. Kaum vorstellbar, dass mehr nötig ist als nur eine Kunden-ID und vielleicht ein Name. Nur etwas, um grob zu identifizieren, für wen die Bestellung bestimmt ist, während sie zusammengestellt wird.
Das Kommissioniersystem muss nicht unbedingt alle Kundeninformationen bis zum Ende des Kommissioniervorgangs ausdrucken, und bis dahin kann die Bestellung in ein anderes System verschoben worden sein, das möglicherweise insbesondere mit Versandinformationen aktueller ist, so Am Ende benötigt das Kommissioniersystem kaum Kundendaten. Tatsächlich könnten Sie die Kundeninformationen innerhalb des Kommissionierauftrags EINGEBEN und denormalisieren, sodass eine spätere Synchronisierung nicht erforderlich oder zu erwarten ist. Solange die Kunden-ID korrekt ist (die sich sowieso nie ändern wird) und der Name (der sich so selten ändert, dass es sich nicht lohnt, darüber zu diskutieren), ist dies die einzige wirkliche Referenz, die Sie benötigen, und alle Ihre Auswahlzettel sind zum Zeitpunkt des Schöpfung.
Der Trick ist die Denkweise, die Systeme aufzubrechen und sich auf die wesentlichen Daten zu konzentrieren, die für die Aufgabe notwendig sind. Nicht benötigte Daten müssen nicht repliziert oder synchronisiert werden. Leute ärgern sich über Dinge wie Denormalisierung und Datenreduktion, besonders wenn sie aus der Welt der relationalen Datenmodellierung kommen. Und das aus gutem Grund mit Vorsicht zu genießen. Aber sobald Sie verteilt sind, haben Sie implizit denormalisiert. Verdammt, du kopierst es jetzt en gros. Sie können also genauso gut klüger sein.
All dies kann durch solide Verfahren und ein gründliches Verständnis des Arbeitsablaufs gemildert werden. Identifizieren Sie die Risiken und erarbeiten Sie Richtlinien und Verfahren, um damit umzugehen.
Aber der schwierige Teil besteht darin, am Anfang die Kette zur zentralen DB zu unterbrechen und die Leute zu unterrichten, dass sie nicht "alles haben" können, wie sie es vielleicht erwarten, wenn Sie einen einzigen, zentralen, perfekten Informationsspeicher haben.
