A ZooKeeper Layer for FoundationDB
Talkat FoundationDB Summit 2019 · on Monday, 2019-11-18· at 14:50· Grand Ballroom 8, Marriott Marquis San Diego Marina·
summary
A proof‑of‑concept replaces ZooKeeper by mapping ZK nodes to the FoundationDB Directory Layer, emulates ZK watches by appending ordered notifications into a per-client event log and signaling via FDB watches, and uses version stamps for total ordering and session IDs. Ephemeral nodes tie to persisted heartbeats and a lightweight cleanup election runs by transaction conflicts. Implementation runs Apache Curator recipes but remains experimental and not yet production-ready.
AI-written summary · about
chapters (24)
- 0:00Intro
- 0:34Typical Zookeeper Usage
- 1:40Zookeeper Performance
- 2:26FoundationDB Performance
- 2:52Why a ZK Layer?
- 3:15Secret ZK Recipe for Configuration
- 3:53Secret ZK Recipe for Synchronization
- 4:43ZK Data Model
- 5:07Filesystems: The Lazy Way
- 5:36ZK Guarantees: Seq. Consistency
- 6:19FDB Guarantees: Strict Serializability
- 6:41Watch Semantics
- 8:03Watches: Understanding ZK
- 8:45Building the Watch Event Log
- 9:58Notifying the Client
- 11:28Building the Log Completed
- 11:58What We Need to Build on FDB
- 12:54Sessions: Heartbeats
- 13:15Sessions: Detecting Disconnects
- 13:32Persisting Sessions
- 14:04Cleaning Up Sessions
- 15:10Session Cleanup Mini-Elections
- 16:20Session State Wrap-Up
- 17:51Mini-Elections: Picking a Leader
related talks
25mFoundationDB Document Layer
46mFoundationDB: The Best-Kept Secret of New Distributed Architectures!
22mSolving Everyday Data Problems with FoundationDB
37mTechnical Overview of FoundationDB
34mFoundationDB, the Black Knight
22mIntroducing Zelos - Zookeeper API leveraging Delos
36mUnder-The-Hood of Druid without Zookeeper on Kubernetes
21mBuild distributed persistent queue on FoundationDB