Обстойно въведение в разпределените системи

Какво е разпределена система и защо е толкова сложна?

С непрекъснато нарастващото технологично разрастване на света разпределените системи стават все по-широко разпространени. Те са огромна и сложна област на обучение в областта на компютърните науки.

Тази статия има за цел да ви запознае с разпределени системи по основен начин, показвайки ви поглед върху различните категории такива системи, като същевременно не се впускате дълбоко в детайлите.

Какво е разпределена система?

Разпределената система в най-простата си дефиниция е група компютри, работещи заедно, за да изглеждат като един компютър за крайния потребител.

Тези машини имат споделено състояние, работят едновременно и могат да се провалят независимо, без това да повлияе на времето за работа на цялата система.

Предлагам постепенно да работим чрез пример за разпространение на система, така че да можете да разберете по-добре всичко:

Да тръгнем с база данни! Традиционните бази данни се съхраняват във файловата система на една машина, когато искате да извлечете / вмъкнете информация в нея - говорите директно с тази машина.

За да разпространяваме тази система от бази данни, ще трябва да използваме тази база данни на няколко машини едновременно. Потребителят трябва да може да говори с която и машина да избере и не трябва да може да каже, че не говори с една машина - ако той вмъква запис в възел # 1, възел # 3 трябва да може да върне този запис.

Защо да разпространяваме система?

Системите винаги се разпространяват по необходимост. Истината е - управлението на разпределени системи е сложна тема, пълна с клопки и наземни мини. Главоболие е разгръщането, поддържането и отстраняването на грешки в разпределените системи, така че защо изобщо да ходите там?

Това, което ви позволява разпределена система, е да мащабирате хоризонтално . Връщайки се към предишния ни пример за един сървър на база данни, единственият начин да се справим с повече трафик би бил да надградим хардуера, на който работи базата данни. Това се нарича мащабиране вертикално .

Мащабирането по вертикала е добре и добре, докато можете, но след определен момент ще видите, че дори най-добрият хардуер не е достатъчен за достатъчно трафик, да не говорим за непрактично за хостване.

Хоризонталното мащабиране просто означава добавяне на повече компютри, вместо да надграждате хардуера на един.

Това е значително по-евтино от вертикалното мащабиране след определен праг, но това не е основният случай за предпочитание.

Вертикалното мащабиране може само да увеличи производителността ви до най-новите възможности на хардуера. Тези възможности се оказват недостатъчни за технологични компании с умерено до голямо натоварване.

Най-хубавото при хоризонталното мащабиране е, че нямате ограничение за това колко можете да мащабирате - когато производителността се влоши, просто добавяте друга машина, до потенциално безкрайност.

Лесното мащабиране не е единствената полза, която получавате от разпределените системи. Толерантността към повреди и ниската латентност също са също толкова важни.

Толерантност към неизправности - клъстер от десет машини в два центъра за данни по своята същност е по-устойчив на грешки от една машина. Дори ако един център за данни се запали, приложението ви пак ще работи.

Ниска латентност - Времето за мрежов пакет да обиколи света е физически ограничено от скоростта на светлината. Например, възможно най-краткото време за двупосочно пътуване на дадена заявка(т.е. отиване и връщане назад) в оптичен кабел между Ню Йорк и Сидни е 160ms. Разпределените системи ви позволяват да имате възел в двата града, позволявайки на трафика да удари възела, който е най-близо до него.

За да работи разпределена система обаче, трябва софтуерът, работещ на тези машини, да бъде специално проектиран за работа на множество компютри едновременно и справяне с проблемите, които идват заедно с него. Това се оказва не лесен подвиг.

Мащабиране на нашата база данни

Представете си, че нашето уеб приложение стана безумно популярно. Представете си също така, че нашата база данни започна да получава двойно повече заявки в секунда, отколкото може да обработи. Вашето приложение веднага ще започне да намалява в производителността и това ще бъде забелязано от вашите потребители.

Нека да работим заедно и да направим нашата база от данни да отговори на нашите високи изисквания.

В типично уеб приложение обикновено четете информация много по-често, отколкото вмъквате нова информация или модифицирате стара.

Има начин за увеличаване на производителността на четене и това е чрез така наречената стратегия за репликация на първична реплика . Тук създавате два нови сървъра за бази данни, които се синхронизират с основния. Уловката е, че можете да четете само от тези нови екземпляри.

Винаги, когато вмъквате или променяте информация - говорите с основната база данни. Той от своя страна асинхронно информира репликите на промяната и те също го запазват.

Поздравления, вече можете да изпълните 3 пъти повече прочетени заявки! Не е ли страхотно?

Подводни камъни

Хванах те! Веднага загубихме C в ACID гаранциите на нашата релационна база данни , което означава последователност.

Виждате ли, сега съществува възможност, при която ние вмъкваме нов запис в базата данни, веднага след това издаваме заявка за четене за него и не получаваме нищо обратно, сякаш не съществува!

Разпространението на новата информация от основната към репликата не се случва моментално. Всъщност съществува времеви прозорец, в който можете да извлечете остаряла информация. Ако случаят не беше такъв, производителността ви на запис ще пострада, тъй като ще трябва да чака синхронно разпространението на данните.

Разпределените системи идват с няколко компромиса. Този конкретен проблем е този, с който ще трябва да се живее, ако искате да мащабирате адекватно.

Продължавайки да мащабирате

Използвайки подхода на базата данни с реплики, ние можем до известна степен да мащабираме нашия трафик на четене. Това е чудесно, но ударихме стена по отношение на нашия трафик за запис - все още всичко е в един сървър!

Тук не сме останали с много възможности. Просто трябва да разделим нашия трафик за запис на множество сървъри, тъй като човек не е в състояние да се справи с него.

Един от начините е да се възползвате от стратегия за многократно репликация. Там вместо реплики, от които можете да четете само, имате множество първични възли, които поддържат четене и запис. За съжаление, това се усложнява много бързо, тъй като вече имате възможност да създавате конфликти (например вмъкнете два записа с един и същ идентификатор).

Да тръгнем с друга техника, наречена рязкост(наричано още разделяне ).

С Sharding разделяте сървъра си на множество по-малки сървъри, наречени парчета. Всички тези парчета съдържат различни записи - вие създавате правило какъв вид записи влизат в кой парче. Много е важно правилото да се създаде така, че данните да се разпространяват по еднакъв начин .

Възможен подход към това е да се дефинират диапазони според известна информация за запис (напр. Потребители с име AD).

Този ключ за рязане трябва да бъде избран много внимателно, тъй като натоварването не винаги е равно на произволни колони. (напр. повече хора имат име, започващо с C, а не Z ). Един-единствен парче, което получава повече заявки от други, се нарича горещо място и трябва да се избягва. След като се разделят, презареждането на данните става невероятно скъпо и може да доведе до значителни престои, какъвто беше случаят с прословутия 11-часов престой на FourSquare.

За да улесним нашия пример, приемете, че нашият клиент (приложението Rails) знае коя база данни да използва за всеки запис. Също така си струва да се отбележи, че има много стратегии за изостряне и това е прост пример за илюстриране на концепцията.

В момента спечелихме доста - можем да увеличим трафика си на запис N пъти, където N е броят на парчетата. Това практически не ни дава почти никакви ограничения - представете си колко фино можем да получим с това разделяне.

Подводни камъни

Всичко в софтуерното инженерство е повече или по-малко компромис и това не е изключение. Sharding не е прост подвиг и е най-добре да се избягва, докато наистина не е необходимо.

Сега направихме запитвания по ключоверазлични от разделения ключ невероятно неефективни (те трябва да преминат през всички парчета). SQL JOINзаявките са още по-лоши и сложните стават практически неизползваеми.

Децентрализирано срещу разпределено

Преди да продължим по-нататък, бих искал да направя разлика между двата термина.

Въпреки че думите звучат подобно и може да се заключи, че логически означават едно и също, тяхната разлика има значително технологично и политическо въздействие.

Децентрализираната все още се разпространява в технически смисъл, но цялата децентрализирана система не е собственост на един участник. Никоя компания не може да притежава децентрализирана система, в противен случай тя вече няма да бъде децентрализирана.

Това означава, че повечето системи, които ще разгледаме днес, могат да се разглеждат като разпределени централизирани системи - и това е, което те са направени да бъдат.

Ако се замислите - по-трудно е да създадете децентрализирана система, защото тогава трябва да се справите със случая, когато някои от участниците са злонамерени. Това не е така при нормалните разпределени системи, тъй като знаете, че притежавате всички възли.

Забележка: Тази дефиниция е обсъждана много и може да бъде объркана с други (равнопоставени, обединени). В ранната литература това също е дефинирано по различен начин. Независимо от това, това, което ви дадох като определение, е това, което според мен е най-широко използваното сега, когато блокчейн и криптовалути популяризираха термина.

Категории на разпределена система

Сега ще преминем през няколко разпределени системни категории и ще изброим техните най-големи публично известни производствени приложения. Имайте предвид, че повечето показани числа са остарели и най-вероятно са значително по-големи към момента, в който четете това.

Разпределени хранилища за данни

Разпределените хранилища за данни са най-широко използвани и признати като разпределени бази данни. Повечето разпределени бази данни са нерелационни бази данни NoSQL, ограничени до семантиката ключ-стойност. Те осигуряват невероятна производителност и мащабируемост с цената на последователност или наличност.

Известен мащаб - Известно е, че Apple използва 75 000 възла на Apache Cassandra, съхраняващи над 10 петабайта данни през 2015 г.

Не можем да навлизаме в дискусии за разпределени хранилища на данни, без първо да въведем теоремата за ОСП.

Теорема за ОСП

Доказано още през 2002 г., теоремата за ОСП гласи, че разпределеното хранилище за данни не може едновременно да бъде последователно, налично и толерантно към разделяне.

Някои бързи определения:

  • Последователност - Това, което четете и пишете последователно, е това, което се очаква (не забравяйте, че има репликация на базата данни преди няколко абзаца?)
  • Наличност - цялата система не умира - всеки неизправен възел винаги връща отговор.
  • Толерантност към дяловете - Системата продължава да функционира и поддържа своите гаранции за последователност / наличност въпреки мрежовите дялове

В действителност толерансът на дяловете трябва да бъде даден за всяко разпределено хранилище на данни. Както беше споменато на много места, едно от които тази страхотна статия, не можете да имате последователност и наличност без толерантност на дяловете.

Помислете за това: ако имате два възела, които приемат информация и връзката им умира - как и двамата ще бъдат достъпни и едновременно ще ви осигурят последователност? Те нямат начин да знаят какво прави другият възел и като такива могат или да станат офлайн (недостъпни), или да работят със остаряла информация (несъвместима) .

В крайна сметка остава да изберете дали искате вашата система да бъде силно последователна или силно достъпна в мрежов дял .

Практиката показва, че повечето приложения оценяват повече наличността. Не винаги е необходима силна последователност. Дори тогава този компромис не е задължително направен, защото се нуждаете от 100% гаранция за наличност, а по-скоро защото латентността на мрежата може да бъде проблем, когато трябва да синхронизирате машините, за да постигнете силна последователност. Тези и повече фактори карат приложенията обикновено да избират решения, които предлагат висока наличност.

Такива бази данни се уреждат с най-слабия модел на последователност - евентуална последователност (обяснение за силна срещу евентуална последователност) . Този модел гарантира, че ако не се правят нови актуализации на даден елемент, в крайна сметка всички достъпи до този елемент ще върнат последната актуализирана стойност.

Тези системи предоставят BASE свойства (за разлика от ACID на традиционните бази данни)

  • B asically A vailable - Системата винаги връща отговор
  • S често състояние - Системата може да се промени с течение на времето, дори и по време на не вход (поради евентуалното последователност)
  • E ventual последователност - При липса на въвеждане, данните ще се разпространи до всеки възел рано или късно - по този начин се превръща в съответствие

Примери за такива налични разпределени бази данни - Cassandra, Riak, Voldemort

Разбира се, има и други хранилища с данни, които предпочитат по-силна последователност - HBase, Couchbase, Redis, Zookeeper

Теоремата за CAP е достойна за множество статии сама по себе си - някои относно това как можете да промените свойствата на CAP на системата в зависимост от това как се държи клиентът, а други как тя не се разбира правилно.

Касандра

Cassandra, както беше споменато по-горе, е разпределена база данни без SQL, която предпочита свойствата на AP извън CAP, като се урежда с евентуална последователност. Трябва да призная, че това може да е малко подвеждащо, тъй като Касандра е силно конфигурируема - можете да я направите също така да осигури силна последователност за сметка на наличността, но това не е често срещаният случай на употреба.

Касандра използва последователно хеширане, за да определи кои възли от вашия клъстер трябва да управляват данните, които предавате. Вие задавате фактор на репликация , който основно посочва колко възли искате да репликирате вашите данни.

Когато четете, ще четете само от тези възли.

Касандра е мащабируема, осигурявайки абсурдно висока производителност на запис.

Въпреки че тази диаграма може да е пристрастна и изглежда, че сравнява Касандра с бази данни, настроени да осигурят силна последователност (в противен случай не мога да разбера защо MongoDB ще намали производителността при надграждане от 4 на 8 възли), това все пак трябва да покаже какво правилно е зададено нагоре клъстерът Касандра е способен.

Независимо от това, в компромиса с разпределени системи, който позволява хоризонтално мащабиране и невероятно висока производителност, Cassandra не предоставя някои основни характеристики на базите данни на ACID - а именно транзакции.

Консенсус

Транзакциите с бази данни са трудни за внедряване в разпределени системи, тъй като изискват всеки възел да се съгласи относно правилното действие (прекъсване или ангажиране). Това е известно като консенсус и е основен проблем в разпределените системи.

Постигането на типа споразумение, необходимо за проблема с „ангажиране на транзакция“, е лесно, ако участващите процеси и мрежата са напълно надеждни. Реалните системи обаче са обект на редица възможни грешки, като сривове на процесите, разделяне на мрежата и загубени, изкривени или дублирани съобщения.

Това поражда проблем - доказано е невъзможно да се гарантира, че е постигнат правилен консенсус в рамките на ограничен период от време в ненадеждна мрежа.

На практика обаче има алгоритми, които доста бързо постигат консенсус за ненадеждна мрежа. Касандра всъщност осигурява леки транзакции чрез използването на алгоритъма на Paxos за разпределен консенсус.

Разпределени изчисления

Разпределените изчисления са ключът към притока на обработка на големи данни, който наблюдаваме през последните години. Това е техниката за разделяне на огромна задача (напр. Съвкупност от 100 милиарда записи), от която нито един компютър не може практически да изпълни сам по себе си, на много по-малки задачи, всяка от които може да се побере в една стокова машина. Разделяте огромната си задача на много по-малки, карате ги да се изпълняват паралелно на много машини, обобщавате данните по подходящ начин и сте решили първоначалния си проблем. Този подход отново ви позволява да мащабирате хоризонтално - когато имате по-голяма задача, просто включете повече възли в изчислението.

Известен мащаб - Folding @ Home имаше 160 000 активни машини през 2012 г.

Ранен новатор в това пространство беше Google, който поради необходимостта от голямото си количество данни трябваше да измисли нова парадигма за разпределено изчисление - MapReduce. Те публикуват доклад за него през 2004 г. и по-късно общността с отворен код създава Apache Hadoop въз основа на него.

MapReduce

MapReduce може просто да бъде дефиниран като две стъпки - картографиране на данните и тяхното намаляване до нещо значимо.

Нека се заемем с пример отново:

Да кажем, че сме средни и съхранихме огромната си информация във вторична разпределена база данни за целите на складирането. Искаме да извлечем данни, представляващи броя на издадени клапове всеки ден през април 2017 г. (преди година).

Този пример се поддържа възможно най-кратък, ясен и опростен, но представете си, че работим с много данни (например анализиране на милиарди пляскания). Няма да съхраняваме цялата тази информация на една машина очевидно и няма да анализираме всичко това само с една машина. Също така няма да отправяме заявки към производствената база данни, а по-скоро към някаква „складова“ база данни, създадена специално за офлайн задачи с нисък приоритет.

Всяка задача на Map е отделен възел, трансформиращ колкото може повече данни. Всяко задание обхожда всички данни в дадения възел за съхранение и ги съпоставя на обикновен набор от датата и номер едно. След това се правят три междинни стъпки (за които никой не говори) - разбъркване, сортиране и разделяне. По принцип допълнително подреждат данните и ги изтриват до съответното задание за намаляване. Тъй като имаме работа с големи данни, имаме отделни задачи за намаляване, за да работим само на една дата.

Това е добра парадигма и изненадващо ви позволява да правите много с нея - например можете да свържете множество задания на MapReduce.

По-добри техники

MapReduce е донякъде наследство в днешно време и носи някои проблеми с него. Тъй като работи на партиди (работни места), възниква проблем, при който ако работата ви се провали - трябва да рестартирате цялото нещо. Неуспехът на 2-часовата работа наистина може да забави целия ви конвейер за обработка на данни и това не искате най-малко, особено в пиковите часове.

Друг проблем е времето, в което чакате, докато получите резултати. В аналитичните системи в реално време (които всички разполагат с големи данни и по този начин използват разпределени изчисления) е важно последните ви смачкани данни да са възможно най-свежи и със сигурност не от преди няколко часа.

Като такива се появиха други архитектури, които се занимават с тези проблеми. А именно Lambda Architecture (комбинация от партидна обработка и поточна обработка) и Kappa Architecture (само поточна обработка). Тези постижения в областта донесоха нови инструменти, които ги позволяват - Kafka Streams, Apache Spark, Apache Storm, Apache Samza.

Разпределени файлови системи

Разпределените файлови системи могат да се разглеждат като разпределени хранилища за данни. Те са едно и също нещо като концепцията - съхраняване и достъп до голямо количество данни в клъстер машини, които всички се появяват като едно цяло. Те обикновено вървят ръка за ръка с разпределените изчисления.

Известен мащаб - Yahoo е известен с това, че използва HDFS на над 42 000 възела за съхранение на 600 петабайта данни, още през 201 г.

Уикипедия дефинира разликата в това, че разпределените файлови системи позволяват достъп до файлове, използвайки същите интерфейси и семантика като локалните файлове, а не чрез персонализиран API като Cassandra Query Language (CQL).

HDFS

Разпределената файлова система на Hadoop (HDFS) е разпределена файлова система, използвана за разпределени изчисления чрез рамката на Hadoop. С широко разпространено приемане, той се използва за съхраняване и репликация на големи файлове (с размер GB или TB) на много машини.

Архитектурата му се състои основно от NameNodes и DataNodes . NameNodes са отговорни за съхраняването на метаданни за клъстера, като кой възел съдържа кои файлови блокове. Те действат като координатори за мрежата, като измислят къде най-добре да се съхраняват и репликират файлове, проследявайки здравето на системата. DataNodes просто съхраняват файлове и изпълняват команди като репликиране на файл, писане на нов и други.

Не е изненадващо, че HDFS се използва най-добре с Hadoop за изчисления, тъй като осигурява информираност за данните за изчислителните задачи. След това посочените работни места се изпълняват на възлите, съхраняващи данните. Това използва локалността на данните - оптимизира изчисленията и намалява количеството трафик в мрежата.

IPFS

Междупланетна файлова система (IPFS) е вълнуващ нов peer-to-peer протокол / мрежа за разпределена файлова система. Използвайки технологията Blockchain, тя може да се похвали с напълно децентрализирана архитектура без нито един собственик, нито точка на повреда.

IPFS предлага система за именуване (подобна на DNS), наречена IPNS, и позволява на потребителите лесно да имат достъп до информация. Той съхранява файл чрез исторически версии, подобно на това, което прави Git. Това позволява достъп до всички предишни състояния на даден файл.

Той все още е в процес на тежко развитие (v0.4 към момента на писане), но вече е виждал проекти, заинтересовани да надграждат над него (FileCoin).

Разпределени съобщения

Системите за съобщения осигуряват централно място за съхранение и разпространение на съобщения / събития във вашата цялостна система. Те ви позволяват да отделите логиката на приложението си от директен разговор с другите ви системи.

Известен мащаб - клъстерът Kafka на LinkedIn обработва 1 трилион съобщения на ден с пикове от 4,5 милиона съобщения в секунда.

Просто казано, платформата за съобщения работи по следния начин:

Съобщение се излъчва от приложението, което потенциално го създава (наречено производител ), влиза в платформата и се чете от потенциално множество приложения, които се интересуват от него (наречени потребители ).

Ако трябва да запишете определено събитие на няколко места (напр. Създаване на потребител в база данни, склад, услуга за изпращане на имейли и каквото друго можете да измислите) платформата за съобщения е най-чистият начин за разпространение на това съобщение.

Потребителите могат да извадят информация от брокерите (модел на изтегляне) или да накарат брокерите да изтласкат информацията директно в потребителите (модел на натискане).

Има няколко популярни първокласни платформи за съобщения:

RabbitMQ - Брокер на съобщения, който ви позволява по-фин контрол на траекториите на съобщенията чрез правила за маршрутизиране и други лесно конфигурируеми настройки. Може да се нарече интелигентен брокер, тъй като има много логика в себе си и стриктно следи съобщенията, които минават през него. Осигурява настройки за AP и CP от CAP . Използва push модел за уведомяване на потребителите.

Kafka - Брокер на съобщения (и изцяло платформа), който е малко по-ниско ниво, тъй като в него не се проследяват кои съобщения са прочетени и не позволява сложна логическа маршрутизация. Това му помага да постигне невероятно представяне. Според мен това е най-голямата перспектива в това пространство с активно развитие от общността с отворен код и подкрепа от екипа Confluent. Може би Kafka е най-широко използвана от най-технологичните компании. Написах задълбочено въведение за това, където навлизам в подробности за цялата му доброта.

Apache ActiveMQ - Най-старият от групата, датиращ от 2004 г. Използва JMS API, което означава, че е насочен към Java EE приложения. Той е пренаписан като ActiveMQ Artemis, който осигурява изключителна производителност наравно с Kafka.

Amazon SQS - Услуга за съобщения, предоставена от AWS. Позволява ви бързо да го интегрирате със съществуващите приложения и елиминира необходимостта да се справяте със собствената си инфраструктура, което може да е голяма полза, тъй като системи като Kafka са известни трудности при настройването. Amazon предлага и две подобни услуги - SNS и MQ, като последната е основно ActiveMQ, но управлявана от Amazon.

Разпределени приложения

Ако навиете 5 Rails сървъра зад един балансиращ товар, всички свързани към една база данни, бихте ли могли да го наречете разпределено приложение? Спомнете си дефиницията ми отгоре:

Разпределената система е група от компютри, работещи заедно, за да се покажат като един компютър за крайния потребител. Тези машини имат споделено състояние, работят едновременно и могат да се провалят независимо, без това да повлияе на времето за работа на цялата система.

Ако смятате базата данни като споделено състояние, бихте могли да твърдите, че това може да бъде класифицирано като разпределена система - но ще сгрешите, тъй като сте пропуснали частта „да работим заедно “ в дефиницията.

Система се разпространява само ако възлите комуникират помежду си, за да координират своите действия.

Следователно нещо като приложение, изпълняващо своя back-end код в peer-to-peer мрежа, може по-добре да бъде класифицирано като разпределено приложение. Независимо от това, всичко това е излишна класификация, която няма никаква цел, но илюстрира колко сме суетливи в групирането на нещата.

Известен мащаб - БитТорент рой от 193 000 възела за епизод от Игра на тронове, април 2014 г.

Виртуална машина Erlang

Erlang е функционален език, който има страхотна семантика за едновременност, разпространение и толерантност към грешки. Виртуалната машина Erlang сама се справя с разпространението на приложение Erlang.

Моделът му работи, като има много изолирани леки процеси, всички с възможността да говорят помежду си чрез вградена система за предаване на съобщения. Това се нарича Модел на актьораи OLA библиотеките на Erlang могат да се разглеждат като разпределена рамка на актьора (по подобие на Akka за JVM).

Моделът е това, което му помага да постигне голяма паралелност по-просто - процесите са разпределени в наличните ядра на системата, която ги изпълнява. Тъй като това не се различава от мрежова настройка (освен възможността за пускане на съобщения), виртуалната машина на Erlang може да се свърже с други виртуални машини на Erlang, работещи в същия център за данни или дори на друг континент. Този рой от виртуални машини изпълнява едно единствено приложение и се справя с отказите на машината чрез поглъщане (друг възел се планира да стартира).

Всъщност разпределеният слой на езика беше добавен, за да осигури толерантност към грешки. Софтуерът, работещ на една машина, винаги е изложен на опасност тази машина да умре и да изведе приложението ви офлайн. Софтуерът, работещ на много възли, позволява по-лесно обработване на хардуерни откази, при условие че приложението е създадено с оглед на това.

BitTorrent

BitTorrent е един от най-широко използваните протоколи за прехвърляне на големи файлове в мрежата чрез торенти. Основната идея е да се улесни прехвърлянето на файлове между различни връстници в мрежата, без да се налага да преминавате през основен сървър.

Използвайки BitTorrent клиент, вие се свързвате с множество компютри по целия свят, за да изтеглите файл. Когато отворите .torrent файл, вие се свързвате с така наречения тракер , който е машина, действаща като координатор. Помага за откриване на връстници, показвайки ви възлите в мрежата, които имат желания файл.

Имате представите за два типа потребители, пиявица и сеялка . Leecher е потребителят, който изтегля файл, и сеялка е потребителят, който качва споменатия файл.

Смешното при равностойните мрежи е, че вие ​​като обикновен потребител имате способността да се присъединявате и да допринасяте за мрежата.

BitTorrent и неговите предшественици (Gnutella, Napster) ви позволяват доброволно да хоствате файлове и да ги качвате на други потребители, които ги искат. Причината, поради която BitTorrent е толкова популярен, е, че е първият по рода си, който предоставя стимули за принос в мрежата. Freeriding , където потребителят ще изтегля само файлове, беше проблем с предишните протоколи за споделяне на файлове.

BitTorrent решава фрирайд до известна степен, като кара сеялките да качват повече на тези, които осигуряват най-добрите скорости на изтегляне. Той работи, като ви стимулира да качвате, докато изтегляте файл. За съжаление, след като приключите, нищо не ви кара да останете активни в мрежата. Това причинява липса на сеялки в мрежата, които имат пълния файл и тъй като протоколът разчита много на такива потребители, решения като частни тракери влязоха в действие. Частните тракери изискват да сте член на общност (често само с покана), за да участвате в разпределената мрежа.

След подобрения в областта бяха измислени безследни торенти. Това беше надстройка на протокола BitTorrent, който не разчита на централизирани тракери за събиране на метаданни и намиране на връстници, а вместо това използва нови алгоритми. Един такъв случай е Kademlia (Mainline DHT), разпределена хеш таблица (DHT), която ви позволява да намерите връстници чрез други връстници. Всъщност всеки потребител изпълнява задълженията на тракера.

Разпределени книги

Разпределената книга може да се разглежда като неизменяема база данни само за добавяне, която се репликира, синхронизира и споделя във всички възли в разпределената мрежа.

Известен мащаб - Ethereum Network имаше пик от 1,3 милиона транзакции на ден на 4 януари 2018 г.

Те използват модела на източника на събития, който ви позволява да възстановите състоянието на счетоводната книга по всяко време от нейната история.

Блокчейн

Blockchain е текущата основна технология, използвана за разпределени счетоводни книги и всъщност бележи началото им. Тази последна и най-голямата иновация в разпределеното пространство позволи създаването на първия по рода си наистина разпределен протокол за плащане - биткойн.

Blockchain е разпределена книга, съдържаща подреден списък на всички транзакции, които някога са се случвали в нейната мрежа. Транзакциите се групират и съхраняват в блокове. Цялата блокчейн по същество е свързан списък от блокове (оттук и името) . Споменатите блокове са изчислително скъпи за създаване и са тясно свързани помежду си чрез криптография.

Просто казано, всеки блок съдържа специален хеш (който започва с X нули) от съдържанието на текущия блок (под формата на дърво на Merkle) плюс хеш на предишния блок. Този хеш изисква да се произведе много мощност на процесора, защото единственият начин да се излезе с него е чрез груба сила.

Майньорите са възлите, които се опитват да изчислят хеша (чрез bruteforce). Всички миньори се състезават помежду си за това кой може да измисли произволен низ (наречен nonce ), който, когато се комбинира със съдържанието, създава гореспоменатия хеш. След като някой намери правилния nonce - той го излъчва на цялата мрежа. След това споменатият низ се проверява самостоятелно от всеки възел и се приема в тяхната верига.

Това се превръща в система, при която е абсурдно скъпо да се модифицира блокчейн и абсурдно лесно да се провери дали той не е фалшифициран.

Смяната на съдържанието на даден блок е скъпа, защото това би довело до различен хеш. Не забравяйте, че хешът на всеки следващ блок зависи от него. Ако трябваше да промените транзакция в първия блок на снимката по-горе - щяхте да промените корен Merkle. Това от своя страна би променило хеша на блока (най-вероятно без необходимите водещи нули) - това би променило хеша на блок # 2 и така нататък и т.н. Това означава, че ще трябва да форсирате нов nonce за всеки блок след този, който току-що променихте.

Мрежата винаги се доверява и възпроизвежда най-дългата валидна верига. За да измамите системата и в крайна сметка да създадете по-дълга верига, ще ви трябват повече от 50% от общата мощност на процесора, използвана от всички възли.

Блокчейнът може да се разглежда като разпределен механизъм за възникващ консенсус . Консенсусът не се постига изрично - няма избори или фиксиран момент, в който да настъпи консенсус. Вместо това консенсусът е възникващ продукт на асинхронното взаимодействие на хиляди независими възли, всички следващи правила на протокола.

Тази безпрецедентна иновация наскоро се превърна в бум в технологичното пространство, като хората прогнозират, че ще отбележи създаването на Web 3.0. Това определено е най-вълнуващото пространство в света на софтуерното инженерство в момента, изпълнено с изключително предизвикателни и интересни проблеми, чакащи да бъдат решени.

Биткойн

Това, което липсваше на предишните разпределени протоколи за плащане, беше начин за практически предотвратяване на проблема с двойните разходи в реално време, по разпределен начин. Изследванията са дали интересни предложения [1], но Биткойн е първият, който прилага практическо решение с ясни предимства пред другите.

Проблемът с двойното харчене гласи, че актьор (например Боб) не може да похарчи единствения си ресурс на две места. Ако Боб има $ 1, той не би трябвало да може да го даде както на Алис, така и на Зак - това е само един актив, той не може да бъде дублиран. Оказва се, че е наистина трудно наистина да се постигне тази гаранция в разпределена система. Има някои интересни подходи за смекчаване, предшестващи блокчейн, но те не решават напълно проблема по практически начин.

Двойното харчене се решава лесно от Bitcoin, тъй като само един блок се добавя към веригата наведнъж. Двойното харчене е невъзможно в рамките на един блок, следователно дори ако два блока са създадени едновременно - само един ще стане на евентуалната най-дълга верига.

Биткойн разчита на трудността при натрупване на мощност на процесора.

Докато в системата за гласуване нападателят трябва само да добавя възли към мрежата (което е лесно, тъй като безплатният достъп до мрежата е цел на проектиране), в схема, базирана на процесора, нападателят е изправен пред физическо ограничение: получаване на достъп до все повече и повече мощен хардуер.

Това е и причината зловредните групи възли да трябва да контролират над 50% от изчислителната мощност на мрежата, за да пренесат всъщност всяка успешна атака. По-малко от това, а останалата част от мрежата ще създаде по-дълъг блокчейн по-бързо.

Ethereum

Ethereum може да се разглежда като програмируема блокчейн базирана софтуерна платформа. Той има своя собствена криптовалута (Ether), която подхранва внедряването на интелигентни договори в своята блокчейн.

Интелигентните договори са парче код, съхранявано като единична транзакция в блокчейна Ethereum. За да стартирате кода, трябва само да издадете транзакция с интелигентен договор като негова дестинация. Това от своя страна кара възлите на миньорите да изпълняват кода и каквито и промени да възникнат. Кодът се изпълнява във виртуалната машина Ethereum.

Здравина , роден език за програмиране Ethereum, се намира това, което се използва, за да пиша умни договори. Това е цялостен език за програмиране, който директно взаимодейства с блокчейна Ethereum, което ви позволява да запитвате състояние като салда или други резултати от интелигентни договори. За да предотвратите безкрайни цикли, стартирането на кода изисква известно количество Ether.

Тъй като блокчейнът може да се тълкува като поредица от промени в състоянието , много разпределени приложения (DApps) са изградени върху Ethereum и подобни платформи.

По-нататъшни употреби на разпределени дневници

Доказателство за съществуване - Услуга за анонимно и сигурно съхраняване на доказателство, че в даден момент е съществувал определен цифров документ. Полезно за осигуряване на целостта на документа, собствеността и маркирането на времето.

Децентрализирани автономни организации (DAO) - организации, които използват блокчейн като средство за постигане на консенсус по предложенията за подобряване на организацията. Примери за това са системата за управление на Dash, проектът SmartCash

Децентрализирано удостоверяване - Съхранявайте самоличността си в блокчейна, което ви позволява да използвате единичен вход (SSO) навсякъде. Соврин, граждански

И много, много повече. Технологията на разпределената книга наистина отвори безкрайни възможности. Някои най-вероятно са измислени, докато говорим!

Обобщение

В краткия обхват на тази статия успяхме да определим какво е разпределена система, защо да използвате такава и да преминете малко над всяка категория. Някои важни неща, които трябва да запомните са:

  • Разпределените системи са сложни
  • Те се избират по необходимост от мащаб и цена
  • С тях се работи по-трудно
  • Теорема за ОСП - компромис за последователност / наличност
  • Те имат 6 категории - хранилища за данни, изчисления, файлови системи, системи за съобщения, дневници, приложения

За да бъдем откровени, едва сме докоснали повърхността на разпределените системи. Нямах шанса да се справя задълбочено и да обяснявам основните проблеми като консенсус, стратегии за репликация, подреждане на събития и време, толерантност към откази, излъчване на съобщение в мрежата и други.

Внимание

Позволете ми да ви оставя с предупреждение за раздяла:

Трябва да се отклонявате от разпределените системи, доколкото можете. Сложността, която те натрупват със себе си, не си струва усилието, ако можете да избегнете проблема, като го решите по различен начин или някакво друго нестандартно решение.

[1]

Борба с двойно харчене с помощта на кооперативни P2P системи, 25–27 юни 2007 г. - предложено решение, при което всяка „монета“ може да изтече и да й бъде назначен свидетел (валидатор) за нейното изразходване.

Bitgold , декември 2005 г. - Преглед на високо ниво на протокол, изключително подобен на този на Bitcoin. Казва се, че това е предшественикът на биткойн.

Допълнително четене на разпределени системи:

Проектиране на приложения, интензивни за данни, Мартин Клепман - Страхотна книга, която разглежда всичко в разпределените системи и не само.

Cloud Computing Specialization, University of Illinois, Coursera - Дълга поредица от курсове (6), обхващащи разпределени системни концепции, приложения

Jepsen - Блог, обясняващ много разпределени технологии (ElasticSearch, Redis, MongoDB и др.)

Благодаря, че отделихте време да прочетете тази дълга (~ 5600 думи) статия!

Ако по някакъв случай сте намерили тази информативна информация или сте сметнали, че ви предоставя стойност, моля, уверете се, че сте я отправили толкова, колкото смятате, че заслужава, и помислете за споделяне с приятел, който би могъл да използва въведение в тази прекрасна област на изследване.

~ Станислав Козловски

Актуализиране

В момента работя в Confluent. Confluent е компания за големи данни, основана от самите създатели на Apache Kafka! Изключително съм благодарен за възможността, която ми предоставиха - в момента работя върху самата Кафка, която е отвъд страхотната! Ние от Confluent помагаме да се оформи цялата екосистема на Kafka с отворен код, включително ново управлявано облачно предложение Kafka като услуга.

Наемаме за много позиции (особено SRE / софтуерни инженери) в Европа и САЩ! Ако се интересувате от работата по самата Kafka, търсите нови възможности или просто сте любопитни - не забравяйте да ми изпратите съобщение в Twitter и аз ще споделя всички страхотни предимства, произтичащи от работата в компания в района на залива.