Каждое популярное программное обеспечение должно иметь ограничитель трафика. Это предотвращает DDOS-атаку, снижает затраты и предотвращает перегрузку серверов.
Есть несколько каверзных вопросов, которые необходимо учитывать при внедрении ограничителя трафика:
Где поставить ограничитель трафика: на стороне клиента, на стороне сервера, на шлюзе? Алгоритмы ограничения скорости. Есть много алгоритмов со своими плюсами и минусами: Token Bucket, Leaking Bucket, Fixed window counter, Sliding window log, Sliding window counter. Особенности вашего бизнеса определят правильный алгоритм.
Четыре стандартных этапа собеседования по проектированию ИТ-систем. Однако я бы думал о них шире: как о четырех начальных шагах проектирования любого ПО.
Шаг 1. Понимание проблемы и определение скоупа проектирования Шаг 2. Предложите дизайн высокого уровня и получите одобрение Шаг 3. Спроектируйте глубокое погружение Шаг 4. Завершение Глава 3 книги раскрывает подробности о каждом шаге, хорошие вопросы, которые нужно задать (над которыми следует подумать), а также то, что НУЖНО и НЕЛЬЗЯ делать.
Очень короткая глава 2 посвящена тому, как делать приблизительные оценки, чтобы начать с самых важных моментов при разработке программного обеспечения.
Концепции, которые должен знать КАЖДЫЙ разработчик программного обеспечения:
“Сила двух” Стандартные цифры задержки! Насколько быстрой является память, насколько медленным является диск и т.д. Показатели доступности Про какие ключевые метрики стоит думать Эти понятия и числа раскрыты во второй главе книги:
“System Design. Подготовка к сложному интервью” Алекса Сюй.
Отличный общий план для масштабирования любого приложения с нуля до миллионов пользователей.
Настройка одного сервера Выбор и использование базы данных Вертикальное масштабирование против горизонтального масштабирования подходов. И почему вы должны предпочесть горизонтальный Добавлен балансировщик нагрузки для горизонтального масштабирования Добавление репликации базы данных для горизонтального масштабирования Добавление кеша Добавление CDN Архитектура без сохранения состояния и с сохранением состояния и использование внешнего хранилища состояния Добавление дополнительных центров обработки данных Добавление очереди сообщений Добавление ведения журнала, метрик и автоматизации Масштабирование базы данных и дальнейшие шаги… Все это тщательно, но кратко раскрыто в Главе 1 книги:
Принципы развертывания микросервисов Различия между непрерывной интеграцией (CI), непрерывной доставкой и непрерывным развертыванием. Шаблоны развертывания:
Базовый шаблон полного развертывания Шаблон непрерывного обновления Паттерн изменения схемы прерывания: здесь два варианта - окончательная миграция и синхронизированная миграция. Сине-зеленый шаблон развертывания Все это раскрыто в главе 16 книги:
“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare
Делюсь своей ментальной картой со всеми подробностями, как обычно:
Тестирование событийно-ориентированных решений — сложная задача. Это включает в себя:
Общие принципы Модульное тестирование: без сохранения состояния и с сохранением состояния Тестирование топологии (держу пари, вы этого не делали! ;) Тестирование эволюции схемы и совместимости Интеграционное тестирование: локальное, удаленное и гибридное - набор соображений здравого смысла, о которых нельзя забывать. Выбор стратегии тестирования Все это раскрыто в главе 15 книги:
“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare
Довольно часто инструменты забывают в начале разработки. В этой главе не рассматриваются инструменты, помогающие создавать и поддерживать управляемые событиями микросервисы. Полезный чек-лист! Эта тема включает в себя:
Правила организации Документация, маркировка Квоты Схема реестра Управление смещением список контроля доступа Управление состоянием и сброс приложения Мониторинг задержки смещения потребителя Элементы управления контейнером Создание кластера и управление им Отслеживание зависимостей Все это раскрыто в главе 14 книги:
“Создание событийно-управляемых микросервисов” Адама Беллемара.
Как интегрировать микросервисы, управляемые событиями, с API-интерфейсами типа «запрос-ответ»?
Существует два типа внешних событий:
Автономно генерируемые события (аналитические события) Реактивно генерируемые события (события от запроса-ответа) Существует два подхода к обработке и обслуживанию запросов с использованием сервисов с отслеживанием состояния:
использование внутренних хранилищ состояний (с глупой или умной маршрутизацией) использование внешних хранилищ состояний (с обычным или с составным микросервисом) Способы обработки запросов в рамках управляемого событиями рабочего процесса:
Четвертый шаблон для создания микросервисов — использование легковесных фреймворков.
Легковесные фреймворки предоставляют функциональность, аналогичную тяжеловесным фреймворкам, но они в значительной степени зависят от:
брокера событий системы управления контейнерами (CMS) Во многих случаях они превосходят тяжеловесные фреймворки.
Различные приложения могут использовать любые/разные ресурсы из кластера, которые лучше соответствуют их потребностям. При этом по-прежнему обеспечивают масштабирование и восстановление после сбоев (опять же, сильно полагаясь на брокера событий и CMS).
К сожалению, на данный момент есть только два полнофункциональных варианта:
Тяжеловесные фреймворки потоковой обработки — это еще одна основа/шаблон для создания микросервисов.
Эти фреймворки обладают высокой масштабируемостью и позволяют эффективно решать множество аналитических задач. Но они не всегда хороши для шаблонов приложений микрослужб с отслеживанием состояния, управляемых событиями.
Тяжеловесные фреймворки работают с использованием централизованных кластеров ресурсов, что может потребовать дополнительных операционных издержек, мониторинга и координации для успешной интеграции в среду микросервисов. Однако недавние инновации двигают эти фреймворки в сторону решений для управления контейнерами (CMS), таких как Kubernetes, которые должны сократить ваши усилия.
Базовой шаблон производителя и потребителя (BPC) — это простой шаблон для создания микросервисов. Он формирует основу сервисов без сохранения состояния и с сохранением состояния.
Вы можете использовать его для:
реализации интерфейса взаимодействия между потоками событий и устаревшими системами использования внешних систем обработки потоков для расширения возможностей Но это требует ваших дополнительных усилий для реализации:
простой материализации состояния скедулинга событий принятия решений на основе временных меток Все это раскрыто в главе 10 книги, которую мы сейчас изучаем:
Функция как сервис (FaaS) — это область облачных вычислений, которая быстро развивается.
Здесь необходимо рассмотреть следующие вопросы:
Принципы FaaS Открытый исходный код и сторонние поставщики FaaS 4 компонента, которые следует учитывать при построении микросервисов как функций Холодный пуск против теплого пуска Различные триггеры, которые могут запускать FaaS: запуск на основе новых событий, запуск на основе задержки группы потребителей, запуск по расписанию, запуск с использованием веб-перехватчиков, запуск по событиям ресурсов. Поддержание состояния Два шаблона функций, вызывающих другие функции: управляемый событиями и прямой вызов.
Существует два шаблона построения микросервисов, управляемых событиями:
Хореография (без централизованной координации) Оркестровка (с централизованной координацией) У обоих есть плюсы и минусы (однако мне кажется, что оркестровка все-таки более удобный шаблон)
Как реализовать распределенные транзакции с хореографией и оркестровкой.
Как ИЗБЕЖАТЬ реализации распределенных транзакций — подход с компенсационным рабочим процессом.
Все это раскрыто в главе 8 книги, которую мы сейчас изучаем:
“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare
Микросервисы, управляемые событиями, должны материализовать состояния. И это связано с важными вещами для размышлений. Два подхода на выбор:
Внутреннее хранилище состояний или внешнее хранилище состояний У обоих есть плюсы и минусы. Оба имеют важные соображения о масштабируемости и восстановлении.
Два подхода к изменению структур данных:
Перестраивать и Миграции Транзакции и как их эмулировать для реализации обработки Ровно Один Раз.
Все это раскрыто в главе 7 книги, которую мы сейчас изучаем:
Детерминированная потоковая обработка — это основа для создания масштабируемых систем, управляемых событиями. Отсутствие детерминизма может быть очень болезненным для бизнеса (представьте себе потерю финансовых транзакций, пропущенные оповещения, неправильную агрегацию данных).
Существуют определенные советы и приемы реализации детерминизма. Ключевые слова здесь:
Временные метки Планирование событий Водяные знаки Время потока Вы должны понимать природу неупорядоченых и запоздалых событий. И стратегии их обработки.
Также необходимо поддерживать повторную обработку.
И нужно учитывать периодические сбои.
Как разговаривать с пользователями при создании стартапа? Какую книгу лучше всего прочитать на эту тему? Три распространенные ошибки, которые совершают все. Пять отличных вопросов, которые вы можете задать в каждом интервью с пользователем. Как разговаривать с пользователями на трех стадиях: стадии идеи, стадии прототипа и стадии запуска.
Обо всем этом рассказывается в Школе стартапов Y Combinator — Урок «Как разговаривать с пользователями».
Как обычно, вот моя сводная ментальная карта:
Скачать полную ментальную карту (PDF)
Основы событийно-управляемой обработки в архитектурах, управляемых событиями:
Типовая структура микросервиса Типовые типы трансформации событий, 2 сценария ветвления, слияние потоков Перепартиционирование событий и когда это может быть полезно Сопартиционирование событий и когда это необходимо Назначение партиций конкретному микросервису занимающемуся обработкой данных. Три стратегии для этого. Восстановление после сбоев микросервисов обработки данных без поддержки состояния. Эти темы раскрыты в главе 5 книги, которую мы сейчас изучаем:
“Создание событийно-управляемых микросервисов” Адама Беллемара.
Освобождение данных — это процесс перехода от монолита к микросервисам путем разделения систем с точки зрения зависимостей данных.
Существуют три паттерна для освобождения данных:
На основе запросов На основе журнала На основе таблиц У каждого паттерна есть свои плюсы и минусы, а также другие важные соображения.
Изменения определения данных (миграция структуры данных) также должны поддерживаться выбранным подходом к освобождению данных.
Существуют различные фреймворки/инструменты, которые упрощают процесс освобождения данных. Обратите внимание, что инструменты CDC не являются конечным пунктом вашей архитектуры, а всего лишь начальным шагом ваших измерений.
Управляемая событиями модель, сильно зависит от КАЧЕСТВА событий.
События хорошего качества:
явно определены через контракты содержат комментарии поддерживают эволюцию с обратной и прямой совместимостью поддерживают генерацию кода ломающие изменения хорошо продуманы События хорошего качества реализуются с помощью правильных инструментов:
используйте форматы Avro/Thrift/Protobuf и никогда не используйте JSON! используйте правильный брокер событий (например, Pulsar) События хорошего качества проектируются так, чтобы:
содержать всю информацию, необходимую потребителям использовать отдельные потоки для каждого типа событий использовать правильные типы данных для своих полей (не используйте строки для чисел, используйте перечисления и т.
Я случайно познакомился с основателями Блокчейна EMPERA. Как вы знаете, несмотря на то, что я верю в будущее блокчейна, я немного скептически отношусь к новым проектам и идеям в этой области, так как есть много чистых мошенников и непрофессиональных энтузиастов.
Однако после прочтения всех статей и глубокого разговора с основателями я очень удивлен этим конкретным проектом. И я хочу поделиться с вами своими мыслями (а также несколькими скептическими неясностями, чтобы быть на 100% честным).
Введение в архитектуру микросервисов, управляемых событиями (EDM), состоит из следующих тем:
две топологии содержание событий три типа событий двойственность таблица-поток схемы для определения данных внутри событий принцип одного писателя функциональные возможности брокера событий брокер событий против брокера сообщений принцип единого источника истины масштабирование с помощью контейнеров и виртуальных машин налог на микросервисы, который мы должны платить Эти темы раскрыты в главе 2 книги, которую мы сейчас изучаем:
“Создание событийно-управляемых микросервисов” Адама Беллемара.
Книжный клуб нашей компании выбрал книгу о микросервисах. Это “Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare
Глава 1 содержит вводную информацию:
Типы архитектур и различия между ними:
Традиционные монолитные архитектуры Сервисно-ориентированные архитектуры (SOA) Архитектуры управляемых событиями микросервисов (EDM) Уровни коммуникативных структур и связанный с ними закон Конвея:
бизнес реализация данные Проблемы с традиционными архитектурами (монолит и SOA), когда вам нужно:
Знаете ли вы, что проиграть 1000 долларов, а затем выиграть 900 долларов (т.е. получить результат -100 долларов в сумме) приятнее, чем выиграть 1000 долларов, а затем проиграть 900 долларов (т.е. получить результат +100 долларов)!??
То, что произошло в НЕДАВНЕМ ПРОШЛОМ, влияет на нашу эмоциональную реакцию гораздо больше, чем на нам общий результат! Это проблема, если вы делаете важный прогноз.
Это продолжение моего предыдущего поста Реальные проекты с Ethereum) — о том, как настроить инфраструктуру разработки вокруг реального смарт-контракта.
Я уже рассказывал о группе поиска правды (Система напарников) как об отличном способе улучшить процесс принятия решений.
Как делиться информацией внутри такой группы и как эффективно не соглашаться (чтобы находить хорошее решение)? И как общаться вне такой эффективной группы?
Люди не готовы считать себя источником проблемы, с которой они столкнулись (свои навыки), они винят в этом других людей/обстоятельства (везение). Как побороть эту проблему?
Одним из решений является создание «группы правды» с вашими коллегами/друзьями/партнерами/«напарниками». И такая группа должна следовать определенным правилам, повышающим рациональность…
Девиз Y Combinator — “Делайте то, чего НУЖНО ЛЮДЯМ”.
Но как найти то, что нужно людям?
Есть семь шагов/соображений, чтобы постепенно приблизиться к ответу…
Как построить сложный смарт-контракт на блокчейне? С какими стандартными проблемами вы столкнетесь с массивами, газом, различными типами переменных, развертыванием контрактов и т.д.? И как их решить?
Какова правильная архитектура приложения, которое должно работать с блокчейном (и чем она отличается от традиционной архитектуры)? Какие библиотеки использовать? Как настроить окружение?
Полезная расширенная информация и техники написания и тестирования смарт-контрактов: основные типы данных, ссылочные типы данных, глобальные переменные, ловушки с динамическими массивами, валидации и модификаторы, отладка, генерация случайных чисел, отправка эфира.
Какие качества важны, чтобы стать отличным коммуникатором? Это харизма или искренность? Или что-то другое? Как определить свои сильные и слабые стороны? И как их использовать?
Какой набор инструментов подходит для разработки под блокчейн? Вот некоторые ключевые слова: nodejs, npm, web3, solc, ganache, mocha, metamask, rinkeby, infura, remix…
Люди должны учиться, наблюдая за результатами, но почему они не учатся?
У результата всегда есть много неизвестных нам обстоятельств - поэтому мы не знаем настоящей причины результата. Удача также часто играет большую роль, поэтому мы часто не знаем что повлияло больше, Удача или Мастерство.
Также нас искажают наши предвзятости:
корыстное предубеждение по отношению к себе
и инвертированное корыстное предубеждение по отношению к другим
Игроки в покер принимают решения делая ставки. Почему и всем нам нужно принимать решения, используя ставки?
Существует ловушка предвзятости «мотивированных рассуждений». И, к счастью, есть фасилитирующие вопросы, которые направляют наш мозг в правильном направлении.
Мы также должны отказаться от использования шкалы уверенности «все или ничего». Вместо этого мы должны научиться измерять нашу уверенность в процентах. Это не только поможет нам выигрывать больше, но также сделает нас более заслуживающими доверия собеседниками и повысит эффективность командной работы вокруг нас.
Почему нужно задавать вопросы во время общения? Какие ошибки мы совершаем в общении?
Два типа вопросов.
Три характеристики хорошего слушателя.
Структура хорошего вопроса. Структура идеального вопроса.
Эта книга написана победителем покерных турниров на миллионы долларров (и ее брат тоже многократный победитель покерных турниров на миллионы долларов - так что это у них семейный бизнес ;))
Она учит применять покерное мышление для принятия решений для финансовых рынков, стратегического планирования, человеческих ресурсов, права, предпринимательства…
В наши дни существует довольно высокий спрос на разработку блокчейна. У нас, как у компании, есть опыт работы с ним (один комплексный многолетний проект), но лично у меня были только высокоуровневые знания, и я хотел их улучшить…
Что лучше — экспертная оценка или механическое предсказание с использованием очень простых моделей/правил? Удивительно, но модель вас лучше вас! Даже простая регрессионная модель, основанная на ваших прошлых решениях!
Как сделать правила/модели еще менее шумными? Как правила/модели могут иногда становиться более предвзятыми?
Почему люди не всегда используют модели (если они так хороши) и по-прежнему полагаются на свои неверные суждения?
Продолжаю делиться свои впечатлением и знаниями из курса Гений Общения, который я начал проходить в январе 2022 года. В третьем уроке вы найдете много полезной информации о ТОСТАХ. Там содержатся конкретные подсказки о том, что сказать, чтобы вас запомнили, и полезные фразы, которые прозвучат уместно в неформальной обстановке за столом.
В январе 2022 года я начал курс Гений Общения от одного из лучших тренеров по публичным выступлениям. Во втором уроке вы найдете подсказки, необходимые для общения в стрессовых ситуациях, когда время на исходе (ELEVATOR PITCH). Там конкретные инструкции о том, что говорить в таких ситуациях, а о чем лучше не упоминать.
Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:
Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения
Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design
👍
Часть VI подрывает некоторые устои 😀:
Вы знаете, что База Данных - это “деталь”? Неважная второстепенная низкоуровневая необязательная функция, которой можно пренебречь при проектировании архитектуры! Вы знаете про Веб тоже самое?
В январе 2022 года я начал курс Гений Общения от одного из лучших тренеров по публичным выступлениям — чтобы быть чуть менее токсичным и более эффективным 🙂
Урок 1 рассказывает:
Какова цель коммуникации?
Какие две половинки для успеха?
Почему вы должны четко определить и записать свою настоящую цель?
Как учесть вашу аудиторию?
Что такое Формат и его элементы: Время, Место, Дресс-код и Жанр и как их использовать?
Как правильно выбрать Момент? Примеры хороших и плохих моментов?
Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:
Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения
Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design
👍
Пятая часть книги содержит МНОГО полезной информации:
Что такое архитектура ПО? Какие типы взаимозависимостей могут существовать? Как провести границы между компонентами? Какие типы границ существуют? Как распределить политики по уровням?
Интересно узнать, как наш разум принимает решения. Два типа решений: прогнозные и оценочные. Как измерить ошибки от предвзятости и шума. Как измерить стоимость шума. И как бороться с катастрофическими последствиями.
Детализация шума до трех компонентов: системный шум, шум уровня и шаблонный шум. Как измерить (и компенсировать) шумы. Случайный шум как часть шаблонного шума. Как компенсировать случайный шум: эффект мудрости толпы, эффект толпа-в-одном, эффект второго ответа и инструмент диалектической самонастройки.
Как групповая работа влияет на шум. Информационный каскад и каскад социального давления. Как с ними бороться. Эффект групповой поляризации.
Вы осознаете, насколько серьезно на вашу организацию влияют неверные решения? В человеческих суждениях есть два типа ошибок: предвзятость и шум. Предвзятость - очень широко известная проблема, и вы наверняка слышали о ней. А шум не так широко известен. Тем не менее, он влияет на МНОГИЕ решения во ВСЕХ отраслях.
В государственных решениях очень много шума. В коммерческих компаниях очень много шума.
Шум можно сделать видимым и уменьшить. Сложнее измерить шум в уникальных единичных решениях, но он все равно там присутствует и его тоже можно уменьшить.
Ранее книжный клуб нашей компании изучил отличную книгу:
Martin Kleppmann - Designing Data-Intensive Applications
Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка
Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪
Как обычно, я подготовил краткий обзор и майнд-мапу.
Глава 12 - это саммари книги и визионерский взгляд на будущее.
Интеграция данных. Обзор способов интеграции данных. Причинность и зачем нам нужен тотальный порядок и идемпотентность.
Ранее книжный клуб нашей компании изучил отличную книгу:
Martin Kleppmann - Designing Data-Intensive Applications
Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка
Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪
Как обычно, я подготовил краткий обзор и майнд-мапу.
Глава 11 раскрывает все аспекты потоковой обработки. Если вашей системе необходимо обрабатывать некоторые данные на лету, ваша команда разработчиков должна изучить эту информацию.
Ранее книжный клуб нашей компании изучил отличную книгу:
Martin Kleppmann - Designing Data-Intensive Applications
Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка
Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪
Как обычно, я подготовил краткий обзор и майнд-мапу.
Глава 10 раскрывает все аспекты пакетной обработки больших данных. Если вашей системе необходимо обрабатывать данные, ваша команда разработчиков должна изучить это.
Инструменты Unix для пакетной обработки и блестящей концепции пайпов.
Ранее книжный клуб нашей компании изучил отличную книгу:
Martin Kleppmann - Designing Data-Intensive Applications
Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка
Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪
Как обычно, я подготовил краткий обзор и майнд-мапу.
В главе 9 рассказывается о согласованности и консенсусе в распределенных системах. Она охватывает следующие темы:
Что такое согласованность и согласованность в конечном счете.
Ранее книжный клуб нашей компании изучил отличную книгу:
Martin Kleppmann - Designing Data-Intensive Applications
Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка
Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪
Как обычно, я подготовил краткий обзор и майнд-мапу.
В главе 8 раскрываются проблемы распределенных систем, не связанные с базами данных. Команды разработчиков должны учитывать их при разработке распределенного программного обеспечения.
Неисправности и частичные отказы.
Ранее книжный клуб нашей компании изучил отличную книгу:
Martin Kleppmann - Designing Data-Intensive Applications
Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка
Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪
Как обычно, я подготовил краткий обзор и майнд-мапу.
Глава 7 - это все, что ваша команда разработчиков должна знать о транзакциях:
Предназначение транзакций Концепция транзакций: ACID, BASE, одно-объектные и много-объектные транзакции.
Ранее книжный клуб нашей компании изучил отличную книгу:
Martin Kleppmann - Designing Data-Intensive Applications
Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка
Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪
Как обычно, я подготовил краткий обзор и майнд-мапу.
Глава 6 содержит все, что следует учитывать команде разработчиков при проектировании хранилища для больших данных:
Партиция, она же шард, она же регион, он же tablet, она же vNode, она же vBucket.
Ранее книжный клуб нашей компании изучил отличную книгу:
Martin Kleppmann - Designing Data-Intensive Applications
Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка
Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪
Как обычно, я подготовил краткий обзор и майнд-мапу.
Глава 5:
Вступление. Как масштабировать приложения. Репликация и партиционирование. Три алгоритма репликации Репликация с одним лидером Лидеры и последователи Синхроная и асинхронная репликация Добавление новых последователей Обработка перебоев в работе узлов Технические реализации и все возможные проблемы Многолидерная репликация Случаи использования, когда это хорошо Обработка конфликтов на запись Три топологии и потенциальные проблемы Репликация без лидера Запись в базу данных, когда узел не работает Кворумы и проблемы с ними Обнаружение одновременных записей и способы разрешения конфликтов Скачать всю майнд-мапу в PDF
