title: Redis Read-Replicas On Web Servers
body: <p>I am currently developing a system that makes heavy use of redis for a series of web services. </p>
  
  <p>One of the key criteria of this system is fast responses.</p>
  
  <p>At present the layout (ignoring load balancers etc) is as follows:</p>
  
  <ul>
  <li>2 x Front End Play Framework 2.x Servers</li>
  <li>2 x Job Handling/Persistence Play Framework 2.x Servers</li>
  <li>1 x MySQL Server</li>
  <li>2 x Redis Servers, 1 master, 1 slave</li>
  </ul>
  
  <p>In this setup, redis serves 2 tasks - as a shared cache and also as a message bus.</p>
  
  <p>Currently the front end servers host a service which interacts in its entirety with Redis. </p>
  
  <p>The front end servers try to balance reads across the pool of read servers (currently the master and 1 slave), but being Redis they need to make their writes to the master server. They handle cache updates etc by sending messages on the queues, which are picked up by the job handling servers.</p>
  
  <p>The job handling servers do blocking listens (BLPOP) to the Redis write server and process tasks when necessary. They have the only connection to MySQL.</p>
  
  <p>At present the read replica server is a dedicated server - more there to be able to switch it to write master if the current master fails.</p>
  
  <p>I was thinking of putting a read replica slave of redis on each of the front end servers which means that read latency would be even less, and writes (messages for queues) get pushed to the write server on a separate connection. </p>
  
  <p>If I need to scale, I could just add more front end servers with read slaves.</p>
  
  <p>It sounds like a win/win to me as even if the write server temporarily drops out, the front end servers can still read data at least from their local slave and act accordingly.</p>
  
  <p>Can anyone think of reasons why this might not be such a good idea?</p>