Join us for RedisConf and Hackathon, April 20-21
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.
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.