mercredi 22 avril 2020

Distributed Atomic Counter

I have a service built on Microservices architecture. The design includes 3 components that communicating with queues. System components:

  1. 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".
  2. 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.
  3. 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:

  1. MySQL Database: reliable, relatively slow. Limited throughput.
  2. Redis: work fast, but we cannot trust it (after restart all the data is removed).
  3. 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