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

Проектирование системы: векторные часы и взлом причинно-следственной истории.

Помните вчерашний 19-й день (протокол сплетен), когда мы позволили нашим серверам обмениваться данными и «сплетничать» без главного сервера? Это было отлично для масштабируемости. Но вот в чем ужасная ловушка: что произойдет, если два сервера услышат совершенно разные вещи в одну и ту же миллисекунду? Добро пожаловать на 20-й день «100 дней проектирования систем». Присаживайтесь, потому что сегодня я предупреждаю вас об одной из самых опасных архитектурных ловушек в распределенных системах: доверии к часам. Проблема «Время — ложь» 🤥 Проверка реальности: мы не можем доверять настенным часам. Представьте себе нашу яркую минималистичную векторную графику: светящийся зеленый циферблат часов внезапно дергается и начинает вращаться в обратную сторону. В распределенной системе серверные часы сбиваются. Даже с протоколом сетевого времени (NTP) они никогда не синхронизируются идеально. Если вы используете принцип «Последняя запись побеждает» на основе метки времени для разрешения конфликтов данных, вы случайно удалите данные ваших пользователей. Время — ложь. Конфликт корзин покупок 🛒 Давайте рассмотрим этот кошмар. Пользователь добавляет «Обувь» в корзину на своем телефоне (на сервер A). Сразу же он добавляет «Рубашку» на своем iPad (на сервер B). Внезапно возникает состояние гонки. Представьте себе два пульсирующих синих сервера, держащих два разных светящихся чека. Они яростно спорят о том, чья корзина самая новая. Поскольку внутренние часы сервера A отстают на 2 секунды, метка времени сервера B выглядит новее, поэтому она полностью перезаписывает метку сервера A. Обувь просто исчезает из базы данных. Решение: Векторные часы 🧬 Как это исправить? Мы полностью отбрасываем время. Вместо этого мы используем векторные часы. Представьте, что данные помечены маленьким неоновым штрихкодом, который отслеживает всю историю ДНК. Каждому фрагменту данных присваивается массив счетчиков, например [Сервер A: 1, Сервер B: 0]. Каждый раз, когда сервер обновляет данные, он увеличивает свой собственный счетчик. Разрешение конфликтов на стороне клиента 📱 Неожиданный поворот: когда база данных сталкивается с конфликтом, она не пытается угадать. Она не удаляет данные. Она сохраняет обе версии как «родственные» и передает их обратно клиентскому приложению (телефону пользователя). Она заставляет клиента объединить обувь и рубашку при следующем чтении. Данные сохраняются. Теперь мы можем разрешать конфликты, не полагаясь на время. Но, говоря о генерации чисел... как нам присвоить уникальный идентификатор миллиарду твитов в секунду без наложений? Завтра, День 21, мы создадим Twitter Snowflake. Подписывайтесь! 👇 Ссылки: «Проектирование ресурсоемких приложений» Мартина Клеппмана #ПроектированиеСистем #ВекторныеЧасы #РаспределенныеСистемы #БэкендИнженерия #АрхитектураПрограммногоОбразования #DDIA #ВременнаяСогласованность #ТехническоеИнтервью #100ДнейПроектированияСистем #КонфликтДанные