Confirmed users
192
edits
Services/MessageQueuing: Difference between revisions
Jump to navigation
Jump to search
m
→Planning Questions
| Line 14: | Line 14: | ||
*Non-persistent allows use of memcached for higher throughput | *Non-persistent allows use of memcached for higher throughput | ||
*Semi-durable allows backends that do occasional fsync's (Mongo / Redis) | *Semi-durable allows backends that do occasional fsync's (Mongo / Redis) | ||
*Fully persistent (i.e., backed by a db) would be much slower | *Fully persistent (i.e., backed by a db, RabbitMQ persist) would be much slower | ||
Or should an App creator get to choose which characteristic they want when creating a queue? | Or should an App creator get to choose which characteristic they want when creating a queue? | ||
| Line 24: | Line 24: | ||
*Payload could be encrypted at the client layer | *Payload could be encrypted at the client layer | ||
*If routing keys are used (RabbitMQ style brokering), those could be encrypted as well | *If routing keys are used (RabbitMQ style brokering), those could be encrypted as well | ||
*Crypto less useful unless other tasks needed to hide payloads, which should likely be done on client-side | |||
Apps should be able to create both durable and temporary queues on-demand, as well as assign a TTL to a queue for temporary use. | Apps should be able to create both durable and temporary queues on-demand, as well as assign a TTL to a queue for temporary use. | ||
| Line 39: | Line 40: | ||
Queues | Queues | ||
*Single default queue per App seems reasonable | *Single default queue per App seems reasonable | ||
*Multiple queues per App? Routing of messages to multiple queues based on route key like in RabbitMQ? | *Multiple queues per App? Routing of messages to multiple queues based on route key like in RabbitMQ? | ||
| Line 44: | Line 46: | ||
Queue Workers? | Queue Workers? | ||
Simplest: No queue workers, service calls back into special App URL | |||
Drawback: Can't determine as easily if the Apps are busy processing 'task' jobs or end-user requests | |||
*Introduces additional challenge of requiring Apps to have the code the worker should call for a message accessible to the MQ Worker Service | *Introduces additional challenge of requiring Apps to have the code the worker should call for a message accessible to the MQ Worker Service | ||