title: GitHub's Redis and Resque failure behavior?
body: <p>Anyone have any insight into how GitHub deals with the potential failure or temporary unavailability of a Redis server when using Resque?</p>
  
  <p>There are others that seem to have put together semi-complicated solutions as a holdover for redis-cluster using zookeeper (see <a href="https://github.com/ryanlecompte/redis_failover" rel="nofollow noreferrer">https://github.com/ryanlecompte/redis_failover</a> and <a href="https://stackoverflow.com/questions/7759572/solutions-for-resque-failover-redis">Solutions for resque failover redis</a>). Others seem to have 'poor mans failover' that switches the slave to the master on first sight of connectivity issues without coordination between redis clients (but this seems problematic in the temporary unavailability scenario).</p>
  
  <p>The question: Has Defunkt ever talked about how GitHub handles Redis failure? Is there a best practice for failover that doesn't involve zookeeper?</p>
  
  <p>The original post on resque states part of the rational for the selection of Redis was the master-slave capability of redis, but the post doesn't describe how GitHub leverages this since all workers need both read+write access to Redis (see <a href="https://github.com/blog/542-introducing-resque" rel="nofollow noreferrer">https://github.com/blog/542-introducing-resque</a>).</p>