我的编程空间,编程开发者的网络收藏夹
学习永远不晚

golang fasthttp的踩坑分析

短信预约 -IT技能 免费直播动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

golang fasthttp的踩坑分析

这篇文章主要讲解了“golang fasthttp的踩坑分析”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“golang fasthttp的踩坑分析”吧!

一个简单的系统,结构如下:

golang fasthttp的踩坑分析

我们的服务A接受外部的http请求,然后通过golang的fasthttp将请求转发给服务B,流程非常简单。线上运行一段时间之后,发现服务B完全不再接收任何请求,查看服务A的日志,发现大量的如下错误

golang fasthttp的踩坑分析

  从错误原因看是因为连接被占满导致的。进入服务A的容器中(服务A和服务B都是通过docker启动的),通过netstat -anlp查看,发现有大量的tpc连接,处于ESTABLISH。我们采用的是长连接的方式,此时心里非常疑惑:1. fasthttp是能够复用连接的,为什么还会有如此多的TCP连接,2.为什么这些连接不能够使用了,出现上述异常,原因是什么?

  从fasthttpclient源码出发,我们调用请求转发的时候是用的是

f.Client.DoTimeout(req, resp, f.ExecTimeout),其中f.Client是一个fasthttp.HostClient,f.ExecTimeout设置的是5s。
追查代码,直到client.go中的这个方法

func (c *HostClient) doNonNilReqResp(req *Request, resp *Response) (bool, error) {    if req == nil {        panic("BUG: req cannot be nil")    }    if resp == nil {        panic("BUG: resp cannot be nil")    }     atomic.StoreUint32(&c.lastUseTime, uint32(time.Now().Unix()-startTimeUnix))     // Free up resources occupied by response before sending the request,    // so the GC may reclaim these resources (e.g. response body).    resp.Reset()     // If we detected a redirect to another schema    if req.schemaUpdate {        c.IsTLS = bytes.Equal(req.URI().Scheme(), strHTTPS)        c.Addr = addMissingPort(string(req.Host()), c.IsTLS)        c.addrIdx = 0        c.addrs = nil        req.schemaUpdate = false        req.SetConnectionClose()    }     cc, err := c.acquireConn()    if err != nil {        return false, err    }    conn := cc.c     resp.parseNetConn(conn)     if c.WriteTimeout > 0 {        // Set Deadline every time, since golang has fixed the performance issue        // See https://github.com/golang/go/issues/15133#issuecomment-271571395 for details        currentTime := time.Now()        if err = conn.SetWriteDeadline(currentTime.Add(c.WriteTimeout)); err != nil {            c.closeConn(cc)            return true, err        }    }     resetConnection := false    if c.MaxConnDuration > 0 && time.Since(cc.createdTime) > c.MaxConnDuration && !req.ConnectionClose() {        req.SetConnectionClose()        resetConnection = true    }     userAgentOld := req.Header.UserAgent()    if len(userAgentOld) == 0 {        req.Header.userAgent = c.getClientName()    }    bw := c.acquireWriter(conn)    err = req.Write(bw)     if resetConnection {        req.Header.ResetConnectionClose()    }     if err == nil {        err = bw.Flush()    }    if err != nil {        c.releaseWriter(bw)        c.closeConn(cc)        return true, err    }    c.releaseWriter(bw)     if c.ReadTimeout > 0 {        // Set Deadline every time, since golang has fixed the performance issue        // See https://github.com/golang/go/issues/15133#issuecomment-271571395 for details        currentTime := time.Now()        if err = conn.SetReadDeadline(currentTime.Add(c.ReadTimeout)); err != nil {            c.closeConn(cc)            return true, err        }    }     if !req.Header.IsGet() && req.Header.IsHead() {        resp.SkipBody = true    }    if c.DisableHeaderNamesNormalizing {        resp.Header.DisableNormalizing()    }     br := c.acquireReader(conn)    if err = resp.ReadLimitBody(br, c.MaxResponseBodySize); err != nil {        c.releaseReader(br)        c.closeConn(cc)        // Don't retry in case of ErrBodyTooLarge since we will just get the same again.        retry := err != ErrBodyTooLarge        return retry, err    }    c.releaseReader(br)     if resetConnection || req.ConnectionClose() || resp.ConnectionClose() {        c.closeConn(cc)    } else {        c.releaseConn(cc)    }     return false, err}

  请注意c.acquireConn()这个方法,这个方法即从连接池中获取连接,如果没有可用连接,则创建新的连接,该方法实现如下

func (c *HostClient) acquireConn() (*clientConn, error) {    var cc *clientConn    createConn := false    startCleaner := false     var n int    c.connsLock.Lock()    n = len(c.conns)    if n == 0 {        maxConns := c.MaxConns        if maxConns <= 0 {            maxConns = DefaultMaxConnsPerHost        }        if c.connsCount < maxConns {            c.connsCount++            createConn = true            if !c.connsCleanerRun {                startCleaner = true                c.connsCleanerRun = true            }        }    } else {        n--        cc = c.conns[n]        c.conns[n] = nil        c.conns = c.conns[:n]    }    c.connsLock.Unlock()     if cc != nil {        return cc, nil    }    if !createConn {        return nil, ErrNoFreeConns    }     if startCleaner {        go c.connsCleaner()    }     conn, err := c.dialHostHard()    if err != nil {        c.decConnsCount()        return nil, err    }    cc = acquireClientConn(conn)     return cc, nil}

其中ErrNoFreeConns 即为errors.New("no free connections available to host"),该错误就是我们服务中出现的错误。那原因很明显就是因为!createConn,即无法创建新的连接,为什么无法创建新的连接,是因为连接数已经达到了maxConns =DefaultMaxConnsPerHost = 512(默认值)。连接数达到最大值了,但是为什么连接没有回收也没有复用,从这块看,还是没有看出来。又仔细的查了一下业务代码,发现很多服务A到服务B的请求,都是因为超时了而结束的,即达到了f.ExecTimeout = 5s。

又从头查看源码,终于发现了玄机。

func clientDoDeadline(req *Request, resp *Response, deadline time.Time, c clientDoer) error {    timeout := -time.Since(deadline)    if timeout <= 0 {        return ErrTimeout    }     var ch chan error    chv := errorChPool.Get()    if chv == nil {        chv = make(chan error, 1)    }    ch = chv.(chan error)     // Make req and resp copies, since on timeout they no longer    // may be accessed.    reqCopy := AcquireRequest()    req.copyToSkipBody(reqCopy)    swapRequestBody(req, reqCopy)    respCopy := AcquireResponse()    if resp != nil {        // Not calling resp.copyToSkipBody(respCopy) here to avoid        // unexpected messing with headers        respCopy.SkipBody = resp.SkipBody    }     // Note that the request continues execution on ErrTimeout until    // client-specific ReadTimeout exceeds. This helps limiting load    // on slow hosts by MaxConns* concurrent requests.    //    // Without this 'hack' the load on slow host could exceed MaxConns*    // concurrent requests, since timed out requests on client side    // usually continue execution on the host.     var mu sync.Mutex    var timedout bool        //这个goroutine是用来处理连接以及发送请求的    go func() {        errDo := c.Do(reqCopy, respCopy)        mu.Lock()        {            if !timedout {                if resp != nil {                    respCopy.copyToSkipBody(resp)                    swapResponseBody(resp, respCopy)                }                swapRequestBody(reqCopy, req)                ch <- errDo            }        }        mu.Unlock()         ReleaseResponse(respCopy)        ReleaseRequest(reqCopy)    }()        //这块内容是用来处理超时的    tc := AcquireTimer(timeout)    var err error    select {    case err = <-ch:    case <-tc.C:        mu.Lock()        {            timedout = true            err = ErrTimeout        }        mu.Unlock()    }    ReleaseTimer(tc)     select {    case <-ch:    default:    }    errorChPool.Put(chv)     return err}

  我们看到,请求的超时时间是如何处理的。当我的请求超时后,主流程直接返回了超时错误,而此时,goroutine里面还在等待请求的返回,而偏偏B服务,由于一些情况会抛出异常,也就是没有对这个请求进行返回,从而导致这个链接一直未得到释放,终于解答了为什么有大量的连接一直被占有从而导致无连接可用的情况。

  最后,当我心里还在腹诽为什么fasthttp这么优秀的框架会有这种问题,如果服务端抛异常(不对请求进行返回)就会把连接打满?又自己看了一下代码,原来,

// DoTimeout performs the given request and waits for response during// the given timeout duration.//// Request must contain at least non-zero RequestURI with full url (including// scheme and host) or non-zero Host header + RequestURI.//// The function doesn't follow redirects. Use Get* for following redirects.//// Response is ignored if resp is nil.//// ErrTimeout is returned if the response wasn't returned during// the given timeout.//// ErrNoFreeConns is returned if all HostClient.MaxConns connections// to the host are busy.//// It is recommended obtaining req and resp via AcquireRequest// and AcquireResponse in performance-critical code.//// Warning: DoTimeout does not terminate the request itself. The request will// continue in the background and the response will be discarded.// If requests take too long and the connection pool gets filled up please// try setting a ReadTimeout.func (c *HostClient) DoTimeout(req *Request, resp *Response, timeout time.Duration) error {    return clientDoTimeout(req, resp, timeout, c)}

感谢各位的阅读,以上就是“golang fasthttp的踩坑分析”的内容了,经过本文的学习后,相信大家对golang fasthttp的踩坑分析这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是编程网,小编将为大家推送更多相关知识点的文章,欢迎关注!

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

golang fasthttp的踩坑分析

下载Word文档到电脑,方便收藏和打印~

下载Word文档

猜你喜欢

golang fasthttp的踩坑分析

这篇文章主要讲解了“golang fasthttp的踩坑分析”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“golang fasthttp的踩坑分析”吧!一个简单的系统,结构如下:我们的服务A
2023-06-25

Golang时间处理中容易踩的坑分析解决

这篇文章主要为大家介绍了Golang时间处理中容易踩的坑分析解决,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
2023-01-11

Java中Objects.equals踩坑实例分析

今天小编给大家分享一下Java中Objects.equals踩坑实例分析的相关知识点,内容详细,逻辑清晰,相信大部分人都还太了解这方面的知识,所以分享这篇文章给大家参考一下,希望大家阅读完这篇文章后有所收获,下面我们一起来了解一下吧。1.
2023-06-29

Python 3.x踩坑的示例分析

这篇文章主要为大家展示了“Python 3.x踩坑的示例分析”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“Python 3.x踩坑的示例分析”这篇文章吧。处处有坑1. 文件读取 open# 我们
2023-06-29

基于log4j2.properties踩坑与填坑的示例分析

这篇文章主要介绍基于log4j2.properties踩坑与填坑的示例分析,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!log4j2.properties踩坑与填坑日志配置门面模式:slf4j日志库:log4j2引入
2023-06-22

vue2使用swiper4踩坑的示例分析

vue2使用swiper4踩坑的示例分析,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。前言一开始打算采用最新的swiper7,后来好像是vue2兼容性问题,各种报错,所以从
2023-06-26

SpringMVC配置404踩坑的示例分析

这篇文章给大家分享的是有关SpringMVC配置404踩坑的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。错误错误就是一直报404,也就说找不到路径。怎么试路径还是404。我相信大家也是非常讨厌404的吧
2023-06-29

基于spring data jpa@query返回map的踩坑分析

这篇文章主要介绍“基于spring data jpa@query返回map的踩坑分析”,在日常操作中,相信很多人在基于spring data jpa@query返回map的踩坑分析问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法
2023-06-25

Mybatis plus多租户方案的实战踩坑分析

这篇文章主要介绍“Mybatis plus多租户方案的实战踩坑分析”,在日常操作中,相信很多人在Mybatis plus多租户方案的实战踩坑分析问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”Mybatis p
2023-06-25

MySQL中case when对NULL值判断的踩坑分析

本篇内容介绍了“MySQL中case when对NULL值判断的踩坑分析”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!前言在开发程序中,从M
2023-06-22

vue3 pinia踩坑及解决实例代码分析

本篇内容主要讲解“vue3 pinia踩坑及解决实例代码分析”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“vue3 pinia踩坑及解决实例代码分析”吧!安装yarn add pinia # o
2023-07-05

Linux高并发踩过的坑及性能实例分析

这篇文章主要讲解了“Linux高并发踩过的坑及性能实例分析”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Linux高并发踩过的坑及性能实例分析”吧!前言Linux操作系统是现在服务器的首选操
2023-06-22

Tauri 打开本地文件踩坑分析解决

这篇文章主要为大家介绍了Tauri 打开本地文件踩坑分析解决,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
2023-05-16

编程热搜

  • Python 学习之路 - Python
    一、安装Python34Windows在Python官网(https://www.python.org/downloads/)下载安装包并安装。Python的默认安装路径是:C:\Python34配置环境变量:【右键计算机】--》【属性】-
    Python 学习之路 - Python
  • chatgpt的中文全称是什么
    chatgpt的中文全称是生成型预训练变换模型。ChatGPT是什么ChatGPT是美国人工智能研究实验室OpenAI开发的一种全新聊天机器人模型,它能够通过学习和理解人类的语言来进行对话,还能根据聊天的上下文进行互动,并协助人类完成一系列
    chatgpt的中文全称是什么
  • C/C++中extern函数使用详解
  • C/C++可变参数的使用
    可变参数的使用方法远远不止以下几种,不过在C,C++中使用可变参数时要小心,在使用printf()等函数时传入的参数个数一定不能比前面的格式化字符串中的’%’符号个数少,否则会产生访问越界,运气不好的话还会导致程序崩溃
    C/C++可变参数的使用
  • css样式文件该放在哪里
  • php中数组下标必须是连续的吗
  • Python 3 教程
    Python 3 教程 Python 的 3.0 版本,常被称为 Python 3000,或简称 Py3k。相对于 Python 的早期版本,这是一个较大的升级。为了不带入过多的累赘,Python 3.0 在设计的时候没有考虑向下兼容。 Python
    Python 3 教程
  • Python pip包管理
    一、前言    在Python中, 安装第三方模块是通过 setuptools 这个工具完成的。 Python有两个封装了 setuptools的包管理工具: easy_install  和  pip , 目前官方推荐使用 pip。    
    Python pip包管理
  • ubuntu如何重新编译内核
  • 改善Java代码之慎用java动态编译

目录