6.2 Distributed locking

  • Redis in Action – Home
  • Foreword
  • Preface
  • Part 1: Getting Started
  • 1.1.1 Redis compared to other databases and software
  • 1.1.3 Why Redis?
  • 1.3.2 Posting and fetching articles
  • 1.3.3 Grouping articles
  • 2.1 Login and cookie caching
  • 2.2 Shopping carts in Redis
  • 2.3 Web page caching
  • 2.5 Web page analytics
  • 3.1 Strings
  • 3.2 Lists
  • 3.4 Hashes
  • 3.5 Sorted sets
  • 3.7.1 Sorting
  • 3.7.2 Basic Redis transactions
  • 3.7.3 Expiring keys
  • 4.4 Redis transactions
  • 4.5 Non-transactional pipelines
  • 4.7 Summary
  • 5.1 Logging to Redis
  • 5.2 Counters and statistics
  • 5.2.2 Storing statistics in Redis
  • 5.4.1 Using Redis to store configuration information
  • 5.4.2 One Redis server per application component
  • 5.4.3 Automatic Redis connection management
  • 6.1 Autocomplete
  • 6.2 Distributed locking
  • 6.3 Counting semaphores
  • 6.6 Distributing files with Redis
  • 6.2.1 Why locks are important
  • 6.2.2 Simple locks
  • 6.2.3 Building a lock in Redis
  • 6.2.5 Locks with timeouts
  • 6.3.2 Fair semaphores
  • 6.3.4 Preventing race conditions
  • 6.5.1 Single-recipient publish/subscribe replacement
  • 6.5.2 Multiple-recipient publish/subscribe replacement
  • 6.6.2 Sending files
  • 7.1 Searching in Redis
  • 7.2 Sorted Indexes
  • 7.5 Summary
  • 7.1.2 Sorting search results
  • 8.1.1 User information
  • 8.5.1 Data to be streamed
  • 9.2.2 SETs
  • 9.4 Summary
  • Chapter 11: Scripting Redis with Lua
  • 11.1.1 Loading Lua scripts into Redis
  • 11.2 Rewriting locks and semaphores with Lua
  • 11.5 Summary
  • 11.2.1 Why locks in Lua?
  • 11.2.2 Rewriting our lock
  • B.1 Forums for help
  • Buy the paperback
  • Redis in Action – Home
  • Foreword
  • Preface
  • Part 1: Getting Started
  • 1.1.1 Redis compared to other databases and software
  • 1.1.3 Why Redis?
  • 1.3.2 Posting and fetching articles
  • 1.3.3 Grouping articles
  • 2.1 Login and cookie caching
  • 2.2 Shopping carts in Redis
  • 2.3 Web page caching
  • 2.5 Web page analytics
  • 3.1 Strings
  • 3.2 Lists
  • 3.4 Hashes
  • 3.5 Sorted sets
  • 3.7.1 Sorting
  • 3.7.2 Basic Redis transactions
  • 3.7.3 Expiring keys
  • 4.4 Redis transactions
  • 4.5 Non-transactional pipelines
  • 4.7 Summary
  • 5.1 Logging to Redis
  • 5.2 Counters and statistics
  • 5.2.2 Storing statistics in Redis
  • 5.4.1 Using Redis to store configuration information
  • 5.4.2 One Redis server per application component
  • 5.4.3 Automatic Redis connection management
  • 6.1 Autocomplete
  • 6.2 Distributed locking
  • 6.3 Counting semaphores
  • 6.6 Distributing files with Redis
  • 6.2.1 Why locks are important
  • 6.2.2 Simple locks
  • 6.2.3 Building a lock in Redis
  • 6.2.5 Locks with timeouts
  • 6.3.2 Fair semaphores
  • 6.3.4 Preventing race conditions
  • 6.5.1 Single-recipient publish/subscribe replacement
  • 6.5.2 Multiple-recipient publish/subscribe replacement
  • 6.6.2 Sending files
  • 7.1 Searching in Redis
  • 7.2 Sorted Indexes
  • 7.5 Summary
  • 7.1.2 Sorting search results
  • 8.1.1 User information
  • 8.5.1 Data to be streamed
  • 9.2.2 SETs
  • 9.4 Summary
  • Chapter 11: Scripting Redis with Lua
  • 11.1.1 Loading Lua scripts into Redis
  • 11.2 Rewriting locks and semaphores with Lua
  • 11.5 Summary
  • 11.2.1 Why locks in Lua?
  • 11.2.2 Rewriting our lock
  • B.1 Forums for help
  • Buy the paperback

    6.2 Distributed locking

    Generally, when you “lock” data, you first acquire the lock, giving you exclusive access to the data. You then perform your operations. Finally, you release the lock to others. This sequence of acquire, operate, release is pretty well known in the context of shared-memory data structures being accessed by threads. In the context of Redis, we’ve been using WATCH as a replacement for a lock, and we call it optimistic locking, because rather than actually preventing others from modifying the data, we’re notified if someone else changes the data before we do it ourselves.

    With distributed locking, we have the same sort of acquire, operate, release operations, but instead of having a lock that’s only known by threads within the same process, or processes on the same machine, we use a lock that different Redis clients on different machines can acquire and release. When and whether to use locks or WATCH will depend on a given application; some applications don’t need locks to operate correctly, some only require locks for parts, and some require locks at every step.

    One reason why we spend so much time building locks with Redis instead of using operating system–level locks, language-level locks, and so forth, is a matter of scope. Clients want to have exclusive access to data stored on Redis, so clients need to have access to a lock defined in a scope that all clients can see—Redis. Redis does have a basic sort of lock already available as part of the command set (SETNX), which we use, but it’s not full-featured and doesn’t offer advanced functionality that users would expect of a distributed lock.

    Throughout this section, we’ll talk about how an overloaded WATCHed key can cause performance issues, and build a lock piece by piece until we can replace WATCH for some situations.