CODEWITHSUNDEEP
queuejmsakkascalabilityp2p
spam
spam

Reputation: 1993

How can (messaging) queue be scalable?

I frequently see queues in software architecture, especially those called "scalable" with prominent representative of Actor from Akka.io multi-actor platform. However, how can queue be scalable, if we have to synchronize placing messages in queue (and therefore operate in single thread vs multi thread) and again synchronize taking out messages from queue (to assure, that message it taken exactly once)? It get's even more complicated, when those messages can change state of (actor) system - in this case even after taking out message from queue, it cannot be load balanced, but still processed in single thread.

  1. Is it correct, that putting messages in queue must be synchronized?
  2. Is it correct, that putting messages out of queue must be synchronized?
  3. If 1 or 2 is correct, then how is queue scalable? Doesn't synchronization to single thread immediately create bottleneck?
  4. How can (actor) system be scalable, if it is statefull?
  5. Does statefull actor/bean mean, that I have to process messages in single thread and in order?
  6. Does statefullness mean, that I have to have single copy of bean/actor per entire system?
  7. If 6 is false, then how do I share this state between instances?
  8. When I am trying to connect my new P2P node to netowrk, I believe I have to have some "server" that will tell me, who are other peers, is that correct? When I am trying to download torrent, I have to connect to tracker - if there is "server" then we do we call it P2P? If this tracker will go down, then I cannot connect to peers, is that correct?
  9. Is synchronization and statefullness destroying scalability?

Upvotes: 1

Views: 1375

Answers (2)

Roland Kuhn
Roland Kuhn

Reputation: 15472

Of course you are correct in that a single queue is not scalable. The point of the Actor Model is that you can have millions of Actors and therefore distribute the load over millions of queues—if you have so many cores in your cluster. Always remember what Carl Hewitt said:

One Actor is no actor. Actors come in systems.

Each single actor is a fully sequential and single-threaded unit of computation. The whole model is constructed such that it is perfectly suited to describe distribution, though; this means that you create as many actors as you need.

Upvotes: 1

the8472
the8472

Reputation: 43115

  1. Is it correct, that putting messages in queue must be synchronized?
  2. Is it correct, that putting messages out of queue must be synchronized?

No.

Assuming we're talking about the synchronized java keyword then that is a reenetrant mutual exclusion lock on the object. Even multiple threads accessing that lock can be fast as long as contention is low. And each object has its own lock so there are many locks, each which only needs to be taken for a short time, i.e. it is fine-grained locking.

But even if it did, queues need not be implemented via mutual exclusion locks. Lock-free and even wait-free queue data structures exist. Which means the mere presence of locks does not automatically imply single-threaded execution.

The rest of your questions should be asked separately because they are not about message queuing.

Upvotes: 1

Related Questions