Comments 20
Команда sync всё портит, как мне кажется. Насчёт WTF #4 непонятно — так можно вызывать getData для получения правильных данных?
Можно, но осторожно)
Допустим, что у нас есть два клиента — A и B, и где-то в один момент времени A решил изменить данные, а B прочитать. Если B не знает, что данные изменились, то нет никакой разницы получит он старые данные или новые, но если он ожидает получить новые могут быть проблемы. Как B может узнать?
В первом случае B получит правильные данные, из-за гарантий zk о том, что если клиенту пришло событие об изменении данных, то запрашивая данные он должен получить новую версию. Во-втором случае тоже будут новые данные из-за глобального порядка — если мы видим новые данные у одного znode, то мы гарантировано видим все изменения, которые были сделаны до него. В ситуации 3 у нас нет гарантий, поэтому, как поведет.
На самом деле, опыт показал, что такое поведение не большая проблема. Кстати в конфиге ZooKeeper можно указать максимальное время за которое должна происходить синхронизация узлами кластера и лидером (syncLimit).
Допустим, что у нас есть два клиента — A и B, и где-то в один момент времени A решил изменить данные, а B прочитать. Если B не знает, что данные изменились, то нет никакой разницы получит он старые данные или новые, но если он ожидает получить новые могут быть проблемы. Как B может узнать?
- Через обработчик события, который он поставил (хорошо)
- Через запись в другом znode о том, что в нужном данные изменились (хорошо)
- Если A и B связались друг с другом напрямую (плохо)
В первом случае B получит правильные данные, из-за гарантий zk о том, что если клиенту пришло событие об изменении данных, то запрашивая данные он должен получить новую версию. Во-втором случае тоже будут новые данные из-за глобального порядка — если мы видим новые данные у одного znode, то мы гарантировано видим все изменения, которые были сделаны до него. В ситуации 3 у нас нет гарантий, поэтому, как поведет.
На самом деле, опыт показал, что такое поведение не большая проблема. Кстати в конфиге ZooKeeper можно указать максимальное время за которое должна происходить синхронизация узлами кластера и лидером (syncLimit).
Добро пожаловать в ад :)
Полезный совет: если у вас много нод (например 5) и вы верите, что метеорит не фиганёт по дискам трёх машин сразу, то в конфиге можно указать forceSync=no, тогда zookeeper перестанет на каждый чих делать fdatasync и io упадёт в несколько тысяч раз.
Полезный совет: если у вас много нод (например 5) и вы верите, что метеорит не фиганёт по дискам трёх машин сразу, то в конфиге можно указать forceSync=no, тогда zookeeper перестанет на каждый чих делать fdatasync и io упадёт в несколько тысяч раз.
В сторону hazelcast/jgroups не смотрели, как сервисов распределенной блокировок?
Сильно утрирую: раньше в документацию по телевизорам входила и электросхема, сейчас там только инструкция по замене батареек в пульте, так вот, документация по ZooKeeper это электросхема, а по hazelcast — современная версия.
При разработке распределенных систем очень важно знать как система работает в нештатном режиме, при смерти нод, разрывах в сети и так далее, документация по ZooKeeper описывает это поведение, а бегло просматривая документацию по hazelcast я не смог этого найти.
Другой аспект это доверие, я верю в работоспособност систем в составе которых используется ZooKeeper, таких как Hadoop и HBase, а про использование hazelcast я ничего не знаю, может его используют в основном в качестве кеша и тогда его надежность не в приоритете у разработчиков.
При разработке распределенных систем очень важно знать как система работает в нештатном режиме, при смерти нод, разрывах в сети и так далее, документация по ZooKeeper описывает это поведение, а бегло просматривая документацию по hazelcast я не смог этого найти.
Другой аспект это доверие, я верю в работоспособност систем в составе которых используется ZooKeeper, таких как Hadoop и HBase, а про использование hazelcast я ничего не знаю, может его используют в основном в качестве кеша и тогда его надежность не в приоритете у разработчиков.
Идемпотентность, а не то что вы написали ;-)
UFO just landed and posted this here
UFO just landed and posted this here
В распределенных системах вместо synchronized используется понятие транзакции. В J2EE этому соотсветствуют стандарты JTA, XA, JTS, JCA. Насколько я понял, ZooKeeper не интегрируется с JTA. Поэтому не совсем понимаю почему выбор пал на ZooKeeper, а не на стандартные решения типа EHCache или Infinispan (Oracle Coherence трогать не будем)? Работать с блокировками вручную — довольно сложное и ненадежное занятие, приводящее к трудноотлавливаемым ошибкам.
Если работать с внешними key/value хранилищами, которые не поддерживат транзакции, может понадобиться реализовывать их вручную. Да, для этого можно взять готовые средства, но и они в редких случаях будут давать сбои (в критической секции будет находиться два потока), только если не замкнут весь поток данных на себя. Если интересно — могу расписать подробнее.
Sign up to leave a comment.
ZooKeeper или пишем сервис распределенных блокировок