Join us for RedisConf and Hackathon, April 20-21
In this chapter we’ve gone through six major topics, but in looking at those topics, we
actually solved nine different problems. Whenever possible, we’ve taken steps to borrow
ideas and functionality from previous sections to keep building more useful tools,
while trying to highlight that many of the techniques that we use in one solution can
also be used to solve other problems.
If there’s one concept that you should take away from this entire chapter, it’s that
although WATCH is a useful command, is built in, convenient, and so forth, having
access to a working distributed lock implementation from section 6.2 can make concurrent
Redis programming so much easier. Being able to lock at a finer level of detail
than an entire key can reduce contention, and being able to lock around related operations
can reduce operation complexity. We saw both performance improvements and operation simplicity in our revisited marketplace example from section 4.6, and in
our delayed task queue from section 6.4.2.
If there’s a second concept that you should remember, take to heart, and apply in
the future, it’s that with a little work, you can build reusable components with Redis.
We reused locks explicitly in counting semaphores, delayed task queues, and in our
multiple-recipient pub/sub replacement. And we reused our multiple-recipient pub/
sub replacement when we distributed files with Redis.
In the next chapter, we’ll continue with building more advanced tools with Redis,
writing code that can be used to back entire applications from document indexing
and search with scored indexing and sorting, all the way to an ad targeting system, and
a job search system. Going forward, we’ll reuse some of these components in later
chapters, so keep an eye out, and remember that it’s not difficult to build reusable
components for Redis.