关于Curator/Zookeeper实现发布订阅模式的经验与示例疑问

First: What does "it is not meant for production" actually mean? #

That note applies only to the example code, not the pub-sub pattern itself when implemented with Curator/ZooKeeper. The official example is a stripped-down demo to show you the core mechanics of using Curator's pub-sub tools (like CuratorFramework and PathChildrenCache), but it skips all the critical production-grade safeguards you’d need, such as:

• Robust retry policies for handling ZooKeeper session drops or reconnections
• Proper resource cleanup (closing caches and client connections when they’re no longer needed)
• Monitoring, logging, and metrics to track system health
• Throttling to prevent overwhelming the ZooKeeper cluster
• Authentication/authorization for securing znode paths

You absolutely can use Curator/ZooKeeper for pub-sub in production—you just need to build on the example’s core logic with these production requirements in mind.

Pros of Using Curator/ZooKeeper for Pub-Sub #

• Native distributed coordination: Since ZooKeeper is built for consensus, your pub-sub system gets out-of-the-box support for cluster membership, leader election, and consistent state across all publishers and subscribers.
• Strong consistency: Messages stored as znode data are replicated across the ZooKeeper quorum, so all subscribers see the exact same state once a publish is confirmed.
• Curator’s simplified abstractions: Curator takes ZooKeeper’s low-level, error-prone Watcher API (which only triggers once) and wraps it into user-friendly tools like PathChildrenCache (for tracking child node changes) and higher-level pub-sub helpers—saving you from writing tons of boilerplate.
• No extra middleware overhead: If you already run a ZooKeeper cluster for other tasks (like service discovery), you don’t need to deploy a separate message broker just for pub-sub.
• Built-in fault tolerance: ZooKeeper’s quorum model ensures your pub-sub system stays available as long as a majority of nodes are up and running.

Cons (Beyond the 1MB Znode Size Limit) #

• High write latency: ZooKeeper prioritizes consistency over speed—every publish (which creates or updates a znode) requires consensus across the quorum, leading to much higher latency than dedicated message brokers like Kafka or RabbitMQ.
• Low throughput: ZooKeeper isn’t built for high-volume message streams; it struggles to handle thousands of publishes or subscribes per second without performance degradation.
• Watcher edge cases: While Curator’s caches fix the single-shot Watcher problem, you still have to handle tricky scenarios like cache sync failures after reconnections. Too many subscribers can also put significant strain on ZooKeeper’s resources.
• Limited message retention: Unlike dedicated brokers, ZooKeeper doesn’t offer built-in message retention policies. If a subscriber is offline for a while, they’ll miss messages unless you implement custom persistence (which adds complexity).
• Session management headaches: You have to carefully handle ZooKeeper session timeouts, reconnection logic, and cache re-syncs—misconfiguring these can lead to missed messages or inconsistent state across subscribers.
• Scalability limits: Adding more ZooKeeper nodes helps with fault tolerance, but it doesn’t linearly improve throughput for pub-sub operations. The cluster can only handle so many concurrent znode changes.

内容的提问来源于stack exchange，提问作者Erikson