设为首页 收藏本站
查看: 1485|回复: 0

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

[复制链接]

尚未签到

发表于 2016-12-21 08:23:54 | 显示全部楼层 |阅读模式
   转载请注明出处哈:http://carlosfu.iyunv.com/blog/2254154


    



    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的使用者)

      DSC0000.jpg


   2. 现象:

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

redis.clients.jedis.exceptions.JedisConnectionException
java.net.SocketException
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三次握手: 

   DSC0001.jpg


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

DSC0002.jpg

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

    DSC0003.jpg


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

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

    DSC0004.jpg


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

      DSC0005.jpg


 

   5. 解决方法:

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

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

    (3) 打屁股,哈哈:

     DSC0006.png


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

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

      DSC0007.jpg


参考文献:redis 如何处理客户端连接


 

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-317109-1-1.html 上篇帖子: 单线程你别阻塞,Redis时延问题分析及应对 下篇帖子: Redis 3.0中文官方文档翻译计划(20) ——集群(中)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表