Полностью с вами согласен, но это как говориться детали.
А по поводу произвольной выборки — та же Kafka умеет читать из произвольного места в очереди.
Это верно но стоит добавить что это введено недавно в версии 9.0 и пока offset работает очень плохо — при стечений обстоятельств можно потерять много данныx (я бы пока не советовал для прода). Если хочется высокопроизводительную и надёжную очередь с произвольным чтением я бы советовал IBM MQ это конечно проприетарный и дорогой продукт но аналогов у него пока нет.
Что хорошо в очередях, и из-за чего появилось много решений для организации очередей — им не нужна полноценная ACID.
Блин это круто! Вам книги технические надо писать, вся суть одним предложением. Тут только могу добавить что «им» это не очередям, а задачам которые на них решают.
Кстати кластер на RabbitMQ практически почти обеспечивает ACID. Практически поскольку ACID классификация применима в случае очередей для всей системы в целом т.е. очередь + прикладные программы. Сответсвенно прикладные программы могут всё порушить.
Либо я вас не понял либо насколько я знаю это не возможно использовать в *nix. Для защиты от отказа диска обычно используют рейд или в случае с RabbitMQ лучше использовать кластер.
ОПИСАНИЕ
fsync копирует все части файла, находящиеся в памяти, на
устройство (диск) и ждет, пока устройство не доложит о
том, что все части нормально сохранены.
ЗАМЕЧАНИЯ
В случае, если на жестком диске включено кэширование при
записи, данных фактически может не быть на диске, хотя
fsync/fdatasync уже сообщит об их записи на диск и
завершит работу.
Это значит что опция sync вас не спасёт. Но не всё так плохо, в новой версии (3.5.5) кролика fsync происходит раз в 0.2с и ни что не мешает вам собрать из исходников свою версию с более коротким промежутком.
ВАЖНО для всех пользователей RabbitMQ
Обычно высокая надёжность достигается за счёт использование кластера из 2х и более машин (что кстати избавляет от необходимости рейда). И есть замечательный механизм — Acknowledgment. Если на пальцах — то при его использовании приходит асинхронное подтверждение согласованного надёжного сохранения сообщения в кластере или сообщение что отвергнуто. Ну соответственно прикладная программа должна уметь с этом работать. Вариантов как это использовать масса.
вам не важно, будет ли оно в итоге обработано или потеряно
Не согласен, очереди в бд какрастаки и нужны для сверх надёжности, транзакционности и ACID + для произвольной выборки а не только из конца как в стандартных FIFO очередях. За это конечно приходиться платить меньшей производительностью.
Если говорить про RabbitMQ то она не супер супер надёжна, сохранение новых элементов очередей которые объявлены как персистентные (есть ещё менне надёжные очереди в памяти ) на диск не делает fsync (ради производительности), это значит что данные попадут в кеш дисковой подсистемы и только когда ядро соизволит сбросить данные на диск они будут надёжно сохранены, если в этот (обычно короткий) промежуток выключить сервер данные потеряются.
А я долго гадал думал, зачем в таком большом количестве вы выбрасываете переводы так себе статей (хотя некоторые интересны). Теперь то понятно — пиарить совой проект обучения web проганью, вот только этих сервисов развелось как грязи в последнее время, чему то там конечно обучают, но только минимальным основам и так себе (Кто умеет, тот делает; кто не умеет, тот учит — пословица такая). В итоге на итак перегретый рынок it разработки выплёскиваются люди прошедшие пару курсов с завышенным чсв и требованием 1000$ в месяц и красной ковровой дорожки чтобы просто прийти на собеседование (к сожалению это гиперболизированная но всё же реальность). Вообщем печалька.
Я не нашёл ни каких контактов на сайте, поэтому попрошу создателей, если они это читают, написать на novoxudonoser@protonmail.com есть пара вопросов и предложений.
Молодцы, успехов. Но всё таки делайте хабр по возможности техническим ресурсом, а не просто презентуйе и пиарте свои сервисы. Я хочу сказать что в статье присутствует тех составляющая (и признаюсь статья интересна) но её явно не достаточно.
Ну вообще говоря если сайт конкурирует среди большого количества аналогичных вроде авиабилетов, то скорость ux и дизайн будут сильно влиять на успех, и это действительно важно. Если предположим это чтото навроде хабра то полностью согласен.
Очень ждал его, мне очень понравилась компоновка у Surface от мелкомяхих, но от них устройство разумеется не хотел покупать. Вопроса 2 — как обстоит дело с Linux? Его можно будет поставить, нет ли лока в Secure Boot? Как обстоит дело с драйверами, сильно придётся извращаться? Как я понимаю десятка стоит максимальная, можно ли будет отказаться от неё и вернуть деньги согласно процедуре?
Это верно но стоит добавить что это введено недавно в версии 9.0 и пока offset работает очень плохо — при стечений обстоятельств можно потерять много данныx (я бы пока не советовал для прода). Если хочется высокопроизводительную и надёжную очередь с произвольным чтением я бы советовал IBM MQ это конечно проприетарный и дорогой продукт но аналогов у него пока нет.
Блин это круто! Вам книги технические надо писать, вся суть одним предложением. Тут только могу добавить что «им» это не очередям, а задачам которые на них решают.
Кстати кластер на RabbitMQ практически почти обеспечивает ACID. Практически поскольку ACID классификация применима в случае очередей для всей системы в целом т.е. очередь + прикладные программы. Сответсвенно прикладные программы могут всё порушить.
Либо я вас не понял либо насколько я знаю это не возможно использовать в *nix. Для защиты от отказа диска обычно используют рейд или в случае с RabbitMQ лучше использовать кластер.
Это значит что опция sync вас не спасёт. Но не всё так плохо, в новой версии (3.5.5) кролика fsync происходит раз в 0.2с и ни что не мешает вам собрать из исходников свою версию с более коротким промежутком.
ВАЖНО для всех пользователей RabbitMQ
Обычно высокая надёжность достигается за счёт использование кластера из 2х и более машин (что кстати избавляет от необходимости рейда). И есть замечательный механизм — Acknowledgment. Если на пальцах — то при его использовании приходит асинхронное подтверждение согласованного надёжного сохранения сообщения в кластере или сообщение что отвергнуто. Ну соответственно прикладная программа должна уметь с этом работать. Вариантов как это использовать масса.
Не согласен, очереди в бд какрастаки и нужны для сверх надёжности, транзакционности и ACID + для произвольной выборки а не только из конца как в стандартных FIFO очередях. За это конечно приходиться платить меньшей производительностью.
только если большинство это некоторые