这个 slave 不处理真实的流量请求，唯一的作用就是处理持久化，把之前 Redis 实例上的持久化操作转移到这个 slave 上
效果非常明显，问题基本解决，但有的时候还是会报错
第7次
排查可能阻塞 Redis 的慢查询，发现有地方使用了 keys *
因为 Redis 中的数据越来越多，这个命令自然会产生严重阻塞
可以使用 scan 进行替换
第8次
经过前面的调整，问题已经解决，随后的几个月，即使流量在不断增长，也都抗住了
但他们意识到了新的问题：
现在的方式是，来一个请求就创建一个 Redis 连接，执行几个命令，然后再断开连接，在请求量很大时，这个方式产生了严重的性能浪费，一半以上的命令是用来处理连接操作的，这都超过了业务逻辑上的处理，也使 Redis 变慢
解决方法：引入 proxy，他们选择了 twitter 的 twemproxy，只需要在每个 webserver 上安装代理，twemproxy负责与 Redis 实例进行持久连接，这样就大大减少了连接方面的操作
twemproxy还有两个方便的地方：
支持 memcached
可以阻止非常耗时或者危险的命令，例如 keys、flushall
效果自然很完美，再也不用担心之前的连接错误
第9次
通过数据分片来继续优化：
对不同上下文的数据拆分隔离
对相同上下文的数据进行一致性哈希分片
效果：
减少了每台机器上的请求、负载
提升了缓存的可靠性，不担心节点故障
小结
原文作者写的非常好，详细的描述了他们在 Redis 应用上的成长历程，是很值得参考的实践经验
原文地址http://tech.trivago.com/2017/01/25/learn-redis-the-hard-way-in-production
