Backend Notes 🧠 👨‍💻

🔥 CAP-теорема📍 Теорема CAP утверждает, что распределенная система не может одновременно обеспечивать более двух из этих трех гарантий: (C)onsistency – согласованность, во всех серверах в один момент времени данные не противоречат друг другу.(A)vailability - доступность, любой запрос к системе завершается корректным откликом, однако, без гарантии, что ответы всех серверов системы совпадают.(P)artition Tolerance - устойчивость к разделению, разделение системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.🔨 Грани треугольника:PA – в случае сетевого разделения узлов системы она продолжает отвечать на запросы, при этом не гарантируя согласованности данных. Примеры: Cassandra, CouchDB.PC – в случае сетевого разделения узлов системы она прекращает отвечать на запросы, данные остаются согласованными. Примеры: MongoDB, Redis.CA – в случае отсутствия сетевого разделения данные доступны и согласованы. Примеры: MySQL, Postgres.🆘 Latency(время ответа на запрос)Если в кластере из 10 узлов «погибает» 9, то оставшийся мастер не сможет обслужить всех пользователей с удовлетворительным latency.✅ PACELC-теорема, расширение CAP-теоремы.IF P THEN (A or C) ELSE (L or C)В случае сетевого разделения (P) в распределенной системе необходимо выбирать между доступностью (A) и согласованностью (C), как и в CAP- теореме, но в остальном (E, ELSE), даже при нормальной работе системы без разделения, нужно выбирать между задержкой (L) и согласованностью (C).🛠️ Грани ромба:PA/EL – высокая доступность (A) при разделении (P) системы, иначе (E) высокая скорость ответа (L). Примеры: Cassandra.PC/EC – согласованность (С) при разделении (P) системы, иначе (E) согласованность (С). Примеры: MySQL, Postgres.PC/EL – согласованность (С) при разделении (P) системы, иначе (E) высокая скорость ответа (L). Примеры: PNUTS.PA/EC – высокая доступность (A) при разделении (P) системы, иначе (E) согласованность (С). Примеры: MongoDB.CAP vs PACELCCAP and Consistency#databa

🔥 Consistent Hashing 💡 Хеш-таблица - структура данных, которая обеспечивает быстрый доступ к объектам по их ключам. Ключи проходят через хеш-функцию, которая преобразует их в индексы для доступа к данным в таблице. 1⃣ Distributed hashing (распределенное хеширование)Если хеш-таблица большая, ее можно разнести по нескольким серверам (шардам). 📌 У нас N серверов, на какой сервер попадут данные?✅ server_index = hash(key) mod NХеш-функция преобразует key в число, от которого берется остаток от деления на N.В результате мы получаем индекс сервера, который будет хранить данные по ключу key. 📌 Что будет, если мы захотим увеличить/уменьшить кол-во серверов?🆘 В данном случае нужно будет снова перехешировать все данные, что бы с измененным N разложить их по серверам. 2⃣ Consistent Hashing (последовательное хеширование) – улучшение распределенного хеширования. Key получает позицию в хеш-кольце. Мы можем масштабировать сервера, перехешируя меньшее количестово данных, в идеале только с соседних серверов. ⚙ Допустим сервера и данные располагаются на окружности - минимальный угол 0, максимальный 360. data = {server1, ..., serverN, key1, ..., keyM} position_on_ring = hash(data[i]) mod 360 📌 У нас N серверов, на какой сервер попадут данные?✅ Используем правило - двигаемся по часовой стрелке и берем первый найденный сервер.Например, если у нас есть отсортированный по position_on_ring список серверов, найти следующий можно с помощью бинарного поиска. 📌 Что будет, если мы захотим увеличить/уменьшить кол-во серверов?✅В среднем будет перераспределено только M/N данных 📌 Как поддержать равномерное распределение данных в последовательном хешировании?✅ Каждый физический сервер, может быть представлен несколькими виртуальными серверами на хеш-кольце. Чем больше виртуальных серверов, тем более равномерно распределены данные по ним. Однако для хранения данных о виртуальных серверах требуется больше места. Подробнее о хешированииConsistent hashing в Cassandra#consistent_hashing#hashing

Backend Notes 🧠 👨‍💻 pinned «🎤 Вебинар × ArchDays Ребят, нас уже около 2к, это круто, спасибо вам! 🎉🎉🎉 Приглашаю всех на вебинар "Проектирование БД: от NF к денормализации данных". Расскажу о том, с чем я столкнулся с ростом проекта относительно Базы Данных. Приходите, задавайте вопросы…»

🎤 Вебинар × ArchDaysРебят, нас уже около 2к, это круто, спасибо вам! 🎉🎉🎉Приглашаю всех на вебинар "Проектирование БД: от NF к денормализации данных".Расскажу о том, с чем я столкнулся с ростом проекта относительно Базы Данных.Приходите, задавайте вопросы 😊🗓 Когда: 1 августа(вторник) в 19:00 по Мск📍Регистрация: https://archconf.ru/meetup_01082023Вход свободный :)Запись будет в youtube :)💡 Возможно у вас есть предложения по темам для контента, пишите в комменты ⬇️#webinar#archdays

🔥 Rate LimitingRate Limiting — это стратегия ограничения сетевого трафика. Устанавливается ограничение на то, как часто кто-то может повторять запросы в течение определенного периода времени. Например, если мы выставляем какое-то внешнее API и хотим ограничить RPS для пользователей, чтобы предотвратить DDoS (Distributed Denial-of-Service). 🛡️ Запросы сверх ограничения (квоты) могут быть отклонены с ошибкой "429 Too Many Requests".⚙️Алгоритмы, по которым может работать Rate Limiter, допустим, квота 20 запросов в минуту.1️⃣ Fixed Window Counter - задается фиксированное временное окно, например, 1 минута, и считается кол-во запросов от пользователя за этот период. Если кол-во запросов превышено, отдается 429 ошибка.🆘 Возможна проблема между 2:00:00 и 2:01:00 было 20 запросов, и между 2:01:00 и 2:02:00 тоже 20 запросов => между 2:00:30 и 2:01:30 может быть 40 запросов.2️⃣ Sliding Window Log - время запросов хранится в логах. Когда приходит новый запрос, нужно проверить в логах кол-во запросов за последнюю минуту.🆘 Потребление памяти для логов.3️⃣ Sliding Window Counter - вычисление взвешенного счетчика для предыдущего временного окна. Например, между 2:00:00 и 2:01:00 было 10 запросов, в текущем окне уже есть 5 запросов, в 2:01:18 приходит еще один запрос: 5 + 10 * (1 - 18/60) = 12 запросов за прошедшую минуту => запрос разрешен.🆘 Предполагается равномерное распределение запросов => не устойчивость к всплескам.4️⃣ Token Bucket - используем корзину (bucket) для хранения токенов. Изначально корзина заполнена токенами, в нашем случае, 20 токенов. Каждый запрос потребляет один токен. Когда приходит новый запрос, мы проверяем, достаточно ли токенов в корзине. Если токенов нет, запрос отклоняется. С определенной скоростью пополняем корзину токенами.🆘 Токены могут накопиться при простое системы, и дальше может случиться всплеск нагрузки.5️⃣ Leaky Bucket - когда приходит новый запрос, он попадет в очередь (корзину) FIFO (first-in-first-out) и ожидает там. Запросы извлекаю

🔥 Логи, Метрики, CI/CD 1️⃣ Logging - это запись (обычно хронологическая) событий, которые происходят в системе. Мониторинг логов важен, поскольку помогает выявлять ошибки, проблемы и узкие места (bottleneck) в системе. Вы можете отслеживать журналы ошибок…🎤🔥 Ребят, в продолжение темы про метрики, я написал статью на habr "Как из метрик Prometheus построить график Latency" ⚙ Будет полезно тем, кто еще не строил метрики из Prometheus, а так же тем, кто хочет понять как их интерпретировать :)#prometheus#metrics

🔥 Шардирование БДШардирование (sharding) - это подход к хранению данных, при котором данные разбиваются на более мелкие части, называемые шардами. Каждый шард использует одну и ту же схему, хотя фактические данные в каждом шарде уникальны для шарда. Шард может быть размещен на разных физических/виртуальных машинах.⚙️ На первой картинке показано как данные размещаются в шарды на основе идентификаторов пользователей, с использованием хеш-функции: user_id % 4. Допустим, мы хотим вставить новую запись со значением user_id = 123, эта запись попадет в шард №3, так как 123 % 4 = 3.🗝️ Ключ шардирования определяет, как данные должны быть распределены между шардами. В данном примере, ключ шардирования - user_id. Однако, ключ может быть и составным. Ключ шардирования позволяет эффективно извлекать и изменять данные, направляя запросы к нужному шарду. В идеале ключ шардирования должен равномерно распределять данные по шардам.‼️ Если запрос не содержит ключ шардирования для определения шарда => придется обходить все шарды - это долгий и ресурсоемкий запрос.⬇️ Возможные проблемы шардирования ⬇️1️⃣ Resharding данных: resharding данных необходим, когда шард переполняется из-за быстрого роста, удаляется или добавляется новый шард.📌 Например, Сonsistent hashing (хеш-кольцо, перераспределение данных происходит между соседями), широко используется для решения этой проблемы.2️⃣ Проблема знаменитостей: чрезмерный доступ к определенному шарду может привести к перегрузке сервера. Представьте, что данные популярных блогеров попадают в один и тот же шард => перегруженность операциями чтения. 📌 Чтобы решить эту проблему, нам может понадобиться выделить шард для каждой знаменитости.3️⃣ JOIN и денормализация. После того, как база данных была разделена на несколько шардов, трудно выполнять операции соединения (JOIN) между шардами. 📌 Распространенным обходным путем является денормализация базы данных, чтобы запросы можно было выполнять в одном шарде.⬇️ А как бы вы решили эти проблемы? ⬇️#dat

🔥 Downtime budget📌 Высокая доступность (High availability) — это способность системы непрерывно работать в течение длительного периода времени.Высокая доступность измеряется в процентах, где 100 % означает, что система имеет 0 простоев.📌 Время простоя (downtime) — интервал с момента неработоспособности сервиса до момента возобновления его работы.⚙️ Время простоя прописывается в соглашении об уровне предоставления услуг — SLA (Service Level Agreement).ℹ️ Например, если SLA равен 99%, простой может быть не более 7,5 часов в месяц.⬇️ Как это вычисляется? ⬇️100% - 99% = 1% 1% * 365 = 3.65 дня в год3.65 / 12 = 0.3 дня в месяц = 0.3 * 24 часа = 7.5 часа в месяц#high_availability

🎤🔥 Ребят, у нас прошел вебинар "Распределенные транзакции в System Design".Спасибо всем, кто пришел, для тех, кто пропустил ниже запись ❤️👀 Запись:https://youtu.be/yURJjz_1oL8💡 Ваш фидбек: https://forms.gle/2AY4ZCtmtZmY5w3p7

🎤 Вебинар Ребят, нас уже около 1к, это круто, спасибо вам! 🎉🎉🎉 Приглашаю всех на вебинар "Распределенные транзакции в System Design". Расскажу о паттерне Saga на примере задачи "бронирование номера в отеле". Приходите, задавайте вопросы, после вебинара…Напоминаю, у нас сегодня открытый вебинар)https://us06web.zoom.us/j/84795030681?pwd=clNnUGdITmdOQ1VxOUZTcHh5RjRpdz09

🔥 Логи, Метрики, CI/CD1️⃣ Logging - это запись (обычно хронологическая) событий, которые происходят в системе. Мониторинг логов важен, поскольку помогает выявлять ошибки, проблемы и узкие места (bottleneck) в системе. Вы можете отслеживать журналы ошибок на уровне каждого сервера или использовать инструменты для их объединения в централизованную службу для удобного поиска и просмотра.Можно выделить уровни логирования:🆘 ERROR - в программе произошла ошибка⚠️ WARN - предупреждение перед критической ошибкой✅ INFO - общая информация о выполнении программы🛠️ DEBUG - детальная информация для отладкиСобирать логи можно с помощью ETL (Extract, Transform, Load) инструмента - Logstash, а хранить например в БД ClickHouse/ElasticSearch.2️⃣ Metrics - это количественные показатели, используемые для измерения и оценки работы системы.⚙️ Push-модель – когда сервер мониторинга ожидает подключений от агентов* для получения метрик;🔩 Pull-модель – когда сервер мониторинга сам подключается к агентам мониторинга и забирает данные;*Агент – ПО, которое выполняет сбор метрик от приложения.Есть три популярных методологии:📌 Метод 4 golden signals (из книги о SRE в Google): задержка, трафик, ошибки, насыщение (Latency, Traffic, Errors, Saturation).📌 Метод USE (придуманный Бренданом Греггом): использование, насыщение, ошибки (Utilization, Saturation и Errors).📌 Метод RED (придуманный Томом Уилки): частота запросов, ошибки, длительность (Rate, Errors, Duration).Подробнее про 4 golden signalsСобирать метрики можно с помощью Prometeus/VictoriaMetrics и визуализировать в Grafana.3️⃣ Автоматизация. CI (continuous integration) - обеспечение последовательного и автоматизированного способа сборки, упаковки и тестирования приложений.CD (continuous delivery) - автоматизация развертывания приложений в различные окружения.Для реализации CI/CD пайплайнов можно использовать Jenkins или встроенные в github/gitlab инструменты.Google SRE bookGoogle SRE workbook#monitoring#observability

🔥 А что, если очередь сообщений уйдет в offline? 🆘⚙️ Допустим, у нас есть требование по высокой доступности (high availability), а наша очередь сообщений ушла в offline, а мы хотим писать в нее, что делать? :)⬇️ Мой вариант решения ⬇️Реализуем паттерн Outbox - сохранение сообщений в хранилище данных (как правило, в таблице outbox в базе данных), прежде чем они будут в конечном итоге переданы в брокер сообщений. Если бизнес-объект и соответствующие сообщения сохраняются в рамках одной транзакции базы данных, это гарантирует, что данные не будут потеряны. Либо будет зафиксировано все, либо при возникновении ошибки произойдет полный откат.Фоновый воркер может читать табличку outbox и пытаться отправить сообщения в очередь. После отправки можно удалять отправленные сообщения из таблицы, что бы она не разрасталась.Подробнее про OutboxА как бы сделали вы, пишите в комменты!)#queue#challenge

Backend Notes 🧠 👨‍💻 pinned «🎤 Вебинар Ребят, нас уже около 1к, это круто, спасибо вам! 🎉🎉🎉 Приглашаю всех на вебинар "Распределенные транзакции в System Design". Расскажу о паттерне Saga на примере задачи "бронирование номера в отеле". Приходите, задавайте вопросы, после вебинара…»

🎤 Вебинар Ребят, нас уже около 1к, это круто, спасибо вам! 🎉🎉🎉Приглашаю всех на вебинар "Распределенные транзакции в System Design".Расскажу о паттерне Saga на примере задачи "бронирование номера в отеле".Приходите, задавайте вопросы, после вебинара можем пообщаться в zoom'е 😊🗓 Когда: 5 июля(среда) в 19:00 по Мск📍Регистрация: https://backend-notes.timepad.ru/event/2485224Вход свободный :)💡 Возможно у вас есть предложения по темам для контента, пишите в комменты ⬇️#webinar

🔥 Очереди сообщений При синхронном взаимодействии между компонентами отправитель ожидает ответа от получателя перед тем, как продолжить свою работу. Например, мы делаем HTTP-запрос и ждем ответа от веб-сервера. Допустим, мы запускаем процесс каких-то долгих вычислений (потребление mem/cpu), в этом случае HTTP-запрос зависнет в ожидании ответа. ⚡️ Если наша система чувствительна ко времени ожидания запроса (latency), то можно вынести долгие вычисления в отдельный компонент (воркер) и взаимодействовать с ним через очередь – асинхронно для конечного пользователя. А так же мы можем независимо масштабировать этот компонент :) Схема очереди на картинке, допустим наша тяжелая работа – преобразование фото.📍 Producer – тот, кто пишет сообщения в очередь📍 Consumer – тот, кто читает сообщения из очереди Гарантии доставки сообщений в очередях:1⃣ At-most-once delivery (“как максимум однократная доставка”). Это значит, что сообщение не может быть доставлено больше одного раза. При этом сообщение может быть потеряно.2⃣ At-least-once delivery (“как минимум однократная доставка”). Это значит, что сообщение никогда не будет потеряно. При этом сообщение может быть доставлено более одного раза.3⃣ Exactly-once delivery (“строго однократная доставка”). Святой грааль систем сообщений. Все сообщения доставляются строго единожды. ❓ Если нам нужна надежная доставка, можно выбрать «At-least-once delivery», но как защититься от «двойного списания», когда сообщение придет более одного раза?✅ Добавлять в сообщение ключ идемпотентности, который сгенерирован отправителем => если сообщение будет задублировано, мы можем понять что это одно и тоже сообщение по ключу и не обрабатывать его повторно.⚙ Реализации очередей: rabbitmq, kafka, nats и т.д. Сравнение очередей #queue