Системная база данных использования производителя/потребителя (MySql), действительно ли это выполнимо?
Я должен использовать что-то для координирования моей системы с несколькими потребителями/производителями каждая работа различных машин с различными операционными системами. Я исследовал при использовании MySql, чтобы сделать это, но это кажется смехотворно трудным.
Мои требования просты: Я хочу смочь добавить или удалить потребителей/производителей в любое время, и таким образом они не должны зависеть друг от друга вообще. Естественно база данных разделила бы два приятно.
Я смотрел на плагин организации очередей сообщений Q4M для MySql, но это кажется сложным для использования.
Мне действительно нужен некоторый вход о том, как создать мою самую лучшую систему.
3 ответа
Мне нужно использовать что-то для координации мою систему с несколькими потребителей/производителей, каждый из которых работает на разных машинах с разными операционными системами
Это очередь сообщений. Не рассматривайте другие альтернативы. Все остальное (т.е. использование базы данных со вставками и удалениями) ужасно медленно и громоздко.
Создание большой, медленной очереди сообщений с базой данных на практике часто оказывается неудачным, потому что (1) базы данных медленные, (2) базы данных огромные и сложные, (3) у вас есть проблемы блокировки и соперничества, которые делают каждую транзакцию потенциально медленной, (4) это гораздо больше накладных расходов, чем того заслуживает проблема.
Существует множество решений для очередей сообщений.
Если вы не можете заставить Q4M работать, вам следует перейти к другому.
http://en.wikipedia.org/wiki/Message_queue
На самом деле (довольно) сложно построить такую систему. (Я говорю честно, потому что это, конечно, выполнимо).
Если у вас несколько производителей и один потребитель, это просто. Все производители пишут одновременно, а единственный потребитель читает данные, как только они становятся видимыми (фиксированными).
Но если вам нужна масштабируемость с несколькими потребителями, вам нужно будет создать нетривиальную схему блокировки. (Вы должны убедиться, что ни одна строка не отправляется двум потребителям. Этого нелегко добиться с помощью транзакций и блокировок базы данных. Наивные решения приводят к сериализации всей доставки сообщений, как если бы у вас был только один потребитель, что нам не нужно. ).
Я бы посоветовал использовать встроенное решение. Вы также можете прочитать этот вопрос по аналогичному вопросу.
Думаю, это возможно без стороннего ПО.
Мой первый дизайн будет выглядеть так:
- Производитель записывает данные в базу данных
- Чтобы гарантировать согласованность, он должен использовать транзакции
- Потребитель обрабатывает данные (чтение и удаление), также используя транзакции.
Из-за требований к транзакциям InnoDB является логическим выбором механизма хранения. Также нужно тщательно выбирать уровень изоляции. Мое первое предположение - "сериализуемый", чтобы избежать фантомного чтения, но, возможно, более слабый уровень также возможен.
Если производительность и масштабируемость являются проблемой, вам следует подумать об использовании «настоящего» решения для обмена сообщениями. Развертывание одного, скорее всего, приведет к проблемам с производительностью и / или масштабируемостью.