gitee.com/woood2/luca@v1.0.4/test/reconnect.md (about)

     1  ### 测试内容
     2  针对依赖的外部组件，关闭一段时间，然后重启，观察Go框架能否脱离人工干预自动重连
     3  
     4  ### consul
     5  - client有缓存机制，即使consul关闭阶段，也不影响gRPC请求
     6  - consul关闭阶段，client定期轮询server状态的请求失败，并打印日志
     7  - consul重启后client与server能够自动恢复正常
     8  
     9  ### mysql
    10  - mysql关闭时，gorm框架输出一条日志：closing bad idle connection: EOF
    11  - mysql关闭阶段，执行sql语句会立即返回err，输出日志： dial tcp [::1]:3306: connect: connection refused
    12  - mysql重启后，执行sql语句恢复正常，说明gorm库能够自动恢复连接
    13  
    14  ### mongo
    15  - mongo关闭时，执行insert操作，等待较长时间之后返回err: dial tcp [::1]:27017: connect: connection refused
    16  - 在具体的insert语句上，传入带有1秒timeout的context对象，能够快速返回err
    17  - mongo重启后，执行insert操作恢复正常，说明mongo-driver库能够自动恢复连接
    18  
    19  ### redis
    20  - redis关闭时，执行cmd立即返回err：dial tcp 127.0.0.1:6379: connect: connection refused
    21  - redis关闭时，cron主实例因为无法续签终止进程，cron副实例不断竞选保持进程
    22  - redis重启后，cron副实例竞选成功，恢复正常，说明go-redis库能够自动恢复连接
    23  
    24  ### kafka
    25  - kafka关闭时，sendMessage立即输出日志并返回err：kafka: client has run out of available brokers to talk to (Is your cluster reachable?)
    26  - kafka重启后，sendMessage保持一段时间断路状态（自带断路器），随后恢复正常，说明producer能够自动恢复连接
    27  - kafka关闭时，consumerGroup.Consume方法会退出，反复重试，直到kafka重启，这段逻辑是我在consumer入口DIY的
    28  
    29  ### zipkin
    30  - zipkin关闭时，框架会不断重试，并且输出日志：failed to send the request: Post "http://10.78.202.136:9411/api/v2/spans": dial tcp [::1]:9411: connect: connection refused
    31  - zipkin重启后，自动恢复正常
    32  - zipkin在生产环境默认使用NewNoopReporter，更没影响了