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

    4.4 Redis transactions

    Part of keeping our data correct is understanding that when other clients are working
    on the same data, if we aren’t careful, we may end up with data corruption. In this section,
    we’ll talk about using Redis transactions to prevent data corruption and, in some
    cases, to improve performance.

    Transactions in Redis are different from transactions that exist in more traditional
    relational databases. In a relational database, we can tell the database server BEGIN, at
    which point we can perform a variety of read and write operations that will be consistent
    with respect to each other, after which we can run either COMMIT to make our
    changes permanent or ROLLBACK to discard our changes.

    Within Redis, there’s a simple method for handling a sequence of reads and writes
    that will be consistent with each other. We begin our transaction by calling the special
    command MULTI, passing our series of commands, followed by EXEC (as introduced in
    section 3.7.2). The problem is that this simple transaction doesn’t actually do anything
    until EXEC is called, which means that we can’t use data we read to make decisions until
    after we may have needed it. This may not seem important, but there’s a class of problems
    that become difficult to solve because of not being able to read the data in a consistent
    fashion, or allow for transactions to fail where they should succeed (as is the case
    when we have MULTIple simultaneous transactions against a single object when using twophase
    commit, a common solution to the problem). One of these problems is the process
    of purchasing an item from a marketplace. Let’s see an example of this in action.

    Redis’s delaying execution of commands until EXEC is called when using MULTI/
    EXEC, many clients (including the Python client that we’re using) will hold off
    on even sending commands until all of them are known. When all of the commands
    are known, the client will send MULTI, followed by the series of commands
    to be executed, and EXEC, all at the same time. The client will then wait
    until all of the replies from all of the commands are received. This method of
    sending multiple commands at once and waiting for all of the replies is generally
    referred to as pipelining, and has the ability to improve Redis’s performance
    when executing multiple commands by reducing the number of network round
    trips that a client needs to wait for.

    In the last few months, Fake Game Company has seen major growth in their webbased
    RPG that’s played on YouTwitFace, a fictional social network. Because it pays
    attention to the needs and desires of its community, it has determined that the players
    need the ability to buy and sell items in a marketplace. It’s our job to design and build
    a marketplace that can scale to the needs of the community.