Database Reference
In-Depth Information
} else {
System. out .println(arg0.getType());
System. out .println(arg0.getPath());
}
}
}).forPath("/a/test/path");
Curator Recipes
In addition to implementing a robust and easy-to-use ZooKeeper client,
Curator goes the extra mile by providing implementations of many of the
recipes found on the ZooKeeper site.
The recipes as given in this section are essentially skeletons, primarily
provided to give clear examples of working with ZooKeeper in common
situations. The Curator recipes take these basic skeletons and make them
robust, and often more feature-rich, for use in production environments.
They provide an excellent starting point for implementing high-level logic
based on these common algorithmic structures.
This section covers using some of the various recipes, which includes
everything from the recipes section of the ZooKeeper website except the
Multi-Version Concurrency Control implementation. In some cases, such as
the Distributed Queue implementation, extensions to the basic algorithm
not found on the ZooKeeper site are added.
Distributed Queues
The Curator website has a document called “Technical Note 4” that states
that ZooKeeper is a terrible system for implementing queues. The reasons
given include ZooKeeper's relatively small node payload, the need to keep
the entire dataset in memory, and performance issues when a znode has a
very large number of children.
In one sense, this is entirely correct. ZooKeeper would be a very poor choice
for handling queues in an environment with a high message volume. A
dedicatedqueuemanagementsystemsuchasActiveMQorRabbitMQwould
be more appropriate in that situation. In a very high-volume environment,
a data motion system like those discussed in the next chapter is even more
appropriate. However, for something like a job queue where relatively few
items are parceled out to worker nodes, ZooKeeper can be a good and fairly
lightweight solution.
Search WWH ::




Custom Search