There is a temptation to use MySQL message queues to provide more complex queueing strategies - prioritization, retries, folding multiple queues into one table, claim tokens to avoid the global lock, and in the very worst case keeping all of the queue data to double up as log records. All of these must be resisted - they scale and perform poorly.
If they use MyISAM as the table format for the queue, it may crash and require repairs. If they use InnoDB, then the queue is no longer very lightweight.
Queues in MySQL certainly can work, and are pretty straightforward, but they'll need to be replaced with something else eventually.
"The right tool for the right job" and all that. I just wish AMQP didn't seem quite so sketchy ...
Comments
There is a temptation to use MySQL message queues to provide more complex queueing strategies - prioritization, retries, folding multiple queues into one table, claim tokens to avoid the global lock, and in the very worst case keeping all of the queue data to double up as log records. All of these must be resisted - they scale and perform poorly.
If they use MyISAM as the table format for the queue, it may crash and require repairs. If they use InnoDB, then the queue is no longer very lightweight.
Queues in MySQL certainly can work, and are pretty straightforward, but they'll need to be replaced with something else eventually.
"The right tool for the right job" and all that. I just wish AMQP didn't seem quite so sketchy ...
check q4m, it has been out in production use for 3 years.