Comments 6
Хех,
Во первых, де факто многие системы продажи авиабилетов являются распределенными (т.е. дают гарантии eventual consitency), что связано со сложными взаимодейтсвиями разных систем(глобальных интеграторов, локальных систем авиакомпаний, турагенств и тд).
Во вторых, некоторые авиакомпании(особенно в штатах) осознанно делают overbooking(продажи нескольких билетов на одно место), потому что статистически какой то % народа не является на посадку и тогда все хорошо. Если на посадку приходят все, то предлагают деньги желающим за то чтобы "полететь завтра", а если все хотят "полететь сегодня" - рандомно выбирают неудачников и советуют почитать что написано мелким шрифтом в соглашении по покупке билета.
Ну и третьих, оно же главное: принцип CAP был сформулирован 25 лет назад и с той поры лучшие инженеры потратили много сотен тысяч часов для того чтобы этот принцип обойти - и это получилось. Это Cloud Spanner от гугла. Если коротко, то там придумали как выкрутиться и нашли компромис который (почти)гарантирует все 3 свойства CAP в подавляющем числе случаев использования, ослабляю гарантии по Availability с существенными оговорками.
Добрейший вечер!)))
Хм. Очень интересный комментарий. Попробую по пунктам.
1. Здесь на самом деле парадоксальная ситуация. Теоретически они должны выбирать CP, чтобы гарантировать точность данных и избежать продажи одного и того же места нескольким пассажирам. Практически они выбирают AP, чтобы обеспечить высокую доступность и работоспособность в условиях сложных взаимодействий между глобальными и локальными системами. Это как бы не противоречит CAP. Скорее показывает практическое применение.
2. Да, все верно. Многие компании продают билеты сверх лимита на досадку, основываясь на статистике. Здесь двоякая ситуация. С одной стороны бизнес-решение, а с другой можно рассматривать, то фактически является способом адаптации к невозможности обеспечить строгую согласованность в распределённой системе. И демонстрирует, как бизнес-процессы могут дополнять технические решения, чтобы минимизировать последствия ограничений, описанных в теореме CAP.
3. Агась! Но это скорее не опровержение теоремы, а отличная демонстрация, как технологии развиваются. Spanner - отличный пример минимизации ограничений, описанных в CAP. При этом CAP не утверждает, что невозможно достичь всех трех свойств вообще. Теорема говорит, что невозможно гарантировать их одновременно в любых условиях. Spanner достигает всех трех свойств в подавляющем большинстве случаев , но допускает временные потери Availability в экстремальных условиях.
давайте оставим авиакомпании, там все понятно, но по 3му пункту уточню: я нигде не пытался "опровергнуть CAP" - наоборот, в рамках имеющихся ограничений физического мира инженеры придумали как их можно "почти обойти" - и для подавляющего большинства бизнес кейсов можно сказать что "Spanner поборол CAP теорему" - и это будет почти правда с практической точки зрения и оговоркой что относительно небольшая часть данных может быть недоступна относительно короткие промежутки времени.
увы, но цирк давно уехал:
The reality is that CAP is nearly irrelevant for almost all engineers building cloud-style distributed systems, and applications on the cloud... https://brooker.co.za/blog/2024/07/25/cap-again.html
This doesn’t mean the CAP theorem is wrong, just that it’s not particularly practically interesting.
Весь фокус в границах системы. Например, пул Memcache нарушает CAP потому что включает в себя клиента. Но если клиентов больше одного, и клиент не конечный, например, балансировщики, реплики или кеши, то проблема согласования появляется уже между ними. Облака тут не при чем, у multi AZ такие же проблемы.
Бинго!))) Облака, multi-AZ и другие современные технологии не решают проблему CAP, а лишь предоставляют инструменты для её адаптации.
Это ведь не ограничение, которое нужно "обойти", а фундаментальный принцип, который помогает понять, как работают распределенные системы. Но можно минимизировать последствия выбора. Например, с помощью современных технологий)))))
Теорема CAP: почему нельзя иметь все сразу и как аналитик выбирает чем пожертвовать