JuJinPark commented on issue #3221:
URL: https://github.com/apache/hertzbeat/issues/3221#issuecomment-2816597263
Thank you for taking the time to answer all my questions — I really
appreciate it! 😄 I’m looking forward to hearing more about your in-depth
research soon.
One concern I still have is about the core concept of the Leader–Follower
model, where the leader handles all writes to maintain consistency, and
followers only replicate state and serve reads.
But I think HertzBeat is a write-heavy system, at least from the Manager’s
perspective. So the Leader–Follower model could become problematic. For example:
- A large and growing number of collectors send frequent heartbeats
- Collectors register and reconnect often (especially during scaling or
failovers)
- Metric collection results are high-frequency writes
Even if metric collection results ares pushed elsewhere, I’m concerned the
leader could still suffer from too much traffic and become a bottleneck —
similar to the original scalability challenge we’re trying to solve.
I also had one more question:
👉 Is assigning a job to a specific collector a core design requirement?
Because if not, maybe we could eliminate the consistent hashing entirely —
which would allow us to remove centralized state and make it much easier to
support a stateless, horizontally scalable Manager cluster.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
