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.2 Replication

    Over their years of scaling platforms for higher loads, engineers and administrators
    have added replication to their bag of tricks to help systems scale. Replication is a
    method by which other servers receive a continuously updated copy of the data as it’s
    being written, so that the replicas can service read queries. In the relational database
    world, it’s not uncommon for a single master database to send writes out to multiple
    slaves, with the slaves performing all of the read queries. Redis has adopted this
    method of replication as a way of helping to scale, and this section will discuss configuring
    replication in Redis, and how Redis operates during replication.

    Though Redis may be fast, there are situations where one Redis server running
    isn’t fast enough. In particular, operations over SETs and ZSETs can involve dozens of
    SETs/ZSETs over tens of thousands or even millions of items. When we start getting
    millions of items involved, set operations can take seconds to finish, instead of milliseconds
    or microseconds. But even if single commands can complete in 10 milliseconds,
    that still limits us to 100 commands/second from a single Redis instance.

    EXAMPLE PERFORMANCE FOR SUNIONSTOREAs a point to consider for the
    performance to expect from Redis, on a 2.4 GHz Intel Core 2 Duo, Redis
    will take 7–8 milliseconds to perform a SUNIONSTORE of two 10,000-item SETs
    that produces a single 20,000 item SET.

    For situations where we need to scale out read queries, or where we may need to write
    temporary data (we’ll talk about some of those in chapter 7), we can set up additional
    slave Redis servers to keep copies of our dataset. After receiving an initial copy of the
    data from the master, slaves are kept up to date in real time as clients write data to the
    master. With a master/slave setup, instead of connecting to the master for reading
    data, clients will connect to one of the slaves to read their data (typically choosing
    them in a random fashion to try to balance the load).

    Let’s talk about configuring Redis for master/slave operation, and how Redis behaves during the entire process.