Comments 35
А вы пробовали потестировать для своих целей hazelcast?
На hazelcast мы смотрели. На тот момент когда выбирали технологию, hazelcast была просто библиотекой синхронизации запросов (быть может сейчас что-то изменилось). А нам нужна целая система гарантированной доставки, которая требует кучу еще всего: сохранение данных на диск, синхронизация данных с диска, восстановление данных после перезапуска и т.д. и т.п. У нас в соседнем проекте используется hazelcast поверх activemq.
Но если прочитать все, что мы делали, то боюсь что это тоже не решение из коробки. Его нужно будет тюнить и тюнить.
Но если прочитать все, что мы делали, то боюсь что это тоже не решение из коробки. Его нужно будет тюнить и тюнить.
Сейчас в библиотеке hazelcast точно есть очередь.
А какими тулами Вы пользовались при работе с zookeeper?
К примеру, Вы пробовали использовать curator.apache.org/?
А какими тулами Вы пользовались при работе с zookeeper?
К примеру, Вы пробовали использовать curator.apache.org/?
curator.apache.org мы не использовали, тем более нам существенно пришлось переделать внутренности zookeeper-а, так что вероятно не будет совместимости
Интересно вы используете Zookeeper. В Сurator есть repices для всяких очередей, но большими буквами написано, что это нужно делать осторожно (не для большого количества сообщений и почему). См ZooKeeper makes a very bad Queue source. Вообще для задач схожих с вашей много раз слышал о Kafka.
> затрачиваемых, например, на извлечение текста из фотографий
Вы распознаете текст на фотографиях пользователей?
Вы распознаете текст на фотографиях пользователей?
Еженедельно проходят так называемые учения, чтобы быть уверенными, что сервисы Яндекса будут продолжать работать, если один из дата-центров вышел из строя.
При этом вы действуете максимально мягко (например, заранее приказать GSLB начать игнорировать существование данной площадки, заранее препендами или отключением анонса BGP увести трафик), или просто рубите сплеча, измеряя реальный даунтайм? Что-то подсказывает мне, что используется первый сценарий, но вдруг?
И есть кое-что хуже полной недоступности ЦОДа: частичная недоступность ЦОДа и/или деградация связи до него или в нем… Вероятность такого события всяко выше, чем полного обесточивания или перерубания всех (или всех кроме одной, которая сразу захлебнется от трафика) магистралей.
Не пытались использовать Kafka от Linkedin, учитывая, что вы уже используете zookeeper как кольцевой буфер, из которого разные бэкэнды читают одни и те же данные?
Для данной задачи Kafka мы не пытались использовать, но Kafka у нас используется в другом месте. Кстати, интересный вопрос, поизучаю и вероятно напишу насколько Kafka именно сюда может/не может подойти.
Ок, спасибо. Еще один вопрос. Со стороны консьюмеров гарантировать exactly-once обработку сообщений можно, например, хранением текущей позиции в кольцевом буфере вместе с обработанными сообщениями. А как вы гарантируете exactly-once запись сообщений в zookeeper? Гарантируете ли вообще?
exactly-once запись сообщений в zookeeper и гарантируем так:
1. перед записью в очередь для сообщения вычисляется хэш и в очередь сообщение записывается вместе с хэшем
2. в момент записи сообщения в очередь сначала выполняется поиск по хэшу и если сообщение с таким хэшем уже есть в очереди, то запись сообщения не производится
3. если в момент записи сообщения в очередь соединение обрывается, то это сообщение записывается еще раз в случае, если оно не было записано до этого
1. перед записью в очередь для сообщения вычисляется хэш и в очередь сообщение записывается вместе с хэшем
2. в момент записи сообщения в очередь сначала выполняется поиск по хэшу и если сообщение с таким хэшем уже есть в очереди, то запись сообщения не производится
3. если в момент записи сообщения в очередь соединение обрывается, то это сообщение записывается еще раз в случае, если оно не было записано до этого
Тут коллеги подсказали, что в последней kafke уже появилась репликация, но с рядом ограничений. Так что если поработать над настройкой Кафки, вероятно спустя время тоже что-то могло получиться
Про Кафку — она не реплицирует данные, поэтому не гарантирует доставку сообщений и поэтому для данной задачи не подходит
У меня в яндекс-почте накопилось в папочке 969736 писем. Как я не крутился, а удалить такое кол-во писем просто нельзя. Запрос в тех.поддержку пару лет назад тоже не дал результатов. Хотелось бы чтобы такие вещи были организованы несколько лучше…
Дождались бы уж юбилея.
UFO just landed and posted this here
Нет, не помогла
К сожалению, с операциями над очень большим количеством писем на данный момент бывают проблемы. Мы занимаемся исправлением ситуации, а пока что можем запустить процесс очистки определённой папки со своей стороны. Можно для этого обратиться в службу поддержки, или скажите мне в личку свой логин и название папки.
> Apache ZooKeeper – очередь с гарантией доставки
Вы уверены? В apache так не считают: zookeeper.apache.org
> ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
Всё же kafka тут лучше подошел бы, мне кажется.
Вы уверены? В apache так не считают: zookeeper.apache.org
> ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
Всё же kafka тут лучше подошел бы, мне кажется.
Ну мы вроде бы описали, что Zookeeper сильно видоизменен и используется в особом режиме.
а вот походимость kafka с учетом наших ограничений еще нужно доказывать.
Расскажите как бы вы настроили kafka, чтобы она гарантированно доставляла в условиях междатацентровой очереди, в условиях еженедельных отключений ДЦ, в условиях огромных объемов данных, при необходимости гарантированной доставки всего и сохранения последовательности сообщений и действий над ними?
Дело в том, что zookeeper содержит не только входной набор писем, но и еще для задач Постмастера он получает действия пользователей над письмами: положили в спам, удалили, прочитали и т.д. и т.п.
и тут очень важно, чтобы сообщение о приходе письма попало в бекэнд раньше, сообщения о действии пользователя над ним
а вот походимость kafka с учетом наших ограничений еще нужно доказывать.
Расскажите как бы вы настроили kafka, чтобы она гарантированно доставляла в условиях междатацентровой очереди, в условиях еженедельных отключений ДЦ, в условиях огромных объемов данных, при необходимости гарантированной доставки всего и сохранения последовательности сообщений и действий над ними?
Дело в том, что zookeeper содержит не только входной набор писем, но и еще для задач Постмастера он получает действия пользователей над письмами: положили в спам, удалили, прочитали и т.д. и т.п.
и тут очень важно, чтобы сообщение о приходе письма попало в бекэнд раньше, сообщения о действии пользователя над ним
> Ну мы вроде бы описали, что Zookeeper сильно видоизменен и используется в особом режиме.
Это вы потом написали, аж в другом параграфе, отделённом заголовком. Сначала вы написали, что зукипер для очередей, что не совсем правда.
У kafka вроде бы всё хорошо с объёмами данных, отключенными нодами, очередностью сообщений и вот этим всем. Если у вас уже есть kafka в другом месте, то накладные расходы на поддержу должны быть меньше, нежели с самописными надстройками над zk.
kafka.apache.org/08/ops.html
engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka
Это вы потом написали, аж в другом параграфе, отделённом заголовком. Сначала вы написали, что зукипер для очередей, что не совсем правда.
У kafka вроде бы всё хорошо с объёмами данных, отключенными нодами, очередностью сообщений и вот этим всем. Если у вас уже есть kafka в другом месте, то накладные расходы на поддержу должны быть меньше, нежели с самописными надстройками над zk.
kafka.apache.org/08/ops.html
engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka
Постарайтесь, пожалуйста, подгонять иллюстрации по размеру. Мегабайтная картинка шириной 640 пикселей это некоторое неуважение к 3G-читателям.
Sign up to leave a comment.
ZooKeeper в качестве системы гарантированной доставки для Яндекс.Почты