Система производителя/потребителя, использующая базу данных (MySql), возможно ли это?

Мне нужно использовать что-то для координации моей системы с несколькими потребителями/производителями, каждый из которых работает на разных машинах с разными операционными системами. Я исследовал использование MySql для этого, но это кажется смехотворно сложным.

Мои требования просты: я хочу иметь возможность добавлять или удалять потребителей/производителей в любое время, и поэтому они вообще не должны зависеть друг от друга. Естественно, база данных прекрасно разделила бы их.

Я искал плагин очереди сообщений Q4M для MySql, но он кажется сложным в использовании.

Мне действительно нужен некоторый вклад в то, как построить мою систему наилучшим образом.


mysql database consumer producer system
person johnrl    schedule 15.03.2010    source источник
comment
Вы про архитектуру спрашиваете? Очереди сообщений являются стандартным решением. Вы спрашиваете о своих технических проблемах при создании Q4M? Пожалуйста, сосредоточьте свой вопрос либо на архитектуре в целом, либо на Q4M в частности. Трудно ответить обоим.   -  person S.Lott    schedule 15.03.2010
comment
Этот вопрос касается архитектуры. Я опубликую еще один, посвященный компиляции Q4M.   -  person johnrl    schedule 15.03.2010
comment
Если вы действительно спрашиваете об архитектуре, не могли бы вы отредактировать свой вопрос, чтобы сосредоточиться на архитектуре? Отвлечение на проблему Q4M мешает людям понять ваш вопрос и предложить разумную помощь. Пожалуйста, удалите отвлекающие материалы и сосредоточьтесь на своем вопросе.   -  person S.Lott    schedule 16.03.2010

Ответы (4)


arrow_upward
5
arrow_downward

Мне нужно что-то использовать для координации моей системы с несколькими потребителями/производителями, каждый из которых работает на разных машинах с разными операционными системами.

Это очередь сообщений. Не гонитесь за другими альтернативами. Все остальное (например, использование базы данных с вставками и удалениями) ужасно медленно и громоздко.

Построение большой и медленной очереди сообщений с базой данных на практике часто заканчивается плохо, потому что (1) базы данных медленные, (2) базы данных огромные и сложные, (3) у вас есть проблемы с блокировкой и конфликтами, которые делают каждую транзакцию потенциально медленной, ( 4) это намного больше накладных расходов, чем того заслуживает задача.

Существует множество решений для очередей сообщений.

Если вы не можете заставить Q4M работать, вам следует перейти к другому.

http://en.wikipedia.org/wiki/Message_queue

http://linux.die.net/man/7/mq_overview

http://qpid.apache.org/

http://code.google.com/p/httpsqs/

person S.Lott    schedule 15.03.2010
comment
Я понимаю. Спасибо за ссылки. Думаю, тогда я буду использовать решение для очереди сообщений. MSMQ звучит как хорошее решение (для .net). - person johnrl; 16.03.2010

arrow_upward
2
arrow_downward

На самом деле (довольно) сложно построить такую ​​систему. (Я говорю честно, потому что это, конечно, выполнимо).

Если у вас есть несколько производителей и один потребитель, это несложно. Все производители пишут одновременно, а один потребитель считывает данные, как только они становятся видимыми (фиксируются).

Но если вам нужна масштабируемость с несколькими потребителями, вам потребуется создать нетривиальную схему блокировки. (Вы должны гарантировать, что ни одна строка не будет отправлена ​​двум потребителям. Этого нелегко добиться с транзакциями и блокировками базы данных. Наивные решения приводят к сериализации доставки всех сообщений, как если бы у вас был только один потребитель, чего мы не хотим. ).

Я бы предложил использовать встроенное решение. Вы также можете прочитать этот вопрос по похожему вопросу.

person ewernli    schedule 15.03.2010

arrow_upward
1
arrow_downward

Я думаю, что это осуществимо без стороннего программного обеспечения.

Мой первый дизайн будет выглядеть так:

  • Производитель записывает данные в базу данных
  • Чтобы гарантировать согласованность, он должен использовать транзакции
  • Потребитель обрабатывает данные (читает и удаляет) также с помощью транзакций.

Из-за требований к транзакциям InnoDB является логичным выбором механизма хранения. Также вы должны тщательно выбирать уровень изоляции. Мое первое предположение - "сериализуемый", чтобы избежать фантомных чтений, но, возможно, возможен и более слабый уровень.

Если производительность и масштабируемость являются проблемой, вам следует рассмотреть возможность использования «настоящего» решения для обмена сообщениями. Развертывание вашего, скорее всего, приведет к проблемам с производительностью и / или масштабируемостью.

person Daniel Rikowski    schedule 15.03.2010

arrow_upward
0
arrow_downward

Это зависит от ситуаций.

В моем случае единственный производитель отправляет тысячи сообщений в день, а несколько потребителей потребляют эти сообщения в течение следующих 24 часов, на завершение которых у каждого уходит несколько минут. Итак, я думаю, что mysql удовлетворит мои требования, и я могу использовать транзакции для обеспечения согласованности между потребителями.

Надеюсь, это поможет.

person bourneli    schedule 23.03.2015