I have a service built on Microservices architecture. The design includes 3 components that communicating with queues. System components:
- Microservice "A" gets a request and generates subrequests. Each sub-request is a queue message written to the Service "B" queue. Each incoming message producing multiple messages to queue "B".
- Microservice "B" gets a task to execute and execute it. When all the subrequests, made by service "A", executed - this service enqueues a message into service "C" queue. Enqueuing a message into the next queue happens only when all the execution of the messages is done.
- Microservice "C" get a message and mark the row in the database as completed.
They way it's implemented today is the on step "1" I create a counter with the init value of the number of tasks. Each execution of service "B" is decrement this counter by 1. After the last execution - the counter value will be 0 - then the execution thread will generate a new message to service "C". This process ensure only 1 message into queue "C".
Basicly, it's working. The problem with this, is the number of decrement operations.
Today I implemented this counter as a database row (SQL update operation is atomic). It's reliable but make my database hard life.
Other solutions I thought about:
- MySQL Database: reliable, relatively slow. Limited throughput.
- Redis: work fast, but we cannot trust it (after restart all the data is removed).
- NoSQL: not handling concurrency in a good way. Hotspots break the performances.
Wondering if this kind of problem has a better solution?
Aucun commentaire:
Enregistrer un commentaire