redis的read error on connection错误解决

    昨日，公司php调用redis报错：read error on connection 2015-01-29 23:59:050.13330000，redis存放的是用户session。

    在网上查询，你们说法都比较一致，说是php.ini文件中的一个配置项致使：

    default_socket_timeout = 60

    因为redis扩展也是基于php 的socket方式实现，所以该参数值一样会起做用。

解决方法是：

    一、直接修改php.ini，将其设置为咱们想要的值（这个不推荐）

    二、在咱们的脚本中经过如下方式设置，这样就比较灵活，不对其余脚本产生影响

ini_set('default_socket_timeout', -1);  //不超时

 

    可是，一看，修改的两个参数，一个是php的全局参数，一个是redis的超时操做，都应该按照实际状况来修改，并且，设置超长超时时间或者不超时都是不合理的；

 

    继续检查redis发现，/usr/local/redis_16379/src/redis-cli -p 16379 info（服务器配置的redis端口为16379，分配内存为8000M）

used_memory_human:7.49G，占用内存已经7.49G

db10:keys=53090286，键值5000多万

    居然是键值占满了内存，检查php的调用代码，发现php居然没有设置redis的键值过时时间，修改php代码，对键值设置过时时间

 

    设置完以后，发现以前的键值由于没有设置过时时间，程序不会自动删除，因而用脚本删除主redis上对应的session，

/usr/local/redis_16379/src/redis-cli -p 16379 -n 10 keys "PHPSESSION_wc*" | xargs /usr/local/redis_16379/src/redis-cli -p 16379 -n 10 del

将大部分过时数据删除掉，删除必定数量的数据以后，报错消失，redis链接正常。

 

    可是，发现redis主从，在这样删除以后，从数据居然没有同步，主的数据和从数据差距有400多万不一致，也没有再发现bgsave操做，查看从日志Trying a partial resynchronization，发现由于过滤keys占用太多资源，形成服务器负载飙升，slave断开与主机的链接，须要从积压空间中找回断开期间的数据更新记录。可是由于删除数据太多，断开的时间足够长，master 拒绝 slave 的部分同步请求，从而 slave 只能进行全同步。

至此，在slave上对数据进行全量同步，数据恢复正常，业务正常。

 

须要注意几点：

    1.redis数据，正常状况下，设置过时时间，不然可能出现，存储键值过多，占用完了预设内存，致使新的键值没法存储，调用redis失败的；

    2.超时时间必须根据实际业务来设置；

    3.若是slave一直链接不上master，可能须要进行全量同步。