danthegoodman1 / UltraQueue

Distributed pull queue based on Segment's Centrifuge. Zero dependency p2p clustering.
GNU Affero General Public License v3.0
1 stars 0 forks source link

Multiple Partitions Per Process #35

Open danthegoodman1 opened 2 years ago

danthegoodman1 commented 2 years ago

Right now the gossip manager takes a single partition to join to the cluster. At thousands of nodes this becomes very noisy with just gossip updates, and is an inefficient use of resources.

We should allow a single process to become multiple partitions and allow a gossipmanager to manage all of them like raft multigroup.

We can leverage Go's concurrency model to have a single process on 4 cores manage 4 partitions with 1 gossipmanager handling them all.

danthegoodman1 commented 2 years ago

Thinking about this more, it shouldn't be too hard to make this change. Major changes:

  1. Initialization of partitions
  2. GossipManager needs to know about multiple partitions
  3. GossipManager needs to send out info about multiple partitions for scanning topic lengths (array of these structs now)
  4. Partitions should be aware of what other partitions on the same node has so they can favor the local partition when they receive a dequeue request and can't fulfill it
  5. The GossipName cannot be the partition name anymore
  6. We need to map remote partitions to node names so that when a node leaves we can get rid of all partitions it managed

Another point is heartbeating. If the gossip stops heartbeating we are losing multiple partitions.