e-Book - Redis in Action

This book covers the use of Redis, an in-memory database/data structure server.
  • Foreword
  • Preface
  • Acknowledgments
  • About this Book
  • About the Cover Illustration
  • Part 1: Getting Started
  • Part 2: Core concepts
  • Part 3: Next steps
  • Appendix A
  • Appendix B
    • Buy the paperback

    6.2.2 Simple locks

    In our first simple version of a lock, we’ll take note of a few different potential failure
    scenarios. When we actually start building the lock, we won’t handle all of the failures
    right away. We’ll instead try to get the basic acquire, operate, and release process
    working right. After we have that working and have demonstrated how using locks can
    actually improve performance, we’ll address any failure scenarios that we haven’t
    already addressed.

    While using a lock, sometimes clients can fail to release a lock for one reason or
    another. To protect against failure where our clients may crash and leave a lock in the
    acquired state, we’ll eventually add a timeout, which causes the lock to be released
    automatically if the process that has the lock doesn’t finish within the given time.

    Many users of Redis already know about locks, locking, and lock timeouts. But
    sadly, many implementations of locks in Redis are only mostly correct. The problem
    with mostly correct locks is that they’ll fail in ways that we don’t expect, precisely when
    we don’t expect them to fail. Here are some situations that can lead to incorrect
    behavior, and in what ways the behavior is incorrect:

    • A process acquired a lock, operated on data, but took too long, and the lock was automatically released. The process doesn’t know that it lost the lock, or may even release the lock that some other process has since acquired.
    • A process acquired a lock for an operation that takes a long time and crashed. Other processes that want the lock don’t know what process had the lock, so can’t
      detect that the process failed, and waste time waiting for the lock to be released.
    • One process had a lock, but it timed out. Other processes try to acquire the lock simultaneously, and multiple processes are able to get the lock.
    • Because of a combination of the first and third scenarios, many processes now hold the lock and all believe that they are the only holders.

    Even if each of these problems had a one-in-a-million chance of occurring, because
    Redis can perform 100,000 operations per second on recent hardware (and up
    to 225,000 operations per second on high-end hardware), those problems can come
    up when under heavy load,1 so it’s important to get locking right.

    Previous
    Next