摘要
看到这篇文章，很有借鉴意义，因此写个读书笔记，不算是翻译。想要深入了解，请看原文http://tech.trivago.com/2017/01/25/learn-redis-the-hard-way-in-production/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website
使用场景
旅店搜索应用，使用redis来做缓冲，以及作为将数据搬到其他存储或者传统意义的数据库之前的一个临时存储。数据主要是旅店元数据以及数据的持久化
问题
发布了一些新功能，平台上增加了一些新的语言。然后HTTP请求在短时间内翻倍了。因为硬件方面的高可用性，能够处理这些增长。但是近来的请求有40%response是HTTP 500: Internal Server Error.
查看日志发现，这和redis connection处理有关，大部分是redis error on connection 以及 redis server went away.
google 一下发现有相关的issue了。
debug read error on connection
Debugging 来解决问题
首先尝试了issue中给出的建议，但是没有用。而且这些问题只出现在高并发情况下。
在web请求结束关闭redis connection
没有使用php-fpm以及持久化连接。意味着每一个HTTP请求都会创建一个新的Redis连接，打开了一个连接，但是从来没有关闭它。
在最新的PHP版本中，PHP会自动关闭连接。
注：
不了解PHP，没使用php-fpm。但是这个错误不应该放，数据库的连接不关闭，一个请求创建一个新的连接。这样很容易导致内存泄漏，OOM。不清楚为什么系统运行了三年还没有发现这个问题。
A/B 测试 connections libraries
怀疑是phpredis(php extension)的bug。将C extension退回到predis包。发现仍然有问题。
升级redis
从redis2.6升级到redis2.8.9还是有问题
Debugging 延迟问题
Watchdog
来debug 延迟问题。为了识别出长时间跑的以及阻塞的命令
建议
Redis是单线程的，所以每一个命令都有可能阻塞其他命令。这点一定要牢记于心。虽然是显而易见的特性，但是常常被忽略，而且这是很多问题的根本
使用了Watchdog后，遇到了个bug，redis server down掉了。
redis crashes during rdb save point
看了下redis baseline 延迟，一切正常
redis-cli --latency -p 6380 -h 1.2.3.4
min: 0, max: 463, avg: 2.03 (19443 samples)查看了redis log,发现redis每隔一分钟将数据保存到磁盘中。
[20398] 22 May 09:25:23.299 * 10000 changes in 60 seconds. Saving...
[20398] 22 May 09:25:23.644 * Background saving started by pid 42027第一个问题是为什么一个后台保存进程的fork需要400+ms.
因为需要复制page table
因此如果你有个大的Redis实例有很多keys，就会需要很多时间去完成。详情看这篇Fork time in different systems
后面讲Redis snapshot关掉了，因为services不需要这样的持久化。这样做法将读错误降低了30%。
建议
review下你对redis持久化的需求以及redis配置。应用是否会更改很多的keys，考虑使用AOF或者定时的BGSAVE作为持久化方案，而不是标准的snapshotting。
我们错误的根源就在于此。读和写keys，不想全面的禁掉持久化。因此使用一个定时任务去调用BGSAVE命令。将这些任务放在slave实例上。对于持久化要求更高的场合，使用AOF。
这样的一个改变，里面降低了timeout/error的问题。但是仍然会看到有错误抛出。