on etcd
Я опять наткнулся на https://github.com/coreos/etcd (легкий Zookeeper, написанный на гошечке) и считаю нужным сказать.
Программисты давно в большинстве своем обленились. Идея тонкого клиента настолько разъела мозг, что думать об уместности никто не хочет. Мы хотим http-api (желательно REST), потому что вдруг мне понадобится распределенный кластер из javascript-страниц, а вся сложная логика пусть будет в серверной части библиотеки.
(на самом деле, конечно, http берут не от хорошей жизни, а от того, что tcp неудобный, а zeromq слишком маргинальный и тоже не без проблем, а больше ничего универсального как-то и нет)
Я в принципе не против. Приятно, когда чтобы заиспользовать тот или иной сервер, не нужно никаких зависимостей и клиентских библиотек, достаточно http-клиента. Но только если это _уместно_.
Так вот, consistent distributed storage это как раз тот случай, когда тонким клиентом не обойтись. В распределенной среде даже клиенты - полноценные участники событий, и требуют чего-то более изобретательного, чем long-polling. В самом деле, на кой черт городить огород со всей этой strong consistency, если я не могу достоверно получить последнее значение по ключу?
Если сделать
GET /key
GET /key/watch
то значение может поменяться между вызовами и мы об этом никогда не узнаем.
Если сделать
GET /key/watch
GET /key
(в разных коннекциях, потому что первый вызов блокируется до первого change по ключу), то вообще говоря ответы надо как-то упорядочить, и то что A пришло вперед B не значит, что они именно в таком порядке отправились с сервера.
Да даже банальное переподписывание после того, как выстрелил /key/watch, непонятно как сделать - пока я переподписываюсь, значение того и гляди поменяется.
Я верю, что сервер-сайд у них клевый и алгоритм Raft определенно стоит внимания, но они просто в трубу слили все усилия, постаравшись сделать клиента тупым. У Zookeeper та же проблема.
В правильной реализации клиент должен быть полноценной нодой, работать в пространстве того процесса, который данные из него и потребляет. Понятно, что это означает переписывать для каждого языка заново, но зато это закрывает все вопросы по distributed consistent storage. А если закрывать их не все, то я не вижу смысла даже начинать что-то делать. Используйте БД с master-slave тогда, ничем не хуже.
Программисты давно в большинстве своем обленились. Идея тонкого клиента настолько разъела мозг, что думать об уместности никто не хочет. Мы хотим http-api (желательно REST), потому что вдруг мне понадобится распределенный кластер из javascript-страниц, а вся сложная логика пусть будет в серверной части библиотеки.
(на самом деле, конечно, http берут не от хорошей жизни, а от того, что tcp неудобный, а zeromq слишком маргинальный и тоже не без проблем, а больше ничего универсального как-то и нет)
Я в принципе не против. Приятно, когда чтобы заиспользовать тот или иной сервер, не нужно никаких зависимостей и клиентских библиотек, достаточно http-клиента. Но только если это _уместно_.
Так вот, consistent distributed storage это как раз тот случай, когда тонким клиентом не обойтись. В распределенной среде даже клиенты - полноценные участники событий, и требуют чего-то более изобретательного, чем long-polling. В самом деле, на кой черт городить огород со всей этой strong consistency, если я не могу достоверно получить последнее значение по ключу?
Если сделать
GET /key
GET /key/watch
то значение может поменяться между вызовами и мы об этом никогда не узнаем.
Если сделать
GET /key/watch
GET /key
(в разных коннекциях, потому что первый вызов блокируется до первого change по ключу), то вообще говоря ответы надо как-то упорядочить, и то что A пришло вперед B не значит, что они именно в таком порядке отправились с сервера.
Да даже банальное переподписывание после того, как выстрелил /key/watch, непонятно как сделать - пока я переподписываюсь, значение того и гляди поменяется.
Я верю, что сервер-сайд у них клевый и алгоритм Raft определенно стоит внимания, но они просто в трубу слили все усилия, постаравшись сделать клиента тупым. У Zookeeper та же проблема.
В правильной реализации клиент должен быть полноценной нодой, работать в пространстве того процесса, который данные из него и потребляет. Понятно, что это означает переписывать для каждого языка заново, но зато это закрывает все вопросы по distributed consistent storage. А если закрывать их не все, то я не вижу смысла даже начинать что-то делать. Используйте БД с master-slave тогда, ничем не хуже.