Sharding в построении отказоустойчивого сервиса | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
Backend-разработчик на PHP
-9%
Алгоритмы и структуры данных
-9%
Team Lead
-6%
Архитектура и шаблоны проектирования Разработчик IoT
-13%
C# Developer. Professional
-9%
HTML/CSS
-11%
C# ASP.NET Core разработчик
-5%
Kotlin Backend Developer
-8%
iOS Developer. Professional
-8%
Symfony Framework Java Developer. Basic C++ Developer. Professional Web-разработчик на Python MS SQL Server Developer Android Developer. Basic Разработчик программных роботов (RPA) на базе UiPath и PIX Microservice Architecture Unity Game Developer. Basic Разработчик голосовых ассистентов и чат-ботов React.js Developer Node.js Developer Интенсив «Оптимизация в Java» Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Супер-интенсив «СУБД в высоконагруженных системах» Супер-интенсив "Tarantool" C++ Developer. Basic
Инфраструктура
Administrator Linux.Basic
-10%
Мониторинг и логирование: Zabbix, Prometheus, ELK
-10%
Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes»
-30%
Administrator Linux. Professional
-6%
Дизайн сетей ЦОД
-13%
Разработчик IoT
-13%
Экспресс-курс по управлению миграциями (DBVC)
-10%
Базы данных Network engineer Разработчик программных роботов (RPA) на базе UiPath и PIX Microservice Architecture Reverse-Engineering. Professional Внедрение и работа в DevSecOps Administrator Linux. Advanced Infrastructure as a code in Ansible Супер-практикум по использованию и настройке GIT Супер-интенсив «СУБД в высоконагруженных системах» Супер-интенсив "Tarantool"
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Sharding в построении отказоустойчивого сервиса

В предыдущих заметках мы рассказывали про горизонтальное масштабирование, CQRS и архитектурный паттерн Event Sourcing. Но, как известно, в системах с Event Sourcing нет строгой согласованности. А это значит, что нам можно задействовать сразу несколько хранилищ, причем без синхронизации между этими хранилищами.

Так как задача заключается в построении быстрого и отказоустойчивого сервиса, то мы можем: • разделить файлы по типам. К примеру, изображения и видео можно декодировать, выбрав наиболее эффективный формат; • разделить аккаунты по странам. Эта схема архитектуры предоставляет такую возможность автоматически, но вообще, необходимость в этом может возникнуть и по законодательным причинам.

w_p53t4fb_02tfjmoyre6rlgpfe_1-1801-1729d2.png

Однако если вы пожелаете осуществить перенос данных из одного хранилища в другое, стандартными средствами здесь не обойтись. К сожалению, в этом случае надо будет остановить очередь, сделать миграцию, а далее запустить ее. В общей ситуации вы не сможете перенести данные, что называется, «на лету», но если очередь событий сохраняется полностью, и у вас существуют слепки предыдущих состояний вашего хранилища, то можно переиграть события следующим образом:

• так как в Event Source каждое событие имеет собственный id (в идеале он не уменьшается), то в хранилище добавляем поле — идентификатор последнего обработанного элемента; • выполняем дублирование очереди, чтобы события смогли обрабатываться для нескольких независимых хранилищ (первое хранилище — это хранилище, где данные хранятся уже сейчас, второе — новое хранилище, пока пустое). При этом 2-я очередь пока обрабатываться не будет; • выполняем запуск 2-й очереди (начинаем переигрывать события); • если новая очередь будет относительно пуста (речь идет о том, чтобы средняя разница во времени между добавлением и извлечением элемента была приемлема), можно приступать к переключению пользователей на новое хранилище.

К чему в итоге пришли? В системе до сих пор нет строгой согласованности. Зато есть eventual constistency и гарантия того, что события будут обрабатываться в одинаковом порядке (правда, возможно, с разной задержкой). А уже пользуясь этим, мы сможем относительно легко перенести данные на другой конец планеты, не останавливая при этом систему.

Какие плюсы дает подобная архитектура, если мы строим онлайн-хранилище для файлов: • есть возможность перемещать объекты поближе к пользователям, причем делая это динамически. А значит, повышается качество сервиса; • есть возможность хранить часть информации внутри компаний. К примеру, Enterprise-пользователи часто требуют хранить свои данные в подконтрольных дата-центрах (для предотвращения утечек). А благодаря sharding мы можем без проблем это обеспечить. Причем задача становится еще более простой, если в распоряжении заказчика есть совместимое облако (допустим, Azure self hosted); • не обязательно сразу писать код. Для начала нас вполне устроит одно хранилище для всех аккаунтов (это позволит быстрее начать работу). Таким образом, мы подходим к ключевой особенности системы — пусть она и расширяема, однако на начальном этапе она относительно проста. Следовательно, нет необходимости сразу же писать код, который будет работать с миллионом независимых отдельных очередей и т. п. То есть если понадобится, мы просто сделаем это в будущем.

По материалам блога компании «Технологический Центр Дойче Банка» (https://habr.com/ru/company/dbtc/).

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться