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