Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
Простите, а можно у вас поинтересоваться, вы статью для людей или для отчетности писали?
Судя по статье, мы даже не гарантируем 2 пункта из 3. Скорее 1.5. Интересно, а в теории реально ли создать что-то, которое близко к выполнению всех 3 принципов CAP?! Возможно что-то нужно изменить в архитектуре или реализации.
Попробуем порассуждать:
Есть 3 понятия: целостность, доступность и устойчивость к сбоям в сети
На самом деле для одной части системы важнее целостность, а для другой доступность, а для третьей — устойчивость к сбоям.
Самое важное при разработке таких систем — это правильно поделить пирог (т.е. правильно разделить части системы). К примеру возьмём абстрактный сервис картинок вроде инстаграмма. Какие части можно выделить? Авторизацию и сессии, профайлы пользователей + настройки, хранение самих картинок.
Каждая часть системы относительно независима, поэтому есть смысл выделить их в отдельные сервисы.
Теперь расставим приоритеты:
— Авторизация — нам важна целостность и доступность (и этот сервис будет важным для остальных частей системы)
— Настройки и профили — нам нужно всего понемногу
— Сервис картинок — нам важна доступность и устойчивость к сбоям (т.к. это основной сервис который мы предоставляем)
Рассмотрим варианты защиты от проблем:
— Отвалился сервис авторизации — активные юзеры продолжают пользоваться сервисами (они могут добавлят и удалять картинки и менять профиль т.к. эта информация хранится отдельно и целостность обеспечивается внутри этих сервисов). Анонимные пользователи продолжают пользоваться сервисом (им не нужна авторизация). Если сервис остался доступным, но потерялась связь с остальными, то проблемы возникают только у новых пользователей (функциональность ограничена — временно могут работать как анонимные).
— Отвалился сервис картинок — такого быть не должно. Поэтому резервируем его. Настраиваем синхронизацию / репликацию. Теряем тем самым целостность данных, но получаем доступность и устойчивость к сбоям.
— Отвалился сервис профайлов — настроек. Проблемы возникают только у зарегистрированных пользователей. Поэтому создаём read-only копию в качестве резерва и распределения нагрузки. При падении основного сервиса пользователи смогут читать данные, но временно не смогут редактировать профиль. Целостность сохранена (на самом деле только частично для чтения), доступность — частичная. Устойчивость к сбоям — частичная.
Масштабировать данные сервисы тоже относительно легко. Для сервиса картинок будет уменьшаться целостность, для сервиса профилей-настроек ничего принципиально не изменится т.к. чтений намного больше чем записей и достаточно масштабировать только read-only копии. Для сервиса авторизации — можем использовать похожий подход т.е. создание пользователей осуществаляется одним сервисом, а зеркала используются в режиме чтения. Но появляются проблемы с записью, а именно с целостностью данных в случае если зеркало отвалилось от остальной части системы. Эту проблему можно уменьшить созданием очередей сообщений для важных действий таких как удаление или создание пользователя или двойными транзациями.
Что в итоге: как только мы начинаем дублировать (горизонтально масштабировать) сервисы, это приводит к проблемам с целостностью и сильно усложняет систему и взаимодействия. Возможно стоит смотреть в направлении микросервисов, т.е. создавать сервисы такого размера, чтобы они были независимы с одной стороны, и легковесными с другой стороны (чтобы не нужно было из горизонтально масштабировать).
Попробуем порассуждать:
Есть 3 понятия: целостность, доступность и устойчивость к сбоям в сети
На самом деле для одной части системы важнее целостность, а для другой доступность, а для третьей — устойчивость к сбоям.
Самое важное при разработке таких систем — это правильно поделить пирог (т.е. правильно разделить части системы). К примеру возьмём абстрактный сервис картинок вроде инстаграмма. Какие части можно выделить? Авторизацию и сессии, профайлы пользователей + настройки, хранение самих картинок.
Каждая часть системы относительно независима, поэтому есть смысл выделить их в отдельные сервисы.
Теперь расставим приоритеты:
— Авторизация — нам важна целостность и доступность (и этот сервис будет важным для остальных частей системы)
— Настройки и профили — нам нужно всего понемногу
— Сервис картинок — нам важна доступность и устойчивость к сбоям (т.к. это основной сервис который мы предоставляем)
Рассмотрим варианты защиты от проблем:
— Отвалился сервис авторизации — активные юзеры продолжают пользоваться сервисами (они могут добавлят и удалять картинки и менять профиль т.к. эта информация хранится отдельно и целостность обеспечивается внутри этих сервисов). Анонимные пользователи продолжают пользоваться сервисом (им не нужна авторизация). Если сервис остался доступным, но потерялась связь с остальными, то проблемы возникают только у новых пользователей (функциональность ограничена — временно могут работать как анонимные).
— Отвалился сервис картинок — такого быть не должно. Поэтому резервируем его. Настраиваем синхронизацию / репликацию. Теряем тем самым целостность данных, но получаем доступность и устойчивость к сбоям.
— Отвалился сервис профайлов — настроек. Проблемы возникают только у зарегистрированных пользователей. Поэтому создаём read-only копию в качестве резерва и распределения нагрузки. При падении основного сервиса пользователи смогут читать данные, но временно не смогут редактировать профиль. Целостность сохранена (на самом деле только частично для чтения), доступность — частичная. Устойчивость к сбоям — частичная.
Масштабировать данные сервисы тоже относительно легко. Для сервиса картинок будет уменьшаться целостность, для сервиса профилей-настроек ничего принципиально не изменится т.к. чтений намного больше чем записей и достаточно масштабировать только read-only копии. Для сервиса авторизации — можем использовать похожий подход т.е. создание пользователей осуществаляется одним сервисом, а зеркала используются в режиме чтения. Но появляются проблемы с записью, а именно с целостностью данных в случае если зеркало отвалилось от остальной части системы. Эту проблему можно уменьшить созданием очередей сообщений для важных действий таких как удаление или создание пользователя или двойными транзациями.
Что в итоге: как только мы начинаем дублировать (горизонтально масштабировать) сервисы, это приводит к проблемам с целостностью и сильно усложняет систему и взаимодействия. Возможно стоит смотреть в направлении микросервисов, т.е. создавать сервисы такого размера, чтобы они были независимы с одной стороны, и легковесными с другой стороны (чтобы не нужно было из горизонтально масштабировать).
Похоже нашли применение новой нокии 3310, теперь на нее можно делать скрины с кодом)))
ЗЫ Доклад хороший мне понравился
Про принципы cap не слышал, но знаю acid.
https://en.wikipedia.org/wiki/ACID
https://en.wikipedia.org/wiki/ACID
Сейчас оно всё собирает, это вам не динамически языки, когда всё сразу работает, тут всё долго и мучительно. Есть время подумать, то ли ты написал, не то написал, переписать всё, пока деплоится.
Здесь что-то не так. Во-первых, потому что это Scala, там всегда что-то может быть не так.Шикарно!
У нас есть два клиента. Мы здесь записали операцию А, дальше ноды сказали «ок», мы записали, у нас тут кворум сошелся. Но пока мы не сказали клиенту, что мы записали А, вот здесь прибежал более быстрый клиент, который успел записать B, ноды ему сказали, что кворум сошёлся, и мы тоже успели сказать, что всё хорошо. Этому клиенту мы сказали, что мы записали B, этому мы сказали, что мы записали А. Тут мы прочитали что-то, что же мы тут такое прочитали?
все смешалось, кони люди…
такая ситуация возможна и в нераспределенной системе. Для избежания этого делают транзакции с разным уровнем изоляции. Без этого нельзя гарантировать что чтение вернет данные, которые были записаны ранее. RAFT здесь ничем не поможет очевидно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Страх и ненависть в распределённых системах