Основы архитектуры ПО. Глава 15 Space-based архитектура / Евгений Кузовлев

• Обсуждение книги "Основы архитектуры" Марка Ричардсона и Нила Форте.  

• Тема обсуждения: глава 15 "Space-Based Architecture".  

• Ведущие: Григорий Скобелев и Николай Голов.  

• Григорий: опыт работы с региональными дата-центрами и распределенной целостностью.  

• Николай: опыт работы в геймдеве, медицине и финтехе, проектирование и разработка информационных систем.  

• Григорий: отсутствие устоявшегося перевода термина.  

• Николай: архитектура по месту, масштабируемость и ускорение за счет приближения контента к пользователю.  

• Григорий: важность выбора подхода масштабирования, соответствующего бизнес-задачам.  

• Николай: необходимость оптимизации запросов и использования доступных ресурсов.  

• Григорий: архитектура выходит за пределы горизонтального и вертикального масштабирования.  

• Николай: важность удовлетворения требований к задержке и консистентности данных.  

• Григорий: примеры геораспределенных систем, таких как YouTube.  

• Николай: использование Google Global Cache для кэширования контента на множестве узлов.  

• Пример рекламной системы, где требуется быстрое время ответа 100 мс.  

• Ноды приближены к пользователям для локального хранения данных.  

• Вопрос о георезервировании и его связи с Space-Based Architecture.  

• Георезервирование может быть частью Space-Based Architecture, если есть несколько точек присутствия.  

• Space-Based Architecture обеспечивает высокую надежность при отказе ноды.  

• Ограничение: оставшееся количество нод должно справляться с нагрузкой.  

• Space-Based Architecture требует глобальности данных.  

• Пример системы продажи авиабилетов, где данные не шардируются для обеспечения скорости отклика.  

• Ограничения на объем данных, переносимых между нодами.  

• Быстрое время отклика и непредсказуемые изменения нагрузки.  

• Потребность в центральном ядре для консистентности данных.  

• Пример с Авито и использованием Tarantool для шардинга и синхронизации данных.  

• Space-Based Architecture применима к системам, хранящим состояние пользователя.  

• Пример с CDN, где контент хранится ближе к пользователю.  

• Проблема целостности данных при множестве копий и изменений.  

• Проблема множественных копий данных и их консистентности.  

• Решение: обращение к единому кластеру баз данных для обеспечения целостности.  

• Основная проблема: низкая скорость при множественных обращениях к базе данных.  

• В процессе обработки запросов пользователей можно забыть о правильной обработке данных.  

• Важно понимать, где и как использовать комиты.  

• Пример системы бронирования авиабилетов для демонстрации работы комитов.  

• При выборе кресла и сохранении данных возникает критическая секция.  

• Алгоритмы решают проблему консистентности и входа в критическую секцию.  

• В многопоточных системах и при масштабировании на весь мир возникают глобальные проблемы.  

• Алгоритмы, основанные на приоритете сигналов, работают эффективно.  

• Используются внутренние идентификаторы системы или таймс-стемпы.  

• Первый запрос с правильным идентификатором получает приоритет.  

• Атомарные часы и тайм-стемпы позволяют соблюдать правильную последовательность запросов.  

• Важно сохранять правильную последовательность данных, даже если они пришли в неправильной последовательности.  

• Алгоритмы на основе атомных часов и тайм-стемпов обеспечивают правильную обработку запросов.  

• Алгоритмы позволяют обрабатывать запросы в правильной последовательности.  

• Логика обработки зависит от приоритетов и идентификаторов.  

• Важно учитывать, когда запрос был инициирован и когда он пришел.  

• Алгоритмы консенсуса, такие как Paxos и Raft, решают проблему выбора нового лидера.  

• Эти алгоритмы имеют множество нюансов и требуют тщательного рассмотрения.  

• Начинающим разработчикам рекомендуется использовать простые решения, такие как семафоры.  

• Очереди сообщений широко используются в микросервисной архитектуре.  

• В книге обсуждается, как прокачивать данные до базы.  

• Важно учитывать архитектуру системы при выборе алгоритмов.  

• Для сортировки ивентов на стороне сервера нужно иметь окно, в рамках которого принимаются ивенты.  

• Вопрос о том, как правильно выбрать длительность ожидания для системы, обеспечивающей быстрый ответ.  

• Важно балансировать между таймфреймами и пингом нот и хранилища.  

• Точки синхронизации данных должны быть редкими.  

• В системах бронирования важно быстрое реагирование на действия пользователя.  

• Вопрос о фреймворках для спейс-спейс архитектуры.  

• Пример с системой бронирования, где важно брать первый эвент по идентификатору.  

• Проблема откидывания невалидных ивентов для обновления данных.  

• Атомные часы используются для синхронизации изменений в распределенной системе.  

• Вопрос о доверии метке атомных часов на клиенте.  

• Задача византийских генералов для защиты от подделок.  

• Спейс-бейс архитектура применима в облачных, премиальных и гибридных средах.  

• Задачи: линейное масштабирование, приближение контента к пользователю, стейт-фул системы.  

• Проблемы консистентности и коллизий при большом количестве апдейтов.  

• Спейс-бейс архитектура: кэш базы данных под ногами апликейшена, слой для обновления и записи данных.  

• Совместная фотография с приглашенным гостем.  

• Обсуждение гибридных форм спейс-бейс архитектуры.  

• Обсуждение сложных алгоритмов консенсуса.  

• Рекомендация начинать с простых решений в 99% случаев.  

• Если простое решение не работает, выбирать более сложное на основе причин неудачи.  

• Благодарность за живое обсуждение и интересные темы.  

• Благодарность Жене за опыт и участие.  

• Благодарность Коле и всем, кто задавал вопросы и комментировал.  

• Предложение закругляться и пожелание хорошего вечера.