Tрунтовний вступ до розподілених систем

Що таке розподілена система і чому вона настільки складна?

У міру постійно зростаючого технологічного розширення світу розподілені системи набувають дедалі більшого поширення. Вони є величезною та складною областю вивчення інформатики.

Ця стаття має на меті ознайомити вас із розподіленими системами в основному, продемонструвавши вам уявлення про різні категорії таких систем, не заглиблюючись у подробиці.

Що таке розподілена система?

Розподілена система в найпростішому визначенні - це група комп’ютерів, що працюють разом, щоб виглядати кінцевим користувачем як єдиний комп’ютер.

Ці машини мають спільний стан, працюють одночасно і можуть самостійно виходити з ладу, не впливаючи на час роботи всієї системи.

Я пропоную нам поетапно опрацювати приклад розповсюдження системи, щоб ви могли краще зрозуміти все це:

Давайте підемо з базою даних! Традиційні бази даних зберігаються у файловій системі однієї машини, коли ви хочете отримати / вставити в неї інформацію - ви безпосередньо розмовляєте з цією машиною.

Щоб ми розповсюджували цю систему баз даних, нам потрібно, щоб ця база даних працювала на кількох машинах одночасно. Користувач повинен мати можливість спілкуватися з будь-якою машиною, яку він вибере, і не повинен мати змоги сказати, що він не розмовляє з однією машиною - якщо він вставляє запис у вузол # 1, вузол # 3 повинен мати можливість повернути цей запис.

Навіщо поширювати систему?

Системи завжди розподіляються за необхідністю. Справа в тому, що управління розподіленими системами - це складна тема, заповнена підводними камінами та наземними міну. Головний біль розгортати, підтримувати та налагоджувати розподілені системи, то навіщо взагалі туди йти?

Що дозволяє розподілена система, це масштабування по горизонталі . Повертаючись до нашого попереднього прикладу єдиного сервера баз даних, єдиним способом обробки більшої кількості трафіку буде оновлення обладнання, на якому працює база даних. Це називається масштабуванням по вертикалі .

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

Горизонтальне масштабування просто означає додавання більше комп’ютерів, а не модернізацію апаратного забезпечення одного.

Це значно дешевше, ніж вертикальне масштабування після певного порогу, але це не головний випадок переваг.

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

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

Простота масштабування - не єдина перевага, яку ви отримуєте від розподілених систем. Відмовостійкість і низька затримка також не менш важливі.

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

Низька затримка - час, протягом якого мережевий пакет подорожує світом, фізично обмежений швидкістю світла. Наприклад, найкоротший час для зворотного поїздки запиту(тобто пересування вперед і назад) у волоконно-оптичному кабелі між Нью-Йорком і Сіднеєм становить 160 мс. Розподілені системи дозволяють мати вузол в обох містах, дозволяючи трафіку потрапляти на найближчий до нього вузол.

Однак для того, щоб розподілена система працювала, вам потрібно, щоб програмне забезпечення, що працює на цих машинах, було спеціально розроблено для роботи на декількох комп’ютерах одночасно та вирішення проблем, які з цим пов’язані. Це виявляється нелегким подвигом.

Масштабування нашої бази даних

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

Давайте працювати разом і створити масштаб нашої бази даних, щоб задовольнити наші високі вимоги.

У типовому веб-додатку ви зазвичай читаєте інформацію набагато частіше, ніж вставляєте нову інформацію або модифікуєте стару.

Існує спосіб підвищення продуктивності читання, і це за допомогою так званої стратегії реплікації первинної репліки . Тут ви створюєте два нових сервери баз даних, які синхронізуються з основним. Підвох полягає в тому, що читати можна лише з цих нових примірників.

Кожного разу, коли ви вставляєте або змінюєте інформацію, ви спілкуєтесь із основною базою даних. Це, в свою чергу, асинхронно інформує про копії змін, і вони також зберігають його.

Вітаємо, тепер ти можеш виконати в 3 рази більше прочитаних запитів! Хіба це не чудово?

Підводний камінь

Зрозуміло! Ми відразу втратили C в гарантіях ACID нашої реляційної бази даних , що означає узгодженість.

Розумієте, зараз існує можливість, коли ми вставляємо новий запис до бази даних, відразу ж видаємо для нього запит на читання і нічого не отримуємо назад, ніби його не було!

Поширення нової інформації від основної до репліки відбувається не миттєво. Насправді існує часове вікно, в якому ви можете отримати застарілу інформацію. Якби це було не так, ваша продуктивність запису постраждала б, оскільки їй довелося б синхронно чекати розповсюдження даних.

Розподілені системи мають кілька компромісів. Це особливе питання, з яким вам доведеться жити, якщо ви хочете адекватно масштабуватись.

Продовжуючи масштабування

Використовуючи підхід до бази даних реплік, ми можемо певною мірою масштабувати наш трафік читання. Це чудово, але ми вдарилися об стіну щодо нашого трафіку запису - це все одно на одному сервері!

Тут у нас не залишається багато варіантів. Нам просто потрібно розділити наш трафік запису на кілька серверів, оскільки один не може його обробити.

Один із способів полягає у використанні стратегії реплікації з кількома первинами. Там замість копій, з яких ви можете лише читати, у вас є кілька основних вузлів, які підтримують читання та запис. На жаль, це дуже швидко ускладнюється, оскільки тепер у вас є можливість створювати конфлікти (наприклад, вставити два записи з однаковим ідентифікатором).

Давайте підемо з іншою технікою, яка називається шардінг(також зване розділенням ).

За допомогою шардінгу ви розділяєте свій сервер на кілька менших серверів, які називаються осколками. Всі ці осколки містять різні записи - ви створюєте правило щодо того, які записи входять в який осколок. Дуже важливо створити таке правило, щоб дані поширювались рівномірно .

Можливим підходом до цього є визначення діапазонів відповідно до деякої інформації про запис (наприклад, користувачів з іменем AD).

Цей ключ заточування слід вибирати дуже обережно, оскільки навантаження не завжди рівне на основі довільних стовпців. (наприклад, у більшості людей ім’я починається з C, а не Z ). Окремий фрагмент, який отримує більше запитів, ніж інші, називається гарячою точкою, і його слід уникати. Після розподілу дані повторного шардування даних стають неймовірно дорогими і можуть спричинити значні простої, як це було з сумнозвісним 11-годинним простоєм FourSquare.

Щоб наш приклад був простим, припустимо, що наш клієнт (додаток Rails) знає, яку базу даних використовувати для кожного запису. Варто також зазначити, що існує безліч стратегій шардінгу, і це простий приклад для ілюстрації концепції.

Зараз ми виграли досить багато - ми можемо збільшити трафік запису в N разів, де N - кількість осколків. Це практично не дає нам майже ніяких обмежень - уявіть, наскільки дрібнозернистими ми можемо отримати за допомогою цього розділення.

Підводний камінь

Все в програмній інженерії є більш-менш компромісним, і це не є винятком. Шардінг - не простий подвиг, і його краще уникати, поки це дійсно не потрібно.

Зараз ми зробили запити за ключамикрім розділеного ключа неймовірно неефективний (їм потрібно пройти всі осколки). JOINЗапити SQL ще гірші, і складні стають практично непридатними.

Децентралізоване проти розподіленого

Перш ніж йти далі, я хотів би розрізнити два терміни.

Незважаючи на те, що слова звучать схоже і можна зробити висновок, що логічно означають одне і те ж, їх відмінність робить значний технологічний та політичний вплив.

Децентралізована система все ще розподіляється в технічному сенсі, але цілі децентралізовані системи не належать одному акторові. Жодна компанія не може володіти децентралізованою системою, інакше вона більше не була б децентралізованою.

Це означає, що більшість систем, які ми розглянемо сьогодні, можна вважати розподіленими централізованими системами - і саме такими вони створені.

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

Примітка: Це визначення багато обговорювалось, і його можна сплутати з іншими (однорангові, федеративні). У ранній літературі це також визначалося по-різному. Незалежно від того, що я дав вам як визначення, це те, що, на мою думку, найбільш широко використовується зараз, коли блокчейн і криптовалюти популяризували цей термін.

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

Зараз ми пройдемо декілька розподілених системних категорій та перелічимо їх найбільше загальновідоме виробниче використання. Майте на увазі, що більшість таких зображень застаріли і, ймовірно, значно більші на той час, коли ви читаєте це.

Розподілені сховища даних

Розподілені сховища даних найбільш широко використовуються і визнаються розподіленими базами даних. Більшість розподілених баз даних - це нереляційні бази даних NoSQL, обмежені семантикою ключ-значення. Вони забезпечують неймовірну продуктивність та масштабованість за рахунок стабільності або доступності.

Відомий масштаб - відомо, що Apple використовує 75 000 вузлів Apache Cassandra, що зберігають понад 10 петабайт даних, ще в 2015 році

Ми не можемо вступати в обговорення розподілених сховищ даних без попереднього введення теореми CAP.

Теорема CAP

Доведено ще в 2002 році, теорема CAP стверджує, що розподілене сховище даних не може одночасно бути послідовним, доступним і толерантним до розділів.

Кілька швидких визначень:

  • Послідовність - Що ви читаєте та пишете послідовно, це те, що очікується (пам’ятаєте, що є реплікація бази даних кілька параграфів тому?)
  • Доступність - вся система не вмирає - кожен невідмовний вузол завжди повертає відповідь.
  • Толерантність до розділів - система продовжує функціонувати та підтримує свої гарантії послідовності / доступності, незважаючи на мережеві розділи

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

Подумайте: якщо у вас є два вузли, які приймають інформацію, і їх з'єднання вмирає - як вони обидва будуть доступними і одночасно забезпечать вам узгодженість? Вони не можуть знати, що робить інший вузол, і як такі можуть або перейти в автономний режим (недоступний), або працювати з застарілою інформацією (суперечлива) .

Врешті-решт вам залишається вибрати, чи хочете ви, щоб ваша система була стабільно послідовною або доступною в мережевому розділі .

Практика показує, що більшість програм більше цінують доступність. Не обов’язково завжди потрібна сильна послідовність. Навіть тоді такий компроміс не обов’язково робиться тому, що вам потрібна 100% гарантія доступності, а швидше тому, що затримка мережі може бути проблемою при синхронізації машин для досягнення високої узгодженості. Ці та інші фактори змушують програми зазвичай вибирати рішення, які пропонують високу доступність.

Такі бази даних узгоджуються з найслабшою моделлю узгодженості - можливістю узгодженості (суттєве та можливе пояснення узгодженості) . Ця модель гарантує, що якщо жодного нового оновлення для даного елемента не буде зроблено, врешті-решт всі звернення до цього елемента повернуть останнє оновлене значення.

Ці системи надають BASE властивості (на відміну від традиційних баз даних ACID)

  • B asically моделі шириною - система завжди повертає відповідь
  • S часто стан - Система може змінюватися з плином часу, навіть під час без входу (з - за можливу послідовність)
  • Е ventual консистенції - При відсутності вхідних даних, то дані будуть поширюватися на кожен вузол , рано чи пізно - таким чином , стає послідовним

Приклади таких доступних розподілених баз даних - Кассандра, Ріак, Волдеморт

Звичайно, є й інші сховища даних, які віддають перевагу більш чіткій послідовності - HBase, Couchbase, Redis, Zookeeper

Теорема CAP гідна кількох статей самостійно - деякі стосуються того, як ви можете налаштувати властивості CAP системи залежно від поведінки клієнта, а інші - того, як це неправильно розуміється.

Кассандра

Кассандра, як згадувалося вище, є розподіленою базою даних No-SQL, яка віддає перевагу властивостям AP поза CAP, врегулюючи їх з остаточною послідовністю. Я повинен визнати, що це може дещо ввести в оману, оскільки Кассандра дуже налаштовується - ви можете зробити так, щоб вона забезпечувала сильну узгодженість за рахунок доступності, але це не є загальним випадком її використання.

Кассандра використовує послідовне хешування, щоб визначити, які вузли з вашого кластера повинні управляти даними, які ви передаєте. Ви встановлюєте коефіцієнт реплікації , який в основному визначає, скільки вузлів ви хочете реплікувати ваші дані.

Під час читання ви будете читати лише з цих вузлів.

Кассандра є масштабованою, забезпечуючи абсурдно високу пропускну здатність.

Незважаючи на те, що ця діаграма може бути упередженою і, схоже, вона порівнює Кассандру з базами даних, встановленими для забезпечення високої узгодженості (інакше я не можу зрозуміти, чому MongoDB знизила б продуктивність при модернізації з 4 до 8 вузлів), це все одно повинно показати, що правильно встановити вгору скупчення Кассандри здатне.

Незважаючи на це, у компромісі розподілених систем, який забезпечує горизонтальне масштабування та неймовірно високу пропускну здатність, Кассандра не надає деяких фундаментальних особливостей баз даних ACID - а саме транзакцій.

Консенсус

Транзакції баз даних складно реалізувати в розподілених системах, оскільки вони вимагають від кожного вузла узгодити правильну дію (перервати або зафіксувати). Це відоме як консенсус, і це є основною проблемою розподілених систем.

Досягнення типу угоди, необхідної для проблеми „здійснення транзакції”, є простим, якщо процеси, що беруть участь, і мережа є повністю надійними. Однак реальні системи піддаються цілому ряду можливих несправностей, таких як збої процесу, розділення мережі та втрачені, спотворені або продубльовані повідомлення.

Це створює проблему - доведено, що неможливо гарантувати, що правильний консенсус буде досягнутий протягом обмеженого періоду часу в ненадійній мережі.

На практиці, однак, існують алгоритми, які досить швидко досягають консенсусу щодо ненадійної мережі. Кассандра насправді забезпечує легкі транзакції за допомогою алгоритму Паксоса для розподіленого консенсусу.

Розподілені обчислення

Розподілені обчислення - це ключ до припливу обробки великих даних, який ми спостерігали протягом останніх років. Це техніка розподілу величезної задачі (наприклад, сукупності 100 мільярдів записів), яку жоден комп’ютер не може практично виконати самостійно, на безліч дрібніших завдань, кожна з яких може вміститися в одну товарну машину. Ви розподіляєте своє величезне завдання на багато менших, доручаєте їх виконувати паралельно на багатьох машинах, належним чином агрегуєте дані, і ви вирішили свою початкову проблему. Цей підхід знову дозволяє масштабувати горизонтально - коли у вас є більша задача, просто включіть більше вузлів у розрахунок.

Відомий масштаб - Folding @ Home мав 160 тис. Активних машин у 2012 році

Раннім новатором у цьому просторі стала Google, якій за необхідності їх великих обсягів даних довелося винайти нову парадигму розподілених обчислень - MapReduce. Вони опублікували статтю про неї в 2004 році, а спільнота з відкритим кодом згодом створила Apache Hadoop на її основі.

MapReduce

MapReduce можна просто визначити як два етапи - відображення даних і зведення їх до чогось значущого.

Знову розглянемо приклад:

Скажімо, ми середні, і ми зберігали свою величезну інформацію у вторинній розподіленій базі даних для цілей складування. Ми хочемо отримати дані, що представляють кількість хлопців, що видаються щодня протягом квітня 2017 року (рік тому).

Цей приклад викладається якомога коротше, чіткіше та простіше, але уявіть, що ми працюємо з великою кількістю даних (наприклад, аналізуємо мільярди хлопців). Ми не будемо зберігати всю цю інформацію на одній машині, очевидно, і не будемо аналізувати все це лише на одній машині. Ми також не будемо запитувати виробничу базу даних, а скоріше якусь “складську” базу даних, створену спеціально для низькопріоритетних офлайн-завдань.

Кожне завдання Карти - це окремий вузол, що перетворює якомога більше даних. Кожне завдання перетинає всі дані у даному вузлі зберігання та відображає їх у простий кортеж дати та числа номер один. Потім виконуються три посередницькі кроки (про які ніхто не говорить) - перестановка, сортування та розділення. Вони в основному надалі упорядковують дані та видаляють їх до відповідного завдання зменшення. Оскільки ми маємо справу з великими даними, у нас кожна робота «Зменшити» розділена для роботи лише на одну дату.

Це хороша парадигма, яка напрочуд дозволяє вам багато з нею робити, наприклад, ви можете створити ланцюжок декількох завдань MapReduce.

Кращі техніки

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

Інше питання - час, коли ви чекаєте, поки не отримаєте результати. В аналітичних системах в режимі реального часу (які всі мають великі дані і, отже, використовують розподілені обчислення), важливо, щоб ваші останні хрусткі дані були якомога свіжішими і, звичайно, не такими, як кілька годин тому.

Як такі, з’явились інші архітектури, які вирішують ці проблеми. А саме Lambda Architecture (суміш пакетної обробки та потокової обробки) та Kappa Architecture (лише потокова обробка). Ці досягнення в галузі принесли нові інструменти, що дозволяють їм - Kafka Streams, Apache Spark, Apache Storm, Apache Samza.

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

Розподілені файлові системи можна сприймати як розподілені сховища даних. Це те саме, що і концепція - зберігання та доступ до великого обсягу даних у кластері машин, які всі виглядають як одне ціле. Зазвичай вони поєднуються з розподіленими обчисленнями.

Відомий масштаб - Yahoo відомий тим, що запускає HDFS на понад 42000 вузлах для зберігання 600 петабайт даних, ще в 201

Вікіпедія визначає різницю в тому, що розподілені файлові системи дозволяють отримувати доступ до файлів із використанням тих самих інтерфейсів та семантики, що й локальні файли, а не через спеціальний API, такий як Cassandra Query Language (CQL).

HDFS

Розподілена файлова система Hadoop (HDFS) - це розподілена файлова система, що використовується для розподілених обчислень через фреймворк Hadoop. Маючи широке поширення, він використовується для зберігання та тиражування великих файлів (розміром ГБ або ТБ) на багатьох машинах.

Його архітектура складається в основному з NameNodes та DataNodes . NameNodes відповідають за збереження метаданих про кластер, наприклад, який вузол містить які файлові блоки. Вони виступають координаторами мережі, з’ясовуючи, де найкраще зберігати та тиражувати файли, відстежуючи стан системи. DataNodes просто зберігають файли та виконують такі команди, як реплікація файлу, написання нового та інші.

Не дивно, що HDFS найкраще використовувати з Hadoop для обчислень, оскільки він забезпечує поінформованість про дані обчислювальних завдань. Потім зазначені завдання запускаються на вузлах, що зберігають дані. Це використовує локалізацію даних - оптимізує обчислення та зменшує обсяг трафіку по мережі.

IPFS

Міжпланетна файлова система (IPFS) - це новий захоплюючий одноранговий протокол / мережа для розподіленої файлової системи. Використовуючи технологію 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 за єдиним балансиром навантаження, всім підключеним до однієї бази даних, чи можете ви назвати це розподіленою програмою? Згадай моє визначення згори:

Розподілена система - це група комп’ютерів, що працюють разом, щоб виглядати кінцевим користувачем як єдиний комп’ютер. Ці машини мають спільний стан, працюють одночасно і можуть самостійно виходити з ладу, не впливаючи на час роботи всієї системи.

Якщо ви вважаєте базу даних загальним станом, ви можете стверджувати, що її можна класифікувати як розподілену систему, але ви помиляєтесь, оскільки пропустили частину визначення " спільної роботи ".

Система розподіляється лише в тому випадку, якщо вузли взаємодіють між собою для координації своїх дій.

Тому щось на зразок програми, яка запускає свій внутрішній код у одноранговій мережі, можна краще класифікувати як розподілену програму. Незважаючи на це, це все непотрібна класифікація, яка не має жодної мети, але ілюструє, наскільки ми вередуємо щодо групування речей.

Відомий масштаб - рой BitTorrent з 193 000 вузлів для епізоду гри престолів, квітень 2014 р.

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

Erlang - це функціональна мова, яка має чудову семантику паралельності, розподілу та відмовостійкості. Віртуальна машина Erlang сама займається розповсюдженням програми Erlang.

Його модель працює, маючи безліч ізольованих легких процесів, усі з можливістю спілкуватися між собою за допомогою вбудованої системи передачі повідомлень. Це називається модель актораа OTP-бібліотеки Erlang можна розглядати як розподілену структуру акторів (на зразок Akka для JVM).

Модель - це те, що допомагає їй досить просто досягти суперечливості - процеси розподілені по доступних ядрах системи, що їх запускає. Оскільки це неможливо відрізнити від налаштування мережі (крім можливості скидання повідомлень), віртуальна машина Erlang може підключатися до інших віртуальних машин Erlang, що працюють в тому ж центрі обробки даних або навіть на іншому континенті. Цей рій віртуальних машин запускає одну програму та обробляє відмови машини через поглинання (інший вузол планується запустити).

Фактично, розподілений шар мови був доданий для забезпечення відмовостійкості. Програмне забезпечення, що працює на одній машині, завжди ризикує загинути та перевести вашу програму в автономний режим. Програмне забезпечення, що працює на багатьох вузлах, дозволяє легше обробляти апаратні збої за умови, що програма була побудована з урахуванням цього.

BitTorrent

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

За допомогою клієнта BitTorrent ви підключаєтеся до кількох комп’ютерів по всьому світу, щоб завантажити файл. Коли ви відкриваєте файл .torrent, ви підключаєтесь до так званого трекера , який є машиною, яка виконує роль координатора. Це допомагає з одноранговим виявленням, показуючи вам вузли в мережі, які мають потрібний файл.

У вас є поняття про двох типів користувачів - про п’явку та про сіялку . Leecher - це користувач, який завантажує файл, а сіялка - це користувач, який завантажує вказаний файл.

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

BitTorrent та його попередники (Gnutella, Napster) дозволяють вам добровільно розміщувати файли та завантажувати їх іншим користувачам, які їх хочуть. Причина, по якій BitTorrent настільки популярна, полягає в тому, що вона перша у своєму роді запропонувала стимули для внеску в мережу. Фрірайдінг , коли користувач завантажував лише файли, був проблемою попередніх протоколів обміну файлами.

BitTorrent до певної міри вирішив фрірайдинг, змусивши сівалки завантажувати більше тим, хто забезпечує найкращі показники завантаження. Це працює, стимулюючи вас завантажувати під час завантаження файлу. На жаль, після закінчення ніщо не змушує вас залишатися активними в мережі. Це спричиняє відсутність у мережі сіялок, які мають повний файл, і оскільки протокол значною мірою покладається на таких користувачів, такі рішення, як приватні трекери, втілилися в життя. Приватні трекери вимагають, щоб ви були членом спільноти (часто лише за запрошеннями), щоб брати участь у розподіленій мережі.

Після прогресу в галузі були винайдені безслідні потоки. Це було оновленням протоколу BitTorrent, який не покладався на централізовані трекери для збору метаданих та пошуку однолітків, а використовував нові алгоритми. Одним з таких прикладів є Kademlia (Mainline DHT), розподілена хеш-таблиця (DHT), яка дозволяє знаходити однолітки за допомогою інших рівних. Фактично кожен користувач виконує обов'язки трекера.

Розподілені книги

Розподілену книгу можна вважати незмінною базою даних, яка лише додається, яка реплікується, синхронізується та спільно використовується між усіма вузлами розподіленої мережі.

Відомий масштаб - мережа Ethereum мала пік 1,3 мільйона транзакцій на день 4 січня 2018 року.

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

Блокчейн

Blockchain - це поточна основна технологія, яка використовується для розподілених книг і фактично ознаменувала їх початок. Це останнє і найбільше нововведення в розподіленому просторі дозволило створити перший в історії справді розподілений платіжний протокол - біткойн.

Блокчейн - це розподілена книга, що містить упорядкований список усіх транзакцій, які коли-небудь відбувалися в її мережі. Транзакції групуються і зберігаються в блоках. Весь блокчейн - це, по суті, пов'язаний список блоків (звідси і назва) . Зазначені блоки обчислювально дорогі у створенні і тісно пов’язані між собою за допомогою криптографії.

Простіше кажучи, кожен блок містить спеціальний хеш (який починається з кількості нулів X) вмісту поточного блоку (у вигляді дерева Меркла) плюс хеш попереднього блоку. Цей хеш вимагає великої потужності центрального процесора, оскільки єдиний спосіб його придумати - груба сила.

Майнери - це вузли, які намагаються обчислити хеш (за допомогою bruteforce). Усі майнери конкурують між собою за те, хто може придумати випадковий рядок (який називається nonce ), який, поєднуючись із вмістом, створює згаданий хеш. Як тільки хтось знаходить правильний нонс - він транслює його по всій мережі. Потім зазначений рядок перевіряється кожним вузлом самостійно і приймається в їх ланцюжок.

Це перетворюється на систему, де модифікувати блокчейн абсурдно дорого, а до абсурду легко переконатися, що він не підроблений.

Змінювати вміст блоку дорого, оскільки це призведе до іншого хешу. Пам'ятайте, що хеш кожного наступного блоку залежить від нього. Якби вам потрібно було змінити транзакцію в першому блоці на малюнку вище, ви б змінили корінь Merkle. Це, в свою чергу, змінило б хеш блоку (швидше за все, без необхідних початкових нулів) - це змінило б хеш блоку # 2 і так далі тощо. Це означає, що вам потрібно буде застосувати нову форму для кожного блоку після того, який ви щойно змінили.

Мережа завжди довіряє і копіює найдовший дійсний ланцюжок. Для того, щоб обдурити систему і врешті-решт створити довший ланцюг, вам знадобиться більше 50% загальної потужності процесора, що використовується усіма вузлами.

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

Це безпрецедентне нововведення нещодавно стало бумом у технічному просторі, і люди прогнозують, що це ознаменує створення Інтернету 3.0. На сьогодні це, безумовно, найбільш захоплюючий простір у світі програмної інженерії, наповнений надзвичайно складними та цікавими проблемами, які чекають свого вирішення.

Біткойн

Те, що не вистачало попереднім розподіленим платіжним протоколам, - це спосіб практично запобігти проблемі подвійних витрат у режимі реального часу розподіленим способом. Дослідження дали цікаві пропозиції [1], але біткойн першим застосував практичне рішення з явними перевагами перед іншими.

Проблема подвійного витрачання стверджує, що актор (наприклад, Боб) не може витратити свій власний ресурс у двох місцях. Якщо у Боба 1 долар, він не зможе передати його Алісі та Заку - це лише один актив, його не можна дублювати. Виявляється, дійсно важко досягти цієї гарантії в розподіленій системі. Існує кілька цікавих підходів до пом’якшення наслідків перед блокчейном, але вони не повністю вирішують проблему на практиці.

Біткойн легко вирішує подвійні витрати, оскільки одночасно до ланцюга додається лише один блок. Подвійні витрати неможливі в межах одного блоку, тому навіть якщо два блоки створюються одночасно - лише один стане в кінцевому підсумку найдовшим ланцюгом.

Біткойн покладається на труднощі накопичення потужності процесора.

У той час як в системі голосування зловмисникові потрібно лише додавати вузли до мережі (що легко, оскільки вільний доступ до мережі є ціллю проектування), у схемі, що базується на потужності процесора, зловмисник стикається з фізичним обмеженням: отримання доступу до все більшої кількості потужне обладнання.

Це також причина, чому зловмисним групам вузлів потрібно контролювати понад 50% обчислювальної потужності мережі, щоб фактично здійснити будь-яку успішну атаку. Менше цього, а решта мережі швидше створить довший блокчейн.

Ефіріум

Ефіріум можна сприймати як програмовану програмну платформу на основі блокчейну. У нього є своя криптовалюта (Ether), яка підживлює розгортання смарт-контрактів на своєму блокчейні.

Смарт-контракти - це фрагмент коду, що зберігається як одна транзакція в блокчейні Ethereum. Для запуску коду достатньо лише оформити транзакцію зі смарт-контрактом як місце призначення. Це, у свою чергу, змушує вузли майнера виконувати код та будь-які зміни, які він спричиняє. Код виконується всередині віртуальної машини Ethereum.

Solidity , рідна мова програмування Ethereum, - це те, що використовується для написання смарт-контрактів. Це повноцінна мова програмування, яка безпосередньо взаємодіє з блокчейном Ethereum, дозволяючи запитувати стан, наприклад, залишки або інші результати розумних контрактів. Щоб запобігти нескінченним циклам, для запуску коду потрібна певна кількість ефіру.

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

Подальші звичаї розподілених книг

Доказ існування - Служба для анонімного та надійного зберігання доказів існування певного цифрового документа в певний момент часу. Корисно для забезпечення цілісності документа, права власності та позначення часу.

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

Децентралізована автентифікація - зберігайте свою особу на блокчейні, що дозволяє використовувати єдиний вхід (SSO) скрізь. Соврін, Громадянський

І багато-багато іншого. Технологія розподіленого реєстру справді відкривала безмежні можливості. Деякі, швидше за все, вигадуються, коли ми говоримо!

Резюме

За короткий проміжок цієї статті ми спромоглися визначити, що таке розподілена система, чому ви використовуєте одну та трохи переглядаєте кожну категорію. Важливо пам’ятати:

  • Розподілені системи є складними
  • Вони вибираються за необхідністю масштабу та ціни
  • З ними важче працювати
  • Теорема CAP - компроміс на узгодженість / доступність
  • Вони мають 6 категорій - сховища даних, обчислювальна техніка, файлові системи, системи обміну повідомленнями, книги, програми

Чесно кажучи, ми ледве торкнулися поверхні розподілених систем. У мене не було можливості ретельно вирішити та пояснити такі основні проблеми, як консенсус, стратегії реплікації, порядок подій та час, терпімість відмов, трансляція повідомлення по мережі та інші.

Обережно

Дозвольте мені залишити вас із попередженням про розставання:

Ви повинні якомога більше відхилятися від розподілених систем. Складність накладних витрат, яку вони породжують із собою, не варта зусиль, якщо ви можете уникнути проблеми, вирішивши її іншим способом або іншим нестандартним рішенням.

[1]

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

Bitgold , грудень 2005 р. - Огляд високого рівня протоколу, надзвичайно схожого на біткойн. Кажуть, це попередник біткойна.

Подальше читання розподілених систем:

Мартін Клеппманн, розробник інтенсивно оброблюваних даних, - чудова книга, яка розглядає все в розподілених системах та багато іншого.

Спеціалізація хмарних обчислень, Університет Іллінойсу, Coursera - довга серія курсів (6), що охоплюють концепції розподіленої системи, програми

Jepsen - Блог, що пояснює багато розподілених технологій (ElasticSearch, Redis, MongoDB тощо)

Дякуємо, що знайшли час прочитати цю довгу (~ 5600 слів) статтю!

Якщо, випадково, ви виявили цю інформативну інформацію або вважаєте, що вона надає вам цінності, переконайтеся, що ви даєте їй стільки аплодувань, на вашу думку, що вона заслуговує, та подумайте про поділитися з другом, який міг би використати вступ до цієї чудової галузі дослідження.

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

Оновлення

Зараз я працюю в Confluent. Confluent - компанія з великими даними, заснована самими творцями Apache Kafka! Я надзвичайно вдячний за можливість, яку вони мені дали - в даний час я працюю над самою Кафкою, що надзвичайно чудово! Ми, Confluent, допомагаємо сформувати всю екосистему Kafka з відкритим кодом, включаючи нову керовану хмарну пропозицію Kafka як послуга.

Ми наймаємо на багато посад (особливо SRE / Інженери-програмісти) в Європі та США! Якщо вам цікаво працювати над самою Kafka, шукати нових можливостей або просто цікаво - не забудьте надіслати мені повідомлення в Twitter, і я поділюсь усіма чудовими привілеями від роботи в компанії в бухті.