Jeg er sikker på, at du så dette komme, "Det kommer an på".
Det afhænger af alt. Og løsningen på at dele kundedata for afdeling A kan være helt anderledes for at dele kundedata med afdeling B.
Mit yndlingskoncept, der er steget op gennem årene, er konceptet "Eventual Consistency". Udtrykket kom fra Amazon, der taler om distribuerede systemer.
Forudsætningen er, at selvom datatilstanden på tværs af en distribueret virksomhed måske ikke er helt konsistent nu, vil den "til sidst" være det.
For eksempel, når en kunderegistrering bliver opdateret på system A, er system B's kundedata nu forældede og ikke matchende. Men "til sidst" vil posten fra A blive sendt til B gennem en eller anden proces. Så til sidst vil de to forekomster matche.
Når du arbejder med et enkelt system, har du ikke "EC", snarere har du øjeblikkelige opdateringer, en enkelt "kilde til sandhed" og typisk en låsemekanisme til at håndtere raceforhold og konflikter.
Jo bedre dine operationer er i stand til at arbejde med "EC"-data, jo lettere er det at adskille disse systemer. Et simpelt eksempel er et datavarehus, der bruges af salg. De bruger DW til at køre deres daglige rapporter, men de kører ikke deres rapporter før tidligt om morgenen, og de ser altid på data fra "yesterdays" (eller tidligere). Så der er ikke noget tidsmæssigt behov for, at DW er perfekt i overensstemmelse med det daglige driftssystem. Det er helt acceptabelt, at en proces køres ved f.eks. forretningsafslutning og bevæger sig over dagenes transaktioner og aktiviteter i massevis i en stor, enkelt opdateringsoperation.
Du kan se, hvordan dette krav kan løse en masse problemer. Der er ingen uenighed om transaktionsdataene, ingen bekymringer om, at nogle rapportdata vil ændre sig midt i akkumuleringen af statistikken, fordi rapporten lavede to separate forespørgsler til den levende database. Det er ikke nødvendigt for den høje detalje-snak at suge netværk og cpu-behandling osv. op i løbet af dagen.
Det er et ekstremt, forenklet og meget groft eksempel på EF.
Men overvej et stort system som Google. Som forbruger af Search har vi ingen idé om, hvornår eller hvor lang tid det tager for et søgeresultat, som Google høster, til hvor op på en søgeside. 1 ms? 1s? 10'erne? 10 timer? Det er let at forestille sig, hvordan hvis du rammer Googles vestkystservere, kan du meget vel få et andet søgeresultat, end hvis du rammer deres østkystservere. På intet tidspunkt er disse to tilfælde fuldstændig konsistente. Men i høj grad er de for det meste konsekvente. Og for deres brug er deres forbrugere ikke rigtig påvirket af forsinkelsen og forsinkelsen.
Overvej e-mail. A ønsker at sende besked til B, men i processen bliver beskeden dirigeret gennem system C, D og E. Hvert system accepterer beskeden, påtager sig det fulde ansvar for den og videregiver den til et andet. Afsenderen ser e-mailen gå på vej. Modtageren savner det ikke rigtig, fordi de ikke nødvendigvis ved, at det kommer. Så der er et stort tidsrum, som det kan tage for den besked at bevæge sig gennem systemet, uden at nogen bekymrer sig om, eller bekymrer sig om, hvor hurtigt det er.
På den anden side kunne A have været i telefonen med B. "Jeg har lige sendt det, har du fået det endnu? Nu? Nu? Få det nu?"
Der er således en form for underliggende, underforstået niveau af ydeevne og respons. I sidste ende, "til sidst", matcher A's udbakke B-indbakke.
Disse forsinkelser, accepten af forældede data, uanset om de er en dag gamle eller 1-5 sekunder gamle, er det, der styrer den ultimative kobling af dine systemer. Jo løsere dette krav er, jo løsere er koblingen, og jo mere fleksibilitet har du til din rådighed med hensyn til design.
Dette er sandt ned til kernerne i din CPU. Moderne multi-core, multi-threaded applikationer, der kører på det samme system, kan have forskellige visninger af de "samme" data, kun mikrosekunder forældede. Hvis din kode kan fungere korrekt med data, der potentielt er inkonsistente med hinanden, så god dag, lyner den sammen. Hvis ikke, skal du være særlig opmærksom for at sikre, at dine data er fuldstændig konsistente, ved at bruge teknikker som flygtig hukommelse, eller låsekonstruktioner osv. Alt sammen, som på deres måde koster ydeevne.
Så dette er den grundlæggende betragtning. Alle de andre beslutninger starter her. Ved at svare på dette kan du fortælle dig, hvordan du partitionerer applikationer på tværs af maskiner, hvilke ressourcer der deles, og hvordan de deles. Hvilke protokoller og teknikker er tilgængelige til at flytte dataene, og hvor meget det vil koste i form af behandling at udføre overførslen. Replikering, belastningsbalancering, datadeling osv. osv. Alt sammen baseret på dette koncept.
Rediger som svar på første kommentar.
Korrekt, præcis. Spillet her, for eksempel, hvis B ikke kan ændre kundedata, hvad er så skaden med ændrede kundedata? Kan du "risikere" at det er forældet i kort tid? Måske kommer dine kundedata så langsomt ind, at du kan replikere dem fra A til B med det samme. Lad os sige, at ændringen sættes i en kø, der på grund af lav lydstyrke let bliver afhentet (<1 sek.), men alligevel ville den være "ude af transaktion" med den oprindelige ændring, og så er der et lille vindue, hvor A ville have data, som B ikke gør.
Nu begynder sindet for alvor at snurre. Hvad sker der under de 1'ere af "lag", hvad er det værst tænkelige scenarie. Og kan du ingeniør omkring det? Hvis du kan konstruere omkring en 1s forsinkelse, kan du muligvis konstruere omkring en 5s, 1m eller endnu længere forsinkelse. Hvor meget af kundedata bruger du egentlig på B? Måske er B et system designet til at lette ordreplukning fra lager. Svært at forestille sig noget mere nødvendigt end blot et kunde-id og måske et navn. Bare noget for groft at identificere, hvem ordren er til, mens den bliver samlet.
Plukkesystemet behøver ikke nødvendigvis at udskrive alle kundeoplysningerne før slutningen af plukkeprocessen, og på det tidspunkt kan ordren være gået videre til et andet system, der måske er mere aktuelt med især forsendelsesoplysninger, så i sidste ende behøver plukkesystemet næsten ikke nogen kundedata overhovedet. Faktisk kunne du EMBED og denormalisere kundeoplysningerne i plukkeordren, så der ikke er behov for eller forventning om at synkronisere senere. Så længe kunde-id'et er korrekt (som aldrig ændres alligevel) og navnet (som ændres så sjældent, at det ikke er værd at diskutere), er det den eneste rigtige reference, du har brug for, og alle dine plukkesedler er helt nøjagtige på tidspunktet for skabelse.
Tricket er tankegangen, at bryde systemerne op og fokusere på de væsentlige data, der er nødvendige for opgaven. Data, du ikke har brug for, behøver ikke at blive replikeret eller synkroniseret. Folk gnaver på ting som denormalisering og datareduktion, især når de kommer fra den relationelle datamodelleringsverden. Og med god grund bør det overvejes med forsigtighed. Men når du først er blevet distribueret, har du implicit denormaliseret. For pokker, du kopierer det engros nu. Så du kan lige så godt være klogere på det.
Alt dette kan afbødes gennem solide procedurer og grundig forståelse af arbejdsgangen. Identificer risiciene og udarbejde politikker og procedurer for at håndtere dem.
Men den svære del er at bryde kæden til den centrale DB i begyndelsen og instruere folk om, at de ikke kan "få det hele", som de måske forventer, når du har et enkelt, centralt, perfekt lager af information.