Какова цель использования Zookeeper, а не просто баз данных для управления распределенными системами?

Question

Я изучаю Zookeeper, и до сих пор я не понимаю цели его использования для распределенных систем, которые базы данных не могут решить.

Случаи использования, которые я прочитал, реализуют блокировку, барьер и т. Д. Для распределенных систем, когда клиенты Zookeeper читают/записывают на сервер Zookeeper. Невозможно добиться того же путем чтения/записи в базы данных?

Например, в моей книге описывается способ реализации блокировки с Zookeeper, чтобы клиенты Zookeeper, желающие получить блокировку, создали ephemeral znode с последовательным флагом, установленным под номером lock-znode. Затем блокировка принадлежит клиенту, чей дочерний znode имеет самый низкий порядковый номер.

Все остальные примеры Zookeeper в книге снова просто используют его для хранения/извлечения значений.

Кажется, единственное, что отличается от Zookeeper от базы данных/любого хранилища, - это концепция «наблюдателя». Но это можно построить с помощью чего-то другого.

Я знаю, что мой упрощенный вид Zookeeper - это недоразумение. Так может ли кто-нибудь сказать мне, что Zookeeper действительно обеспечивает, что база данных/пользовательский наблюдатель не может?

Answer 1

Я думаю, что вы задаете себе неправильный вопрос, когда пытаетесь выяснить цель Zookeeper, вместо того, чтобы спросить, что Zookeeper может сделать, что «базы данных» не могут сделать (btw Zookeeper также является базой данных) спросите, что Zookeeper лучше, чем в других доступных базах данных. Если вы начнете задавать себе этот вопрос, вы, надеюсь, поймете, почему люди решают использовать Zookeeper в своих распределенных сервисах.

Возьмите эфемерные узлы, например, огромная польза от их использования заключается не в том, что они делают гораздо лучший замок, чем какой-либо другой способ. Преимущество использования эфемерных узлов заключается в том, что они будут автоматически удалены, если клиент потеряет соединение с Zookeeper.

И тогда мы можем взглянуть на теорему CAP, где Zookeeper ближе всего похожа на систему CP. И вы должны еще раз решить, хотите ли вы это сделать из своей базы данных.

tldr: Zookeeper лучше в некоторых аспектах и ​​хуже в других по сравнению с другими базами данных.

Answer 2

Нельзя ли добиться того же путем чтения/записи в базы данных?

Теоретически, да, это возможно, но, как правило, не рекомендуется использовать базы данных для требовательных случаев распределенной координации. Я видел микросервисы, использующие реляционные базы данных для управления распределенными блокировками с очень плохими последствиями (например, тысячи взаимоблокировок в базах данных), что, в свою очередь, приводило к ухудшению отношения DBA-разработчика :-)

Zookeeper имеет некоторые ключевые характеристики, которые делают его хорошим кандидатом для управления метаданными ли приложение

• Возможность масштабирования по горизонтали путем добавления новых узлов в ансамбле
• данных гарантированно будет в конечном счете, в соответствии в течение определенного времени и поставленным.Если клиенты желают этого, возможно иметь строгую согласованность (Zookeeper - это система CP в терминах CAP)
• Гарантия на гарантию - всем клиентам гарантируется возможность чтения данных в том порядке, в котором они были написанное

Все перечисленное может быть достигнуто с помощью баз данных, но только при значительных усилиях клиентов приложений. Также часы и эфемерные узлы могут быть получены с помощью баз данных с использованием таких методов, как триггеры, тайм-ауты и т. Д. Но их часто считают неэффективными или противостоящими.

Реляционные базы данных предлагают надежные транзакционные гарантии, которые обычно бывают дорогостоящими, но часто не требуются для управления метаданными приложений. Поэтому имеет смысл искать более специализированное решение, такое как Zookeeper или Chubby.

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