Как стать автором
Обновить

Комментарии 7

Простите, а можно у вас поинтересоваться, вы статью для людей или для отчетности писали?

Судя по статье, мы даже не гарантируем 2 пункта из 3. Скорее 1.5. Интересно, а в теории реально ли создать что-то, которое близко к выполнению всех 3 принципов CAP?! Возможно что-то нужно изменить в архитектуре или реализации.

Попробуем порассуждать:
Есть 3 понятия: целостность, доступность и устойчивость к сбоям в сети
На самом деле для одной части системы важнее целостность, а для другой доступность, а для третьей — устойчивость к сбоям.

Самое важное при разработке таких систем — это правильно поделить пирог (т.е. правильно разделить части системы). К примеру возьмём абстрактный сервис картинок вроде инстаграмма. Какие части можно выделить? Авторизацию и сессии, профайлы пользователей + настройки, хранение самих картинок.
Каждая часть системы относительно независима, поэтому есть смысл выделить их в отдельные сервисы.

Теперь расставим приоритеты:
— Авторизация — нам важна целостность и доступность (и этот сервис будет важным для остальных частей системы)
— Настройки и профили — нам нужно всего понемногу
— Сервис картинок — нам важна доступность и устойчивость к сбоям (т.к. это основной сервис который мы предоставляем)

Рассмотрим варианты защиты от проблем:
— Отвалился сервис авторизации — активные юзеры продолжают пользоваться сервисами (они могут добавлят и удалять картинки и менять профиль т.к. эта информация хранится отдельно и целостность обеспечивается внутри этих сервисов). Анонимные пользователи продолжают пользоваться сервисом (им не нужна авторизация). Если сервис остался доступным, но потерялась связь с остальными, то проблемы возникают только у новых пользователей (функциональность ограничена — временно могут работать как анонимные).
— Отвалился сервис картинок — такого быть не должно. Поэтому резервируем его. Настраиваем синхронизацию / репликацию. Теряем тем самым целостность данных, но получаем доступность и устойчивость к сбоям.
— Отвалился сервис профайлов — настроек. Проблемы возникают только у зарегистрированных пользователей. Поэтому создаём read-only копию в качестве резерва и распределения нагрузки. При падении основного сервиса пользователи смогут читать данные, но временно не смогут редактировать профиль. Целостность сохранена (на самом деле только частично для чтения), доступность — частичная. Устойчивость к сбоям — частичная.

Масштабировать данные сервисы тоже относительно легко. Для сервиса картинок будет уменьшаться целостность, для сервиса профилей-настроек ничего принципиально не изменится т.к. чтений намного больше чем записей и достаточно масштабировать только read-only копии. Для сервиса авторизации — можем использовать похожий подход т.е. создание пользователей осуществаляется одним сервисом, а зеркала используются в режиме чтения. Но появляются проблемы с записью, а именно с целостностью данных в случае если зеркало отвалилось от остальной части системы. Эту проблему можно уменьшить созданием очередей сообщений для важных действий таких как удаление или создание пользователя или двойными транзациями.

Что в итоге: как только мы начинаем дублировать (горизонтально масштабировать) сервисы, это приводит к проблемам с целостностью и сильно усложняет систему и взаимодействия. Возможно стоит смотреть в направлении микросервисов, т.е. создавать сервисы такого размера, чтобы они были независимы с одной стороны, и легковесными с другой стороны (чтобы не нужно было из горизонтально масштабировать).

Похоже нашли применение новой нокии 3310, теперь на нее можно делать скрины с кодом)))


ЗЫ Доклад хороший мне понравился

Про принципы cap не слышал, но знаю acid.
https://en.wikipedia.org/wiki/ACID
Сейчас оно всё собирает, это вам не динамически языки, когда всё сразу работает, тут всё долго и мучительно. Есть время подумать, то ли ты написал, не то написал, переписать всё, пока деплоится.
Здесь что-то не так. Во-первых, потому что это Scala, там всегда что-то может быть не так.
Шикарно!
У нас есть два клиента. Мы здесь записали операцию А, дальше ноды сказали «ок», мы записали, у нас тут кворум сошелся. Но пока мы не сказали клиенту, что мы записали А, вот здесь прибежал более быстрый клиент, который успел записать B, ноды ему сказали, что кворум сошёлся, и мы тоже успели сказать, что всё хорошо. Этому клиенту мы сказали, что мы записали B, этому мы сказали, что мы записали А. Тут мы прочитали что-то, что же мы тут такое прочитали?

все смешалось, кони люди…
такая ситуация возможна и в нераспределенной системе. Для избежания этого делают транзакции с разным уровнем изоляции. Без этого нельзя гарантировать что чтение вернет данные, которые были записаны ранее. RAFT здесь ничем не поможет очевидно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы