You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After discovering this project, I then found the CRAQ paper and began reading it. In that paper, I noticed this paragraph:
Building a fault-tolerant coordination service for distributed applications is notoriously error prone. An
earlier version of CRAQ contained a very simple, centrally controlled coordination service that maintained
membership management. We subsequently opted to leverage ZooKeeper however, to provide CRAQ
with a robust, distributed, high-performance method for tracking group membership and an easy way to
store chain metadata. Through the use of Zookeper, CRAQ nodes are guaranteed to receive a
notification when nodes are added to or removed from a group. Similarly, a node can be notified when
metadata in which it has expressed interest changes.
I've noticed in other implementations of CRAQ, I've seen them replace ZooKeeper with protocols like RAFT. Effectively using Raft for the coordination service and CRAQ for k/v storage.
How does Artillery maintain chain metadata for the cluster? Or is it only using epidemic protocals to distribute metadata?
The text was updated successfully, but these errors were encountered:
After discovering this project, I then found the CRAQ paper and began reading it. In that paper, I noticed this paragraph:
I've noticed in other implementations of CRAQ, I've seen them replace ZooKeeper with protocols like RAFT. Effectively using Raft for the coordination service and CRAQ for k/v storage.
How does Artillery maintain chain metadata for the cluster? Or is it only using epidemic protocals to distribute metadata?
The text was updated successfully, but these errors were encountered: