Dubbo之connet timeout问题排查

一 背景
    购物车依赖推荐的dubbo接口，推荐服务每天凌晨3点会批量下线推荐dubbo服务，全量更新商品，更新完以后在执行上线操作，每天凌晨3点10分左右，购物车工程都会出现5000左右的connection timeout error。正常依赖的dubbo服务工程在启动的时候，消费端会经常出现connection timeout error。





二 问题排查
    遇到问题之后，sa，中间件开发，推荐开发，购物车开发等拉群排查问题，分析影响面。
    dubbo源码分析


总结：推荐服务上线之后，消费端收到zookeeper通知，会主动拉取推荐dubbo服务的URL信息。消费端拿到URL信息后，如果connections不配置，则共享连接，否则每服务每连接，然后将该服务URL和clinets列表封装成一个DubboInvoker对象。如果connection timeout下次会重试。

   哨兵监控分析



    我们发现在connection timeout error出现的时候，推荐服务器TcpExtListenOverflows，TcpExtListenDrops指标异常。

    TcpExtListenDrops（监听队列连接丢弃数）和 TcpExtListenOverflows（监听队列连接溢出数）：

• ListenOverflows：3次握手之后进入Accept Queue，如果Accept Queue满了，队列溢出连接就会丢弃，TcpExtListenOverflows值增加1；
• ListenDrops：包含上面的情况，也就是说当出现ListenOverflows时，它也会增加1；除此之外，当内存不够无法为新的连接分配socket相关的数据结构时，也会增加1，当然还有别的异常情况下会增加1。

    Accept Queue 的队列长度是由程序的backlog和系统参数net.core.somaxconn共同设置，当backlog的值大于系统设置的net.core.somaxconn时则取net.core.somaxconn的值，否则取程序设置的backlog值。

总结：net.core.somaxconn默认值是128，dubbo backlog目前1024， min(net.core.somaxconn, backlog) = 128。推荐一个服务的提供者的消费者就由1600多，推荐服务一上线，消费者都是第一时间去建立连接，导致Accept Queue溢出。
参考：SYN packet handling in the wild

三 解决问题
    问题已经分析完成，解决的思路：

1. 增加云主机net.core.somaxconn值和dubbo backlog值。
2. 修改dubbo源码，服务提供者一上线，消费者延迟随机时间之后去建立连接。

    目前所有云主机同步参数net.core.somaxconn调整到2048，dubbo backlog默认值还是1024，需要压测确定具体值，connection timeout error已经由原先的6000降低到200，connection timeout之后会重试连接，不会影响业务功能。