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

    5.4.1 Using Redis to store configuration information

    To see how generally difficult configuration management can be, we only need to
    look at the simplest of configurations: a flag to tell our web servers whether we’re
    under maintenance. If so, we shouldn’t make requests against the database, and
    should instead return a simple “Sorry, we’re under maintenance; try again later” message
    to visitors. If the site isn’t under maintenance, all of the normal web-serving
    behavior should happen.

    In a typical situation, updating that single flag can force us to push updated configuration
    files to all of our web servers, and may force us to reload configurations on all
    of our servers, if not force us to restart our application servers themselves.

    Instead of trying to write and maintain configuration files as our number of services
    grows, let’s instead write our configuration to Redis. By putting our configuration
    in Redis and by writing our application to fetch configuration information from
    Redis, we no longer need to write tools to push out configuration information and
    cause our servers and services to reload that configuration.

    To implement this simple behavior, we’ll assume that we’ve built a middleware
    layer or plugin like we used for caching in chapter 2 that will return our maintenance
    page if a simple is_under_maintenance() function returns True, or will handle the
    request like normal if it returns False. Our actual function will check for a key called
    is-under-maintenance. If the key has any value stored there, we’ll return True; otherwise,
    we’ll return False. To help minimize the load to Redis under heavy web server
    load (because people love to hit Refresh when they get maintenance pages), we’ll only
    update our information once per second. Our function can be seen in this listing.

    Listing 5.13The is_under_maintenance() function
    LAST_CHECKED = None
    IS_UNDER_MAINTENANCE = False
    
    def is_under_maintenance(conn):
    
       global LAST_CHECKED, IS_UNDER_MAINTENANCE
    
    

    Set the two variables as globals so we can write to them later.

       if LAST_CHECKED < time.time() - 1:
    

    Check to see if it’s been at least 1 second since we last checked.

          LAST_CHECKED = time.time()
    

    Update the last checked time.

          IS_UNDER_MAINTENANCE = bool(
    
             conn.get('is-under-maintenance'))
    
    

    Find out whether the system is under maintenance.

       return IS_UNDER_MAINTENANCE
    

    Return whether the system is under maintenance.

    With that one function plugged into the right place in our application, we could affect
    the behavior of thousands of web servers within 1 second. We chose 1 second to help
    reduce load against Redis for very heavily trafficked web sites, but we can reduce or
    remove that part of the function if our needs require faster updates. This seems like a toy example, but it demonstrates the power of keeping configuration information in a
    commonly accessible location. But what about more intricate configuration options?