Live data from Hacker News

Cloudflare Meerkat - Globally distributed consensus

blog.cloudflare.com

51–58 of 58 posts

Re: Cloudflare Meerkat - Globally distributed consensus

#51
post #50
post #47

Earlier quoted context omitted.

> I think all big cloud providers replaced etcd with a custom in house implementation in their K8s offerings for this reason This is incorrect. AWS, Azure, GCP still use etcd in their customer kubernetes services. "EKS Ultra Scale" uses an in-house Journal

GKE uses spanner (with an etcd API layer) per the docs. https://docs.cloud.google.com/kubernetes-engine/docs/concept... https://cloud.google.com/blog/products/containers-kubernetes...

TIL!

Re: Cloudflare Meerkat - Globally distributed consensus

#55
post #46

This sounds like a very direct approach to linearizability - just put everything in a linear order. But this includes READ operations too! You have to get global consensus for every read! Most distributed systems have additional complexity and latency on write paths so that reads can be completely local. If you can accept slow read operations this seems like a great trade off, but I think that is going to relegate th…

The article says that if your read hits a master there’s no consensus needed. Perhaps I read wrong

The system seems to have no master or leader at all. Where in the article did you get that reads from a master have no consensus?

Of course, you could build database that uses meerkat to do leader election, and then neither reads nor writes need to go through the consensus algo. But then you've basically just reproduced conventional distributed db, and you're back to the timeout problems this was supposed to solve.

Re: Cloudflare Meerkat - Globally distributed consensus

#56
post #46

Earlier quoted context omitted.

The article says that if your read hits a master there’s no consensus needed. Perhaps I read wrong

The system seems to have no master or leader at all. Where in the article did you get that reads from a master have no consensus? Of course, you could build database that uses meerkat to do leader election, and then neither reads nor writes need to go through the consensus algo. But then you've basically just reproduced conventional distributed db, and you're back to the timeout problems this was supposed to solve.

> We chose a different consensus algorithm for Meerkat, called QuePaxa, that aims to avoid the “tyranny of timeouts” imposed by protocols like Raft. QuePaxa is a subtle protocol, but here are the highlights. A client can contact any replica, and that replica can drive consensus for the latest slot. There is a leader, but it is not required — its only advantage is that it can drive consensus with fewer round trips (one) than other replicas (3+). Critically, clients are free to contact multiple replicas concurrently for the same proposal, to increase the chance of the proposal being successful. Concurrent proposals do not destructively interfere: replicas work together to decide one of the proposed values.

Re: Cloudflare Meerkat - Globally distributed consensus

#57
post #46

Earlier quoted context omitted.

The article says that if your read hits a master there’s no consensus needed. Perhaps I read wrong

The system seems to have no master or leader at all. Where in the article did you get that reads from a master have no consensus? Of course, you could build database that uses meerkat to do leader election, and then neither reads nor writes need to go through the consensus algo. But then you've basically just reproduced conventional distributed db, and you're back to the timeout problems this was supposed to solve.

They say they have leaders but don’t need them
Post reply on HN