А что, если потребуется сохранить согласованность и отказаться вместо нее от чего-то другого? Итак, для сохранения согласованности каждый узел базы данных должен знать, что у него имеется такая же копия данных, как и у других узлов баз данных. Теперь при разделении, если узлы баз данных не могут связываться друг с другом, они не могут выполнять координацию для обеспечения согласованности. Мы не в состоянии гарантировать согласованность, поэтому единственным вариантом остается отказ от ответа на запрос. Иными словами, мы приносим в жертву доступность. Система согласована и терпима к разделению, или же можно сказать, что она приняла форму CP. В этом режиме сервису придется выработать меры снижения уровня функциональности до тех пор, пока не будет преодолено разделение и узлы баз данных не восстановят синхронизированность.
Обеспечить согласованность нескольких узлов довольно трудно. В распределенных системах сложно найти задачу труднее этой (если таковая вообще сможет найтись). Давайте немного порассуждаем на эту тему. Представим, что нужно прочитать запись из локального узла базы данных. Как узнать, что эта запись не устарела? Нужно обратиться с вопросом к другому узлу. Но мне также нужно попросить узел базы данных не разрешать обновление этой записи до тех пор, пока чтение не будет завершено, иными словами, для обеспечения согласованности нужно инициировать транзакционное чтение между несколькими узлами баз данных. Но люди, как правило, не связываются с транзакционным чтением, не так ли? Оно слишком медленное. Они запрашивают блокировки. Чтение может заблокировать всю систему. Для выполнения этой задачи всем согласованным системам требуется определенный уровень блокировки.
Как уже говорилось, для распределенных систем сбои не должны быть неожиданностью. Рассмотрим транзакционное чтение в наборе согласованных узлов. Я прошу удаленный узел заблокировать заданную запись, как только чтение будет инициировано. Завершаю чтение и прошу удаленный узел снять его блокировку. Но теперь я не могу с ним общаться. Что же произошло? Правильное применение блокировок вызывает серьезные затруднения даже в системе с единственным процессом, а правильно реализовать их в распределенных системах еще сложнее.
Помните, в главе 5 мы говорили о распределенных транзакциях? Основная причина затруднений при их реализации заключалась в проблеме обеспечения согласованности между несколькими узлами.
Обеспечить согласованность между несколькими узлами настолько трудно, что я буду весьма настоятельно рекомендовать при возникновении насущной потребности в этом не пытаться заниматься изобретательством. Лучше подобрать такое хранилище данных или такую службу блокировки, которые предлагают нужные характеристики. К примеру, такое средство, как Consul, которое вскоре будет рассмотрено подробнее, реализует совершенно согласованное хранилище пар «ключ — значение», разработанное для совместного использования конфигурации несколькими узлами. За лозунгом «Друзья не должны позволять своим друзьям писать собственные системы криптографии» должен следовать лозунг «Друзья не должны позволять своим друзьям создавать собственные распределенные согласованные хранилища данных». Если вы полагаете, что вам нужно написать собственное хранилище данных, обладающее свойствами CP, прочитайте сначала все статьи по данной теме, затем получите степень кандидата наук и потом подумайте, стоит ли тратить несколько лет на получение неработающего хранилища. А в это время я воспользуюсь чем-нибудь уже готовым или, что более вероятно, очень постараюсь создать вместо этого системы, обладающие свойствами AP и согласованностью, возникающей по прошествии некоторого времени.
Нам ведь нужно понять, какие два свойства из трех выбрать, не так ли? Мы уже получили приобретающую согласованность по прошествии некоторого времени AP-систему. У нас есть согласованная, но трудная в создании и масштабировании CP-система. Почему не создать еще и CA-систему? Итак, как же нам пожертвовать терпимостью к разделению? Если у системы отсутствует терпимость к разделению, она не сможет запускаться по сети. Иными словами, ей нужно быть единым процессом, выполняемым локально. CA-систем среди распределенных систем просто не бывает.
Каков должен быть правильный выбор: AP или CP? В реальности нужно решать, что от чего зависит. При создании какой-нибудь системы всегда приходится идти на компромиссы. Нам известно, что AP-системы проще поддаются масштабированию и их легче создавать, и мы знаем, что CP-система потребует больших трудозатрат из-за сложностей при поддержке распределенной согласованности. Но мы можем не понимать влияния этих компромиссов на бизнес. Подойдет ли для системы инвентаризации пятиминутная задержка с обновлением записи? Если ответ положительный, то выбор будет за AP-системой. А как насчет сведений о балансе клиента банка? Могут ли они быть устаревшими? Без знания контекста, в котором используется операция, мы не можем решить, как правильно поступить. Осведомленность о существовании теоремы CAP просто помогает понять, что такие компромиссы существуют, и разобраться в том, какие вопросы следует задавать.
Не обязательно, чтобы вся наша система была либо AP, либо CP. Каталог может быть AP, поскольку в случае с ним нас не особо волнует устаревшая запись. А вот насчет сервиса инвентаризации может быть принято решение о его принадлежности к CP, поскольку мы не собираемся продавать клиенту отсутствующий товар, а затем приносить ему извинения.
Но даже отдельные сервисы не обязательно должны быть либо CP, либо AP.
Подумаем о сервисе остатка бонусных баллов, в котором сохраняются записи о количестве полученных клиентами бонусных баллов. Можно решить, что устаревание сведений об остатке этих баллов, демонстрируемых клиенту, нас особо не волнует, но что делать, когда речь пойдет об обновлении остатка и обязательном поддержании согласованности, чтобы убедиться в том, что клиенты не воспользовались большим количеством баллов, чем им было доступно? К какому из типов отнести этот микросервис: CP, AP или же сразу к обоим? Вообще-то мы сделали следующее: применили компромиссы теоремы CAP к отдельным возможностям сервиса.
Еще одна сложность заключается в том, что ни согласованность, ни доступность не должны рассматриваться как либо все, либо ничего. Многие системы допускают куда более тонкие компромиссы. Например, применяя такое средство, как Cassandra, я могу идти на различные компромиссы для отдельных вызовов. Поэтому, если мне требуется строгое соблюдение согласованности, я могу выполнить чтение, ставящее блокировку до тех пор, пока не ответят все реплики, или пока не ответит определенный кворум реплик, или даже пока не ответит отдельный узел. Понятно, что, если в ожидании обратного отчета от всех реплик одна из них окажется недоступна, блокировка будет сохраняться довольно долго. Но если меня устроит простой кворум узлов, приславших отчет, для меня может быть приемлемо частичное отсутствие согласованности, которое поможет стать менее уязвимым к недоступности отдельной реплики.
Вам будут часто попадаться сообщения о людях, которым удалось обойти теорему CAP. Это неправда. Все, что им удается сделать, заключается в создании системы, где некоторые возможности относятся к категории CP, а некоторые — к AP. Математическое доказательство, подкрепляющее теорему CAP, остается незыблемым. Несмотря на неоднократные мои попытки обойти математику в школе, я понял, что сделать это невозможно.
Многое, о чем мы говорим, относится к миру электроники — битам и байтам, сохраненным в памяти. Мы говорим о согласованности в какой-то манере, похожей на детские рассуждения. Мы представляем себе, что в пределах видимости созданной нами системы мы можем остановить мир и считаем, что во всем этом есть смысл. И еще многое из того, что мы создаем, — это просто отражение реального мира, и мы не в состоянии этим управлять, не так ли?
Вернемся к системе инвентаризации. Она отображается на физические товарные позиции реального мира. Мы в своей системе подсчитываем количество имеющихся альбомов. На начало дня было 100 копий альбома Give Blood группы The Brakes. Одну мы продали. Теперь у нас 99 копий. Все просто, не правда ли? Но что получится, если при отправке заказа кто-нибудь уронит копию на пол и случайно ее раздавит? Что произойдет? Наша система говорит «99», но на полке 98 копий.
А что, если мы создали нашу систему инвентаризации с прицелом на AP-свойства и впоследствии время от времени вынуждены выходить на контакт с пользователем и сообщать ему, что один из его товаров отсутствует на складе? Станет ли это самым худшим, что может случиться в этом мире? Несомненно, гораздо проще будет создать систему, выполнить ее масштабирование и убедиться в том, что все сделано правильно.
Мы должны признать, что независимо от степени возможной согласованности наших систем и от них самих разобраться абсолютно во всем, что может произойти, невозможно, особенно если мы ведем учет происходящего в реальном мире. Это одна из основных причин, по которой во многих ситуациях AP-системы в конечном счете берут верх. Кроме того что CP-системы сложны для построения, они все равно не в состоянии решить все наши проблемы.
Когда количество микросервисов, находящихся в вашем распоряжении, станет солидным, вы непременно захотите получить сведения о том, где располагается каждый из них. Возможно, вам потребуется узнать, какой из них работает в той или иной среде, чтобы понять, что нужно отслеживать. Может, просто захочется узнать, где находится сервис счетов, чтобы использующие его микросервисы знали, где его найти. Или, может быть, вам просто потребуется упростить оповещение разработчиков — сотрудников организации, чтобы они знали, какие API-интерфейсы доступны, и не изобретали колесо заново. В широком смысле все эти сценарии можно назвать