Б Бёрнс - Распределенные системы. Паттерны проектирования

Глава 11. Событийно-ориентированная пакетная обработка 195

Рис. 11.4. Пример реализации паттерна пакетной обработки Splitterдля рассылки уведомлений о доставке посредством двух очередей задач Представьте, к примеру, что вы неудачно обновили контей-нер-исполнитель, в результате чего все его экземпляры отка-зали и очередь задач перестала обрабатываться. Если задачи обрабатываются только одной очередью, то сервис окажется полностью недоступным для всех пользователей. Если бы вы шардировали очередь на четыре части, то у вас была бы воз-можность организовать поэтапное развертывание контейнера-исполнителя. Предположим, вы обнаруживаете отказ на первом этапе развертывания. При шардировании на четыре части отказ

повлияет только на четверть пользователей вашего сервиса. Еще один довод в пользу шардирования — более равномерное распределение нагрузки на вычислительные ресурсы. Если вам не особенно важно, за обработку каких задач будет отвечать конкретный центр обработки данных (ЦОД), шардером можно воспользоваться для распределения задач между несколькими ЦОД, чтобы выровнять нагрузку серверов в них. Что касается 196Часть III. Паттерны проектирования систем пакетных вычислений обновлений, распределение очереди задач между несколькими точками отказа повышает надежность, позволяя избежать от-каза всех серверов в конкретном ЦОД или целом регионе. Шардированная очередь, работающая в штатном режиме, по-казана на рис. 11.5.

Рис. 11.5. Пример реализации шардированной очереди, работающейв штатном режиме

Если в силу отказов количество рабочих шардов уменьшилось, алгоритм шардирования динамически перестраивается на рас-пределение работы только между рабочими шардами, даже если осталась только одна очередь задач. Это показано на рис. 11.6. Паттерн Merger

Последним среди паттернов событийно-ориентированных систем пакетной обработки рассмотрим паттерн Merger. Он выполняет Глава 11. Событийно-ориентированная пакетная обработка 197

Рис. 11.6. При отказе одной из очередей задач оставшиеся переходятв другую очередь

задачу, обратную задаче паттерна Copier, — объединяет две оче-реди в одну общую. Допустим, в вашем проекте много разных репозиториев исходного кода, коммиты в которые происходят одновременно. Вы хотите выполнить тестирование и сборку каж-

дого из них. Создавать отдельную инфраструктуру для сборки репозитория — плохо масштабируемое решение. Каждый из ре-позиториев можно смоделировать в виде очереди задач, служащей источником задач-коммитов. Все эти источники задач можно объединить в один интегрированный источник с помощью адап-тера-объединителя. Такой объединенный поток коммитов служит единственным источником задач для системы сборки, выступаю-щей исполнителем. Контейнер-объединитель является частным случаем реализации паттерна Adapter. Такой адаптер преобразует потоки задач от нескольких контейнеров-источников в общий по-ток задач. Схема паттерна Multi-Adapter приведена на рис. 11.7. 198Часть III. Паттерны проектирования систем пакетных вычислений

Рис. 11.7. Использование нескольких уровней контейнеровдля объединения нескольких очередей задач в одну общую

Практикум. Создание событийно-ориентированного потока задач для регистрации нового пользователя Пример конкретного потока задач позволяет показать, как эти паттерны можно объединить для получения полноценной рабо-чей системы. В данном примере рассматривается задача реги-страции нового пользователя.

Глава 11. Событийно-ориентированная пакетная обработка 199Представьте, что наша «воронка» получения пользователей работает в два этапа. Первый — верификация. После реги-страции в сервисе пользователь получает уведомление, по-зволяющее подтвердить его адрес электронной почты. После одобрения адреса пользователь получает письмо, подтвер-ждающее его членство. Затем его по желанию подписывают на почтовую и/или СМС-рассылку.