gin 1.3.0 框架 http 回應資料錯亂問題排查
問題概述
客戶端同時發起多個http請求，gin接受到請求后，其中一個介面回應內容為空，另外一個介面回應內容包含介面1,介面2的回應內容，導致回應資料錯亂（偶現問題）
- 圖1紅框標注部分為正常請求回應
- 圖1藍框標注部分為例外請求回應（可以看到編號2531的回應資料只有一個狀態碼資訊，并沒有具體的回傳內容）
- 圖2 可以看到編號2533的回應資料包含兩組object物件資訊，其中第一條object資訊應該是2531的回應資料
- 圖1：
- 圖2：
問題分析
因為此問題是偶現問題，有時回應資料又是正常的，而且本次新版本這兩個介面代碼也并沒有修改，所以排查問題花了很長時間,下面是我一步步排查問題的程序.
- 首先懷疑是代碼邏輯問題，通過review介面代碼邏輯后，這兩個介面邏輯都非常簡單，且沒有任何邏輯關聯，所以基本上排除了介面邏輯問題，
- 懷疑是否是并發請求導致的問題，通過golang并且開啟多個協程模擬并發發起http請求同時呼叫這兩個介面100次，并沒有復現出這種問題，所以可以排除并發請求導致的問題，
- 因為使用golang同時呼叫這兩個介面沒有復現此問題，懷疑是否是客戶端呼叫的問題，是否共用了一個http連接發送請求，導致最終回應結果合并到了一起？ review客戶端代碼后，發現代碼邏輯也沒有什么問題，并且通過抓包后卻發現的確是后臺回應的資料就有問題，所以可以確認就是后端的問題，
- 此時有同事建議列印一下兩個介面后臺請求和回應的物件記憶體地址看一下，是否是共用了同一個物件導致，果然列印之后發現，當資料錯亂時，兩個介面使用的是同一個物件，兩個介面沒有任何邏輯關系，為什么會使用同一個請求物件? 為什么就兩個介面會出現資料錯亂的問題? 難道是gin框架的問題? 此時我們嘗試著除錯代碼去驗證
實驗驗證
- 通過除錯發現,除錯資訊如圖3所示(第1部分為正常情況，可以觀察到物件指標地址不一樣，第2部分為例外情況，可以觀察到物件指標地址一樣)：
- 圖3：
-
此時我觀察到每次這兩個介面請求后面，都跟著另外一個介面請求，如圖1所示的第2494條請求 /api/client/area/scenes 介面，并且本次新版本功能改動了這塊的邏輯，會不會是受這個介面的影響了，于是我嘗試恢復了這塊的代碼，恢復后測驗多次發現問題無法重現，所以可以斷定是受了這塊代碼的影響.
-
然而本次修改的代碼邏輯主要是為了兼容老版本的客戶端,為此介面添加了一個中間件,引入了gin框架的HandleContext(context) 方法,用來做一個統一的中間件,做路由的轉發,具體代碼邏輯如圖4所示.
- 圖4：
- gin框架為golang web開發中,很常用的框架,使用人員非常多,這么明顯的問題不可能沒人發現,雖然極力的認為不可能是框架的問題,但是事實表明就是這里的問題,于是通過查詢資料發現,此方法的確可能出現問題,如圖5所示
- 圖5：
- 可以確認gin框架有問題了,可是原因是什么了?網上并沒有詳細的說明,于是我打算通過除錯閱讀原始碼的方式來測驗,在閱讀原始碼的時候我發現,本地代碼和gin最新的官方原始碼已經不一致,于是我發現本地代碼版本為1.3.0,而官方代碼已經更新到1.6.3了, 如圖6所示: 1.6.3已經洗掉了 engine.pool.Put(c) 此行代碼
- 圖6：
- 于是我嘗試者把gin版本從1.3.0升級到1.6.3,看看問題是否已經解決,果然gin版本升級后,連續測驗多次未能重現問題,所以可以確定就是這里的問題,并且問題已經解決
雖然問題已經解決了,但是為什么洗掉了這一行就可以了? 好像并沒有搞清楚具體的原理是什么? 于是我嘗試著繼續分析原理
- engine.pool.Put(c) 函式使用的是 golang的 sync.Pool 類,sync.Pool設計的目的是用來保存和復用臨時物件，以減少記憶體分配，降低CG壓力,Pool對外暴露的主要有三個介面:get(),put(),new()
- Get 回傳 Pool 中的任意一個物件，如果 Pool 為空，則呼叫 New 回傳一個新創建的物件，
- sync.Pool 是一個臨時物件池，一句話來概括，sync.Pool 管理了一組臨時物件，當需要時從池中獲取，使用完畢后從再放回池中，以供他人使用，
- Put的程序就是將臨時物件放進 Pool 里面，
- 通過如下圖7也可以看到 HandleContext 方法上面有一個 ServeHTTP 方法,可以明顯看到此方法也呼叫了 engine.pool.Put(c) 方法,并且也呼叫了 engine.pool.Get().(Context) 方法,通過除錯發現 ServeHTTP 為http請求通用的方法,所有請求都會先呼叫 ServeHTTP ,如果呼叫了 HandleContext 則會再呼叫 HandleContext ,具體執行順序如下圖7所示,如圖可以看出來 engine.pool.Put(c) 會執行兩次,這樣就會導致在sync.Pool存在兩個同樣的物件,在后面的請求中通過 engine.pool.Get().(Context) 獲取context物件時就會獲取到相同的context物件,導致ResponseWriter指標一樣,從而導致回應資料輸出到同一個介面中.
- 圖7：
小結
此次問題主要是使用了低版本的gin框架所致,所以可以看出即使再成熟的框架,也可能會存在bug,在實際開發程序中應該及時升級到框架的最新穩定版本, 這樣可以防止一些潛在的bug,當發現一些未知的問題,不要憑空猜測,要盡可能的除錯代碼,找到問題的根本原因.
參考資料:
- gin框架介紹: https://studygolang.com/articles/26000?fr=sidebar
- sync.Pool原理:https://blog.csdn.net/u010853261/article/details/90647884
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/229648.html
標籤：Go
上一篇：C/C++編程筆記：如何理解C語言中的嵌套函式，零基礎也看得懂
下一篇：【Go語言學習筆記一】基礎語法