ZooKeeper vs etcd: qual store de coordenação?
O ZooKeeper é um serviço de coordenação consolidado com watches e nós efêmeros; o etcd é um key-value store moderno baseado em Raft com uma API HTTP/gRPC simples.
O ZooKeeper, construído sobre o consenso ZAB, oferece znodes hierárquicos, watches e nós efêmeros, dando poder a muitos sistemas distribuídos mais antigos. O etcd usa Raft, expõe uma API gRPC/HTTP limpa, suporta leases e watch streams, e é o store padrão do Kubernetes. O ZooKeeper vence em dependência de ecossistema legado; o etcd vence em uma API moderna, modelo mais simples e momentum cloud-native.
| ZooKeeper | etcd | |
|---|---|---|
| Consenso | ZAB | Raft |
| API | Bibliotecas de cliente | gRPC / HTTP |
| Modelo | Znodes, watches | KV, leases, watch |
| Ecossistema | Big data legado | Cloud-native / K8s |
| Melhor para | Sistemas ZK existentes | KV/coordenação modernos |
Caso de uso e API
O ZooKeeper serve a sistemas já construídos sobre ele ou que precisam de suas primitivas específicas. O etcd serve a novas necessidades de coordenação e configuração cloud-native com uma API limpa, e é o padrão em ambientes Kubernetes.
Adequação a ops e CI
O etcd tende a ser mais simples de operar e raciocinar do que o ZooKeeper para novos deploys. Ambos são testados via integração no CI contra quóruns efêmeros, onde runners gerenciados mais rápidos encurtam o startup de cluster e os testes de watch/lease.
O veredito
Dá suporte a um sistema existente dependente de ZooKeeper ou precisa de suas primitivas: ZooKeeper. Construindo coordenação cloud-native moderna ou rodando Kubernetes: etcd. Trabalho novo geralmente favorece o etcd; o ZooKeeper perdura sob plataformas legadas.