Я новичок в изучении распределенных систем, и я читал о теореме CAP, меня интересует система AP, такая как Cassandra.
Мой вопрос в том, в каких случаях вы действительно можете пожертвовать согласованностью? По сути, я имею в виду, что отказ от согласованности означает предоставление неточных данных. В каких случаях вы действительно будете использовать хранилище данных AP, такое как Cassandra? Я не могу вспомнить ни одного случая, когда я не хотел бы, чтобы мои чтения были последовательными.
По системе AP я предполагаю, что вы, по крайней мере, нацелитесь на обеспечение возможной согласованности.
Представьте, что вы разрабатываете социальную сеть, в которой у пользователей есть друзья и собственные новостные ленты. Не имеет значения, если фид конкретного пользователя время от времени отстает на пять минут (его список фидов имеет конечную согласованность). Отсутствие 2/3 самых последних обновлений в новостной ленте в этом случае нормально, если эти ленты в конечном итоге появятся. И на самом деле, Facebook построил свою новостную ленту, используя Cassandra.
Представьте себе распределенную систему кэширования хранилища ключей и значений, в которой обновления происходят очень редко. Если операций обновления почти нет, обеспечение строгой согласованности не требуется, поэтому вы можете сосредоточиться на доступности. Случайные промахи кеша (запись ключ-значение еще не заполнена) и запрос к базе данных из-за возможной согласованности должны быть в порядке.
Мой вопрос в том, в каких случаях вы действительно можете пожертвовать согласованностью?
Одним из случаев может быть создание набора данных механизма рекомендаций и его обслуживание с помощью Cassandra. Эти наборы данных, по сути, являются агрегацией многих пользователей для определения моделей покупок/просмотров.
Например: если я добавляю фигурку Рей из «Звездных войн» в корзину, базовый механизм рекомендаций запускает запрос на получение аналогичных результирующих шаблонов покупок на основе других, которые также приобрели фигурку Рей. Запрос возвращает первые 5 результатов поиска продуктов и помещает их в конец страницы.
Эти 5 возвращенных продуктов являются результатом анализа и объединения нескольких тысяч предыдущих покупок. Предположим, что некоторые из этих данных не согласуются друг с другом, что приводит к расхождению в возвращаемых пяти продуктах. Это действительно большое дело?
tl;dr; Настоящий вопрос, который нужно задать; лучше ли получить несколько точный список из 5 рекомендаций по продуктам менее чем за 10 мс, чем получить 100% точный список из 5 рекомендаций по продуктам за 100 мс?
Оба набора результатов помогут увеличить продажи. Но тот, который возвращается достаточно быстро, чтобы не мешать работе пользователя, намного предпочтительнее.
«C» в CAP относится к линеаризуемости, которая является очень сильной формой постоянства, которая вам не нужна большую часть времени.
Линеаризуемость — это гарантия актуальности, из-за которой кажется, что существует единственная копия данных. Как только вы внесете изменения в данные, все последующие операции чтения будут возвращать измененные данные. Такой уровень согласованности стоит дорого и плохо масштабируется. Тем не менее, в некоторых сценариях нам нужна линеаризуемость, а именно.
Когда у вас есть эти варианты использования, вы должны использовать что-то вроде ZooKeeper, etcd и т. д. У Cassandra также есть облегченная транзакция (LWT), которая использует расширение классического алгоритма Paxos для реализации линеаризуемости. Эту функцию можно использовать для тех редких случаев использования, когда необходима линеаризуемость и сериализуемость, но это дорого. И в подавляющем большинстве случаев вас вполне устроит немного более слабая согласованность, чтобы получить лучшую масштабируемость и производительность. Вы обмениваете небольшую согласованность на масштабируемость и производительность.
Некоторые веб-сайты электронной коммерции рассылают клиентам письма с извинениями за то, что они не могут выполнить их заказы. Это связано с тем, что последняя копия продукта была продана более чем одному покупателю из-за отсутствия и линеаризуемости. Они предпочитают иметь дело с этим, а не с неспособностью масштабироваться с клиентской базой и неспособностью отвечать на их запросы в рамках строгих соглашений об уровне обслуживания.
Говорят, что Кассандра обладает настраиваемой консистенцией. Вы можете записывать клики или действия пользователей для анализа. Вы в порядке, если некоторые данные будут потеряны, но вы не можете идти на компромисс с производительностью. Вероятно, вы бы использовали уровень согласованности записи ЛЮБОЙ с включенными подсказками (небрежный кворум).
Если вам нужно немного больше согласованности, вы должны использовать уровень согласованности QUORUM для чтения и записи вместе с подсказками и восстановлением чтения. В подавляющем большинстве случаев все узлы обновляются мгновенно. Даже если один или два узла выйдут из строя, большинство узлов будут иметь данные, а неисправные узлы будут восстановлены, когда они вернутся, используя подсказки, восстановление чтения, восстановление антиэнтропии.
Cassandra особенно полезна в случаях, когда у вас не будет много одновременных обновлений одних и тех же данных. Причина в том, что, в отличие от архитектуры динамо, она не использует векторные часы для разрешения конфликтов между репликами. Вместо этого он использует последние выигрыши при записи (LWW) на основе метки времени. Если временные метки совпадают, используется лексикографический порядок. Поскольку время на узлах не может быть точным даже при наличии NTPD, существует вероятность потери данных, хотя Cassandra предприняла некоторые шаги, чтобы избежать этого, например. временная метка на стороне клиента вместо временной метки на стороне сервера.
Теорема CAP гласит, что при заданном допуске к разделам вы можете выбрать либо доступность, либо согласованность в распределенной базе данных (в любом случае никто не захочет отказываться от допусков к разделам). Поэтому, если вы хотите иметь максимальную доступность, вам придется отказаться от согласованности. Это зависит, конечно, от того, насколько критичен бизнес.
Вы что-то ответили на SO, но ответ не отображается при посещении страницы? Можно терпеть. ТАК вниз? Не может быть. Важнейшие финансовые системы скорее будут иметь сильную согласованность, чем доступность. Время от времени серверы моего банка отключались, когда я пытался совершить платеж.
Обычно вы выбираете доступность и конечную согласованность. Ответ, который вы написали в SO, в конечном итоге появится.
Помимо упомянутых выше случаев, когда противоречивые данные допустимы, существуют также сценарии, в которых мы можем отложить решение проблемы несогласованности на пользователя.
Например, если мы нашли в базе данных две разные версии чьего-то адреса, мы можем предложить пользователю идентифицировать правильный адрес.
