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

Question

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

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

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

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

Answer 1

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

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

Построение большой, медленной очереди сообщений с базой данных часто оказывается плохим на практике, потому что (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/

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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