4.4 Redis transactions

  • 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.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.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

    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 two phase 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.

    DELAYED EXECUTION WITH MULTI/EXEC CAN IMPROVE PERFORMANCEBecause of 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.