Как реализовать решение для аутентификации клиента с помощью NoSQL (Cassandra)? - PullRequest
Новая
       13

Как реализовать решение для аутентификации клиента с помощью NoSQL (Cassandra)?

2 голосов
/ 31 октября 2011

В настоящее время я думаю о том, как реализовать аутентификацию для веб-приложения с помощью решения NoSQL.Проблема, с которой я сталкиваюсь, заключается в том, что в большинстве решений NoSQL (например, Cassandra, MongoDB) записи, вероятно, задерживаются.Например, мы пишем на узле A, но не гарантируется, что запись появляется на узле B одновременно.Это логично для подходов, лежащих в основе решений NoSQL.

Теперь одна идея состоит в том, что вы не выполняете вторичных операций чтения (так что все идет поверх мастера).Это, вероятно, будет работать в MongoDB (где у вас фактически есть мастер), но не в Cassandra (где все узлы равны).Но наше приложение работает в нескольких независимых точках по всему миру, поэтому нам нужна возможность мультимастера.

В настоящий момент мне неизвестно решение с Cassandra, где я мог бы обновлять данные и быть уверенным, что последующее чтениедля всех узлов) есть изменение.Итак, как можно построить аутентификацию поверх тех решений NoSQL, где запрос аутентификации (чтение) может появляться на нескольких узлах параллельно?

Спасибо за вашу помощь!

1 Ответ

6 голосов
/ 31 октября 2011

С уважением к Apache Cassandra:

ConsistencyLevel - это перечисление, которое управляет как чтением, так и записью на основе вашего определения схемы. Различные уровни согласованности имеют разные значения в зависимости от того, выполняете ли вы операцию записи или чтения. Обратите внимание, что если W + R> ReplicationFactor, где W - количество узлов, которое нужно заблокировать при записи, а R - количество, которое нужно заблокировать при чтении, у вас будет строго согласованное поведение; то есть читатели всегда будут видеть самые последние записи. Из них наиболее интересным является чтение и запись в QUORUM, что обеспечивает согласованность, в то же время обеспечивая доступность перед лицом сбоев узлов вплоть до половины ReplicationFactor. Конечно, если задержка важнее согласованности, вы можете использовать более низкие значения для одного или обоих.

Это выполняется на стороне приложения. В частности, к вашему вопросу все сводится к тому, как вы проектируете реализацию Cassandra, коэффициент репликации для узлов Cassandra и как ваше приложение ведет себя при чтении / записи.

запись

  • ЛЮБОЙ: убедитесь, что запись была записана как минимум в 1 узел, включая получателей HintedHandoff.
  • ONE: прежде чем отвечать клиенту, убедитесь, что запись была записана как минимум в 1 журнал фиксации реплики и таблицу памяти.
  • QUORUM: убедитесь, что запись была записана в реплики N / 2 + 1, прежде чем отвечать клиенту.
  • LOCAL_QUORUM: Убедитесь, что запись была записана в / 2 + 1 узлы локального центра обработки данных (требуется NetworkTopologyStrategy)
  • EACH_QUORUM: Убедитесь, что запись была записана в / 2 + 1 узлов в каждом центре данных (требуется NetworkTopologyStrategy)
  • ALL: убедитесь, что запись записана во все N реплик, прежде чем отвечать клиенту. Любые не отвечающие реплики не выполнят операцию.

Читать

  • ЛЮБОЙ: не поддерживается. Вы, вероятно, хотите ОДИН вместо.
  • ONE: вернет запись, возвращенную первой репликой для ответа. Проверка согласованности всегда выполняется в фоновом потоке, чтобы исправить любые проблемы согласованности при использовании ConsistencyLevel.ONE. Это означает, что последующие вызовы будут иметь правильные данные, даже если начальное чтение получает более старое значение. (Это называется ReadRepair)
  • QUORUM: запросит все реплики и вернет запись с самой последней отметкой времени, как только будет получено хотя бы большинство реплик (N / 2 + 1). Опять же, оставшиеся реплики будут проверены в фоновом режиме.
  • LOCAL_QUORUM: возвращает запись с самой последней отметкой времени после того, как большинство реплик в локальном центре данных ответили.
  • EACH_QUORUM: возвращает запись с самой последней отметкой времени после того, как большинство реплик в каждом центре обработки данных ответили.
  • ALL: запросит все реплики и вернет запись с самой последней отметкой времени, как только все реплики ответят. Любые не отвечающие реплики не выполнят операцию.
...