Комментарии 41
У нас нет ресурсов на адаптацию, но есть ресурсы на расшифровку. Материалы хорошие, доклады выбраны пользователями. Мы честно пишем, что это расшифровка доклада, всё по-чесноку!
Делал расшифровки выпусков телепередач. На слух запоминал речь в рамках эпизода, ставил на паузу, печатал, снова слушал. В результате натренировал память. Потом вторым проходом расставлял знаки препинания, в обнимку с сайтом грамота ру — натренировал пунктуацию. И то и другое не раз пригодилось. Смысл есть в самых неожиданных местах.
Спрашивал активных пользователей RabbitMQ про надёжность, в каких ситуациях лучше использовать БД. Все говорили, что очередь надёжна, что записи никуда не пропадут, что очередь сбрасывается на диск, и даже перезапуск сервера ей не страшен.
А судя по слайдам, узким местом является требование к памяти, памяти надо много, и когда она заканчивается, как понимаю, работа сервера очередей может прекратиться. Протестировать очередь при недостатке памяти дело нехитрое, на ноутбуке памяти мало. Постараюсь протестировать.
Расшифровка — отличный формат. Спасибо.
ОПИСАНИЕ
fsync копирует все части файла, находящиеся в памяти, на
устройство (диск) и ждет, пока устройство не доложит о
том, что все части нормально сохранены.
ЗАМЕЧАНИЯ
В случае, если на жестком диске включено кэширование при
записи, данных фактически может не быть на диске, хотя
fsync/fdatasync уже сообщит об их записи на диск и
завершит работу.
Это значит что опция sync вас не спасёт. Но не всё так плохо, в новой версии (3.5.5) кролика fsync происходит раз в 0.2с и ни что не мешает вам собрать из исходников свою версию с более коротким промежутком.
ВАЖНО для всех пользователей RabbitMQ
Обычно высокая надёжность достигается за счёт использование кластера из 2х и более машин (что кстати избавляет от необходимости рейда). И есть замечательный механизм — Acknowledgment. Если на пальцах — то при его использовании приходит асинхронное подтверждение согласованного надёжного сохранения сообщения в кластере или сообщение что отвергнуто. Ну соответственно прикладная программа должна уметь с этом работать. Вариантов как это использовать масса.
fsync штука хорошая, но не спасет от выхода из строя самого диска.
В этой ситуации кеш можно перенести на SSD.
В этой ситуации кеш можно перенести на SSD.
Либо я вас не понял либо насколько я знаю это не возможно использовать в *nix. Для защиты от отказа диска обычно используют рейд или в случае с RabbitMQ лучше использовать кластер.
Смотря какой *nix использовать. Прокачай свой жёсткий диск! Этот способ реально работает!. А в Кеширование данных на SSD с помощью EnhanceIO упоминаются еще парочка решений.
Для некоторых решений нужно патчить ядро, можно на уровне ядра добавить принудительный сброс в ssd.
RAID разные бывают. fsync не гарантирует пробивку кеша рейда. Поэтому и появились RAID с батарейкой. Если туже батарейку не поменять, то можем потерять данные.
>RAID разные бывают
Я говорил исключительно про софтверный рейд. Про аппаратный рейд вы полностью правы.
Кстати очень забавно наблюдать когда люди покупают аппаратный без батарейки потому как дорого и не выключают кеш на нём.
Стиль подачи информации очень нравится, в очередной раз спасибо!
Нам понадобилась очередь, и мы решили использовать для ее организации СУБД. А там блокировки, да и хранит данные она на диске, непорядок! Решили использовать модный распределенный ObjectStore для организации очереди, он работает побыстрее, но все равно оверхед большой и управлять им сложно, не то. Затем для реализации очереди мы решили использовать распределенный in-memory key-value store (а почему бы и нет?). Затем не распределенный in-memory key-value store. Затем мы решили все-таки попробовать продукты, реализующие функционал очередей, но что-то у них настройка больно мудреная, и мы не осилили
Это же основы. ПО для организации очередей писалось не дураками, и писалось именно потому, что другие инструменты конкретно для задачи организации очередей подходят плохо. ActiveMQ, ZeroMQ, RabbitMQ, Kafka и многие другие — создавались именно для того, чтобы снизить оверхед на операции с очередями, гарантировать сохранность данных и их последующую обработку. По определению никакие СУБД, key-value store, object store и прочие не будут решать эту задачу лучше, за исключением ситуации, когда у вас одно сообщение в секунду и вам не важно, будет ли оно в итоге обработано или потеряно.
вам не важно, будет ли оно в итоге обработано или потеряно
Не согласен, очереди в бд какрастаки и нужны для сверх надёжности, транзакционности и ACID + для произвольной выборки а не только из конца как в стандартных FIFO очередях. За это конечно приходиться платить меньшей производительностью.
Что хорошо в очередях, и из-за чего появилось много решений для организации очередей — им не нужна полноценная ACID. А по поводу произвольной выборки — та же Kafka умеет читать из произвольного места в очереди.
А по поводу произвольной выборки — та же Kafka умеет читать из произвольного места в очереди.Это верно но стоит добавить что это введено недавно в версии 9.0 и пока offset работает очень плохо — при стечений обстоятельств можно потерять много данныx (я бы пока не советовал для прода). Если хочется высокопроизводительную и надёжную очередь с произвольным чтением я бы советовал IBM MQ это конечно проприетарный и дорогой продукт но аналогов у него пока нет.
Что хорошо в очередях, и из-за чего появилось много решений для организации очередей — им не нужна полноценная ACID.Блин это круто! Вам книги технические надо писать, вся суть одним предложением. Тут только могу добавить что «им» это не очередям, а задачам которые на них решают.
Кстати кластер на RabbitMQ практически почти обеспечивает ACID. Практически поскольку ACID классификация применима в случае очередей для всей системы в целом т.е. очередь + прикладные программы. Сответсвенно прикладные программы могут всё порушить.
Сверх надежность обеспечивается дублированием систем. Как только мы будем собирать кластер БД, то мы столкнемся с CAP теоремой. Как не крути, грусть и печаль.
Кстати если всё же географическое разделение необходимо, то есть интересный подход — отказ от устойчивости к разделению через исключение разделяемых ресурсов. Это конечно не всегда возможно. Пример для лучшего понимания — нужно сделать количество денег на счёту пользователя не разделяемым. Тогда предварительно нужно разделить сумму на две части и предоставить каждую часть на пользование одной из двух нод, а потом раз в некоторое время перебалансировать два этих подбаланса. Конечно на время разделение чтение актуальной итоговой суммы по разделённому каналу не возможно но все операции по обработки в пределах разделения будут происходить не нарушая ACID.
как-то так…
Куда как менее прожорливый.
https://www.consul.io/intro/vs/zookeeper.html
Статья хорошая, но… Красный текст на синем фоне? Вы серьезно?
Kafka имеет к Hadoop очень мало отношения, это вещь в себе
как продолжение, есть слайды с митапа "10 рецептов готовки кролика"
из доклада:
То, что я реализовывал — это было еще 4-5 лет назад, тогда такого пакета еще не было. Сейчас появился очень хороший API у Tarantool, если кто пользуется Python, у них API, вообще заточенный под очереди.
rybakit:
Я написал для php библиотеку для работы с очередями больше года назад:
https://github.com/tarantool-php/queue
Вроде вышло неплохо, ссылка на нее добавлена в awesome-php список:
https://github.com/ziadoz/awesome-php#queue
Какие плюшки даем нам пакет Queue? Там есть очереди с приоритетами, такого я больше не встречал нигде среди других серверов очередей.
rybakit:
Вообще, очереди с приоритетами можно встретить во многих реализациях. Вот, например, довольно популярный Beanstalkd, с которого был скопирован API для тарантуловской очереди:
https://github.com/kr/beanstalkd
Я сам реализовывал очереди с приоритетами (по времени) для многих бэкедов (redis, mondo, db и тд):
https://github.com/rybakit/phive-queue#queues
Очереди и блокировки. Теория и практика