Сигурен съм, че сте забелязали това, „Зависи“.
Зависи от всичко. И решението за споделяне на клиентски данни за отдел А може да е напълно различно за споделяне на клиентски данни с отдел Б.
Любимата ми концепция, която се надигна през годините, е концепцията за „евентуална последователност“. Терминът идва от Amazon, когато говорим за разпределени системи.
Предпоставката е, че докато състоянието на данните в едно разпределено предприятие може да не е напълно последователно сега, то „евентуално“ ще бъде.
Например, когато клиентски запис се актуализира в система A, клиентските данни на система B вече са остарели и не съответстват. Но "в крайна сметка" записът от A ще бъде изпратен до B чрез някакъв процес. Така че в крайна сметка двата екземпляра ще съвпаднат.
Когато работите с една система, вие нямате „EC“, а по-скоро имате незабавни актуализации, един „източник на истина“ и обикновено заключващ механизъм за справяне със състезателни условия и конфликти.
Колкото по-способни са вашите операции да работят с "EC" данни, толкова по-лесно е да разделите тези системи. Прост пример е Data Warehouse, използван от продажбите. Те използват DW, за да изготвят ежедневните си отчети, но не изготвят отчетите си до рано сутринта и винаги гледат данните от „вчера“ (или по-рано). Така че няма нужда в реално време DW да бъде напълно съвместим с ежедневната операционна система. Напълно приемливо е даден процес да се изпълнява, да речем, при приключване на работа и да премества през дните транзакции и дейности масово в една голяма, единична операция за актуализиране.
Можете да видите как това изискване може да реши много проблеми. Няма конкуренция за транзакционните данни, няма притеснения, че някои данни в отчетите ще се променят по време на натрупването на статистиката, тъй като отчетът направи две отделни заявки към активната база данни. Няма нужда бърборенето с високи детайли да изсмуква обработката на мрежата и процесора и т.н. през деня.
Това е екстремен, опростен и много груб пример за ЕК.
Но помислете за голяма система като Google. Като потребители на Търсене, ние нямаме представа кога или колко време отнема резултат от търсенето, който Google събира до това как се качва на страница за търсене. 1ms? 1s? 10-ки? 10 часа? Лесно е да си представите как, ако посетите сървърите на Google в Западното крайбрежие, може много добре да получите различен резултат от търсенето, отколкото ако посетите техните сървъри в Източното крайбрежие. В нито един момент тези два случая не са напълно последователни. Но като цяло те са предимно последователни. И за техния случай на употреба техните потребители не са наистина засегнати от забавянето и забавянето.
Помислете за имейл. A иска да изпрати съобщение до B, но в процеса съобщението се пренасочва през система C, D и E. Всяка система приема съобщението, поема пълна отговорност за него и след това го предава на друга. Подателят вижда имейла да върви по пътя си. Получателят всъщност не го пропуска, защото не е задължително да знае, че идва. Така че има голям период от време, който може да отнеме това съобщение да премине през системата, без никой заинтересован да знае или да се интересува колко бързо е то.
От друга страна, А може да е говорил по телефона с Б. „Току-що го изпратих, получихте ли го? Сега? Сега? Вземете го сега?“
По този начин има някакъв вид основно, подразбиращо се ниво на изпълнение и реакция. В крайна сметка, "в крайна сметка", изходящата кутия на A съвпада с входящата кутия на B.
Тези забавяния, приемането на остарели данни, независимо дали са на един ден или на 1-5 секунди, са това, което контролира окончателното свързване на вашите системи. Колкото по-свободно е това изискване, толкова по-свободно е свързването и толкова по-голяма гъвкавост имате на ваше разположение по отношение на дизайна.
Това важи до ядрата във вашия процесор. Модерни, многоядрени, многонишкови приложения, работещи на една и съща система, могат да имат различни изгледи на „едни и същи“ данни, остарели само за микросекунди. Ако вашият код може да работи правилно с данни, потенциално несъвместими помежду си, тогава щастлив ден, той бърза. Ако не, трябва да обърнете специално внимание, за да се уверите, че вашите данни са напълно последователни, като използвате техники като квалифициране на летлива памет или заключващи конструкции и т.н. Всички те, по свой начин, струват производителност.
И така, това е основното съображение. Всички останали решения започват от тук. Отговорът на това може да ви каже как да разделяте приложения между машини, какви ресурси се споделят и как се споделят. Какви протоколи и техники са налични за преместване на данните и колко ще струва по отношение на обработката за извършване на прехвърлянето. Репликация, балансиране на натоварването, споделяне на данни и т.н. и т.н. Всичко се основава на тази концепция.
Редактиране в отговор на първия коментар.
Точно така. Играта тук, например, ако B не може да промени клиентските данни, тогава каква е вредата от променените клиентски данни? Можете ли да „рискувате“ да остане неактуален за кратко време? Може би вашите клиентски данни идват достатъчно бавно, за да можете да ги репликирате от А до Б веднага. Да кажем, че промяната е поставена на опашка, която поради малкия обем се прихваща лесно (<1s), но въпреки това ще бъде „извън транзакцията“ с оригиналната промяна и така има малък прозорец, където A ще има данни, които Б няма.
Сега умът наистина започва да се върти. Какво се случва по време на тази 1 секунда "лаг", какъв е най-лошият възможен сценарий. И можете ли да проектирате около него? Ако можете да проектирате около 1s закъснение, може да сте в състояние да проектирате около 5s, 1m или дори по-дълго закъснение. Каква част от клиентските данни всъщност използвате на B? Може би B е система, предназначена да улесни вземането на поръчки от инвентара. Трудно е да си представим, че е необходимо нещо повече от просто идентификатор на клиент и може би име. Просто нещо, което грубо да идентифицира за кого е поръчката, докато се сглобява.
Системата за избор не е задължително да отпечата цялата информация за клиента до самия край на процеса на избор и дотогава поръчката може да се е преместила в друга система, която може би е по-актуална, особено с информация за доставка, така че в крайна сметка системата за събиране почти не се нуждае от никакви данни за клиента. Всъщност можете да ВГРАДИТЕ и денормализирате информацията за клиента в рамките на поръчката за доставка, така че няма нужда или очакване за синхронизиране по-късно. Докато идентификационният номер на клиента е правилен (който така или иначе никога няма да се промени) и името (което се променя толкова рядко, че не си струва да се обсъжда), това е единствената истинска справка, от която се нуждаете, и всичките ви фишове за избор са напълно точни към момента на създаване.
Номерът е начинът на мислене, за разбиване на системите и фокусиране върху основните данни, които са необходими за задачата. Данните, от които не се нуждаете, не трябва да се репликират или синхронизират. Хората се възмущават от неща като денормализиране и намаляване на данните, особено когато са от света на моделирането на релационни данни. И с основателна причина трябва да се разглежда с повишено внимание. Но след като станете разпределени, вие имплицитно сте се денормализирали. По дяволите, сега го копирате на едро. Така че може и да сте по-умни за това.
Всичко това може да бъде смекчено чрез солидни процедури и задълбочено разбиране на работния процес. Идентифицирайте рисковете и разработете политика и процедури за справяне с тях.
Но трудната част е прекъсването на веригата до централната база данни в началото и инструктирането на хората, че не могат да „имат всичко“, както може би очакват, когато имате единичен, централен, перфектен склад за информация.
