美团在Redis上踩过的一些坑-1.客户端周期性出现connect timeout

    1. 背景:

      大部分互联网公司都会有Mysql或者Oracle的DBA,但是在Nosql方面一般不会设置专门的DBA。不过对于一些知名的互联网公司来说,Nosql的使用量是巨大的,所以通常让Mysql的DBA或者单独聘请工程师来维护一些Nosql数据库,比如:

      Redis, Hbase, Memcache(其实严格讲不是nosql), Mongodb, Cassandra。从讲座看美团网应该是有专职的Redis DBA。所以作为业务开发人员不需要自己安装、配置、运维Redis,只需要找Redis DBA来申请就可以了。

      这里为了简化说明:Redis DBA提供的服务叫做Redis云,业务开发人员叫做业务端(redis的使用者)

      

美团在Redis上踩过的一些坑-1.客户端周期性出现connect timeout_第1张图片

   2. 现象:

       业务端在使用redis云提供的redis服务后,经常出现connect timeout:

Java代码   

收藏代码

  1. redis.clients.jedis.exceptions.JedisConnectionException  
  2. java.net.SocketException  
  3. java.net.SocketTimeoutException:connect time out  

   

   3. 分析和怀疑:

   业务端一般认为redis出现问题,就是redis云有问题,人的“正常”思维:看别人错误容易,发现自己难,扯多了, 出现这个有很多原因:

   (1). 网络原因:比如是否存在跨机房、网络割接等等。

   (2). 慢查询,因为redis是单线程,如果有慢查询的话,会阻塞住之后的操作。 

   (3). value值过大?比如value几十兆,当然这种情况比较少,其实也可以看做是慢查询的一种

   (4). aof重写/rdb fork发生?瞬间会堵一下Redis服务器。

   (5). 其他..................

   4. 查询原因

   演讲者一开始怀疑是网络问题,但是并未发现问题,观察各种对比图表,tcp listenOverFlow和timeout经常周期出现。(赞一下这个监控,我们监控现在还没有这个层面的)

   有关listenOverFlow:

查看现有的连接数是否大于设置的backlog,如果大于就丢弃,并相应的参数值加1。其中backlog是由程序和系统参数net.core.somaxconn共同设置,当backlog的值大于系统设置的net.core.somaxconn时则取net.core.somaxconn的值,否则取程序设置的backlog值。这种出错的方式也被记录在TcpListenOverflows中(其只记录了连接个数不足而产生溢出错误的次数!)。

   觉得可能和TCP相关,于是分析了Tcp三次握手:最后一次握手客户端的请求会进入服务器端的一个队列(可以认为是下三图)中,如果这个队列满了,就会发生上面的异常。(accept)

  (1) TCP三次握手: 

   

美团在Redis上踩过的一些坑-1.客户端周期性出现connect timeout_第2张图片

  (2) redis客户端与redis服务器交互的过程(本质就是TCP请求)

美团在Redis上踩过的一些坑-1.客户端周期性出现connect timeout_第3张图片

  (3) I/O 多路复用程序通过队列向文件事件分派器传送套接字的过程

    

美团在Redis上踩过的一些坑-1.客户端周期性出现connect timeout_第4张图片

   (4) 和redis有什么关系呢?

        由于Redis的单线程模型(对命令的处理和连接的处理都是在一个线程中),如果存在慢查询的话,会出现上面的这种情况,造成新的accept的连接进不了队列。

    

美团在Redis上踩过的一些坑-1.客户端周期性出现connect timeout_第5张图片

    如果上面的图没法理解的话,看看这张图:

      

美团在Redis上踩过的一些坑-1.客户端周期性出现connect timeout_第6张图片

   5. 解决方法:

    (1) 对慢查询进行持久化,比如定时存放到mysql之类。(redis的慢查询只是一个list,超过list设置的最大值,会清除掉之前的数据,也就是看不到历史)

    (2) 对慢查询进行报警(频率、数量、时间)等等因素

    (3) 打屁股,哈哈:

     

     (4) 其实应该做的是:对业务端进行培训,告诉他们一下redis开发的坑,redis不是万金油,这个和Mysql DBA要培训Mysql使用者一样,否则防不胜防。

      比如他执行了 monitor, keys *, flushall, drop table, update table set a=1; 这种也是防不胜防的( 当然也可以做限制,利用rename-command一个随机数),但是提高工程师的水平才是关键。

你可能感兴趣的:(redis,数据库)