Zookeeper — це підпроєкт Hadoop, і хоча він походить від Hadoop, я помітив, що Zookeeper дедалі частіше використовує розподілені фреймворки поза Hadoop. Сьогодні я хочу поговорити про Zookeeper, ця стаття не буде про те, як користуватися Zookeeper, а про те, які практичні застосування Zookeeper, які типи додатків можуть мати переваги Zookeeper, і нарешті про те, яку роль Zookeeper може відігравати в архітектурі розподілених сайтів.
Zookeeper — це дуже надійна система координації для великих розподілених систем. З цього визначення ми знаємо, що zookeeper — це скоординована система, яка діє на розподілених системах. Чому розподілені системи потребують координаційної системи? Причини такі:
Розробка розподіленої системи — дуже складна справа, і ця складність головним чином відображається у «частковому відмові» розподіленої системи. «Частковий відбій» означає передачу інформації між двома вузлами мережі: якщо мережа виходить з ладу, відправник не може знати, чи отримав отримувач повідомлення, і причина цієї несправності є складною: отримувач міг отримати повідомлення або не отримати повідомлення до помилки мережі, або процес приймача мертвий. Єдиний спосіб, яким відправник отримає реальну картину — це знову підключитися до приймача і запитати отримувача, чому виникла помилка, що є проблемою «часткового збою» у розподіленій системній розробці.
Zookeeper є основою для вирішення «часткової несправності» розподілених систем. Zookeeper не дозволяє розподіленим системам уникати проблем «часткових відмов», але дозволяє розподіленим системам правильно вирішувати такі проблеми при виникненні часткових збоїв, щоб розподілені системи могли працювати нормально.
Давайте поговоримо про практичне застосування доглядача зоопарку:
Сценарій 1: Існує група серверів, які надають певний сервіс клієнту (наприклад, серверна частина розподіленого сайту, який я створив раніше, — це кластер із чотирьох серверів для надання послуг фронтенд-кластеру), і ми сподіваємося, що клієнт зможе знаходити сервер у кластері серверів щоразу, коли клієнт запитує, щоб надавати клієнту необхідні послуги. У такому випадку нам потрібен список серверів у нашій програмі, з якого ми читаємо список серверів щоразу, коли клієнт його запитує. Тоді цей підсписок, очевидно, не можна зберігати на одному вузловому сервері, інакше вузол зависне, і весь кластер зазнає відмови, і ми сподіваємося, що цей список буде дуже доступним у цей момент. Якщо сервер у списку зберігання зламаний, інші сервери можуть одразу замінити зламаний сервер, і зламаний сервер можна видалити зі списку, щоб зламаний сервер міг відійти від роботи всього кластера, і всі ці операції виконуватимуться не зламаним сервером, а звичайним сервером у кластері. Це активна розподілена структура даних, яка може активно змінювати стан елементів даних при зміні зовнішніх умов. Фреймворк Zookeeper надає цю послугу. Назва цього сервісу: Unified Nameing Service, який дуже схожий на сервіс JNDI у javaEE.
Сценарій 2: Розподілений сервіс блокування. Коли розподілена система маніпулює даними, такими як читання даних, аналіз даних і, нарешті, модифікація даних. У розподіленій системі ці операції можуть бути розподілені між різними вузлами кластеру, тоді виникає проблема узгодженості в процесі роботи з даними, якщо вона неузгоджена, ми отримаємо неправильний результат операції, у програмі одного процесу задачу узгодженості легко розв'язати, але дістатися до розподіленої системи складніше, оскільки операції різних серверів у розподіленій системі відбуваються в незалежних процесах, а проміжні результати та процеси мають передаватися через мережу. Тоді набагато складніше досягти послідовності з роботою з даними. Zookeeper надає сервіс блокування, який вирішує цю проблему, дозволяючи нам забезпечити узгодженість операцій з даними при виконанні розподілених операцій.
Сценарій 3: Управління конфігурацією. У розподіленій системі ми розгортаємо сервісний додаток на n серверах окремо, і конфігураційні файли цих серверів однакові (наприклад, у фреймворку розподіленого вебсайту, який я розробив, на серверній стороні є 4 сервери, програми на 4 серверах однакові, а конфігураційні файли однакові), якщо параметри конфігурації конфігураційних файлів змінюються, то потрібно змінювати ці конфігураційні файли один за одним, якщо потрібно змінити сервери відносно невеликі, ці операції не надто складні, Якщо у нас велика кількість розподілених серверів, наприклад, кластер Hadoop великої інтернет-компанії з тисячами серверів, то зміна параметрів конфігурації може бути складною та небезпечною. Зараз zookeeper може стати в пригоді, ми можемо використовувати zookeeper як високодоступну конфігураційну пам'ять, передати її zookeeper для управління, копіюємо конфігураційний файл кластера на вузол файлової системи zookeeper, а потім використовуємо zookeeper для моніторингу стану файлу конфігурації у всіх розподілених системах, коли виявляється, що файл конфігурації змінився, Кожен сервер отримає сповіщення від Zookeeper для синхронізації конфігураційних файлів у Zookeeper, а сервіс Zookeeper також гарантує, що операція синхронізації є атомарною для правильного оновлення конфігураційного файлу кожного сервера.
Сценарій 4: Забезпечити функції ремонту несправностей для розподілених систем. Управління кластером складне, і додавання сервісу Zookeeper до розподіленої системи полегшує нам управління кластером. Найскладнішим у управлінні кластером є управління несправностями вузлів: zookeeper може дозволити кластеру обрати здоровий вузол як майстра, головний вузол знатиме поточний стан стану стану кожного сервера в кластері, а після відмови вузла майстер повідомить інші сервери кластера, щоб перерозподілити обчислювальні завдання різних вузлів. Zookeeper може не лише знаходити несправності, а й відстежувати несправний сервер, виявляти, який тип несправності є сервером несправності, якщо несправність можна виправити, Zookeeper може автоматично виправити або повідомити системному адміністратору причину помилки, щоб адміністратор міг швидко знайти проблему і усунути несправність вузла. Можливо, у вас все ще є питання: що робити, якщо головний пристрій несправний? Zookeeper також враховує це: у zookeeper є внутрішній «алгоритм для вибору лідерів», майстрів можна динамічно обирати, а коли майстер не справляється, він одразу може обрати нового майстра для управління кластером.
Давайте поговоримо про особливості Zookeeper:
ZooKeeper — це оптимізована файлова система. Це трохи схоже на Hadoop, але файлова система ZooKeeper керує дрібними файлами, а Hadoop — дуже великими.
Zookeeper надає безліч «артефактів», які дозволяють багатьом операціям координувати структури даних і протоколи. Наприклад: розподілені черги, розподілені блокування та алгоритм «вибору лідера» групи вузлів на одному рівні.
ZooKeeper дуже доступний, його власна стабільність досить хороша, розподілені кластери можуть покладатися на управління кластерами Zookeeper, а ZooKeeper використовується для уникнення проблеми одноточкового збою розподілених систем.
Zookeeper використовує слабо пов'язаний режим взаємодії. Це особливо помітно в тому, що Zookeeper надає розподілені замки, які можуть використовуватися як механізм призначення для того, щоб учасники могли знаходити та взаємодіяти між собою без знань інших процесів (або мережі), і учасникам навіть не обов'язково існувати одночасно, якщо вони залишають повідомлення в Zookeeper, а після завершення процесу інший процес може прочитати це повідомлення, таким чином роз'єднуючи зв'язки між вузлами.
ZooKeeper надає спільний репозиторій для кластера, з якого кластер може централізовано читати та записувати спільну інформацію, уникаючи програмування спільних операцій для кожного вузла та знижуючи складність розробки розподілених систем.
Zookeeper головним чином відповідає за зберігання та управління даними, які важливі для всіх, а потім приймає реєстрацію спостерігачів; після зміни статусу цих даних Zookeeper відповідатиме за повідомлення тих спостерігачів, які зареєструвалися на Zookeeper, щоб вони відповідали відповідно, щоб досягти режиму управління майстер/підлеглим, подібного до кластера.
Видно, що zookeeper дуже сприяє розподіленій розробці систем, що робить розподілені системи більш надійними та ефективними.
Нещодавно я брав участь у групі інтересів Hadoop у відділі, встановив hadoop, mapreduce, Hive і Hbase у тестовому середовищі, а також заздалегідь встановив Zookeeper під час встановлення hbase. Zookeeper може надавати послуги, тому більше половини з 3 — це 2, а більше половини з 4 — це також два, тому встановлення трьох серверів може досягти ефекту 4 серверів. У процесі вивчення Hadoop я вважаю, що Zookeeper — найскладніший підпроєкт для розуміння, причина не в тому, що він технічно відповідальний, а в тому, що напрямок його застосування для мене дуже заплутаний, тому моя перша стаття про технологію Hadoop починається з Zookeeper і не стосується конкретної технічної реалізації, але з огляду на сценарії застосування Zookeeper, я розумію сферу застосування Zookeeper, думаю, навчання Zookeeper буде ефективнішим з половиною зусиль.
Причина, чому я хочу сьогодні поговорити про Zookeeper, — це доповнити фреймворк розподіленого вебсайту з моєї попередньої статті. Хоча я розробив архітектуру сайту як розподілену структуру, я також створив простий механізм обробки помилок, наприклад, механізм серцебиття, але все одно неможливо вирішити єдину точку відмови кластера: якщо сервер зламаний, клієнт намагається підключитися до нього, що призводить до блокування деяких запитів і марнотратства ресурсів сервера. Однак наразі я не хочу змінювати свій фреймворк, бо завжди вважаю, що додавання сервісу доглядача зоопарку до існуючих сервісів вплине на ефективність сайту. На щастя, наш відділ також зіткнувся з такою проблемою: наш відділ розробить потужну систему віддалених дзвінків, розділить управління кластером і комунікації, а також забезпечить ефективні та доступні послуги централізовано.
Переведено з ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Опубліковано 18.07.2017 14:19:01
|
|
|
