Produtor/Sistema de Consumidores usando o banco de dados (MySQL), isso é viável?

Question

Eu preciso usar algo Para coordenar meu sistema com vários consumidores/produtores, cada um em diferentes máquinas com diferentes sistemas operacionais. Eu tenho pesquisado sobre o uso do MySQL para fazer isso, mas parece ridiculamente difícil.

Meus requisitos são simples: quero poder adicionar ou remover consumidores/produtores a qualquer momento e, portanto, eles não devem depender um do outro. Naturalmente, um banco de dados separaria os dois bem.

Eu tenho analisado o plug -in de fila de mensagens Q4M para MySQL, mas parece complicado de usar.

Eu realmente preciso de algumas informações sobre como construir o melhor possível do meu sistema.

Answer 1

Preciso usar algo para coordenar meu sistema com vários consumidores/produtores cada um em diferentes máquinas com diferentes sistemas operacionais

Essa é uma fila de mensagens. Não perseguem outras alternativas. Tudo o mais (ou seja, usando um banco de dados com inserção e exclusão) é terrivelmente lento e pesado.

Construir uma fila de mensagens grandes e lentas com um banco de dados geralmente acaba mal na prática, porque (1) os bancos de dados são lentos; (2) os bancos de dados são enormes e complexos, (3) você tem problemas de travamento e contenção que tornam cada transação potencialmente lenta (( 4) É muito mais sobrecarga do que o problema merece.

Existem inúmeras soluções de fila de mensagens.

Se você não conseguir fazer o Q4M funcionar, deve passar para outro.

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

Na verdade, é (bastante) complicado construir esse sistema. (Eu digo de maneira justa, porque é claro que é factível).

Se você tem vários produtores e 1 Consumidor, é fácil. Todos os produtores escrevem simultaneamente, e o único consumidor leu dados assim que forem visíveis (comprometidos).

Mas se você quiser escalabilidade com de várias Consumidor, você precisará criar um esquema de travamento que não seja trivial. (Você deve garantir que nenhuma linha seja despachada para dois consumidores. Isso não é fácil de obter com transações e bloqueios de banco de dados. Soluções ingênuas levam à serialização de toda a entrega de mensagens, como você tinha apenas um consumidor, o que não queremos. ).

Eu sugeriria usar uma solução interna. Você também pode ler essa questão sobre uma pergunta semelhante.

Answer 3

Eu acho que é viável sem software de terceiros.

Meu primeiro design ficaria assim:

• O produtor escreve dados no banco de dados
• Para garantir a consistência, ele precisa usar transações
• O consumidor processa os dados (leia e excluir) também usando transações.

Devido ao requisito de transações, o InnoDB é a escolha lógica do mecanismo de armazenamento. Além disso, você deve escolher cuidadosamente o nível de isolamento. Meu primeiro palpite é "serializável" para evitar leituras fantasmas, mas talvez seja possível um nível mais fraco.

Se o desempenho e a escalabilidade são um problema, considere usar uma solução de mensagens "real". A implantação do seu provavelmente levará a problemas de desempenho e/ou escalabilidade.

Answer 4

Depende de situações.

No meu caso, o único produtor faz milhares de mensagens por dia, e vários consumidores consomem essas mensagens nas 24 horas seguintes, que cada uma delas leva vários minites para terminar. Então, acho que o MySQL atenderia aos meus requisitos e posso usar as transações para garantir a consistência entre os consumidores.

Espero que ajude.