我有一個(gè)應(yīng)用程序，它使用該upper.io/db包與 Mongo 數(shù)據(jù)庫服務(wù)器（它是一個(gè)相當(dāng)簡單的包裝器gopkg.in/mgo.v2）進(jìn)行通信。應(yīng)用程序的工作方式是在啟動(dòng)時(shí)在主線程中創(chuàng)建一個(gè)會(huì)話，然后需要向 mongo 服務(wù)器發(fā)出請求的每個(gè)單獨(dú)的 goroutine 調(diào)用Clone該會(huì)話并對defer session.Close結(jié)果值執(zhí)行 a 。據(jù)我所知，這都是標(biāo)準(zhǔn)操作程序。在我們使用本地運(yùn)行的 MongoDB或MongoLab 上的沙箱實(shí)例的開發(fā)環(huán)境中，此設(shè)置不會(huì)出現(xiàn)任何錯(cuò)誤。最近，我們將應(yīng)用程序提升到我們的暫存環(huán)境中，我們讓應(yīng)用程序與 MongoLab 上的 MongoDB 共享集群實(shí)例（最便宜的 15 美元選項(xiàng)）進(jìn)行通信。這就是奇怪開始發(fā)生的地方。通過的 /first/ 請求（從第一個(gè)被調(diào)用的 go-routine 開始）返回預(yù)期的響應(yīng)，但隨后的請求都返回 read tcp <ip address>:47112: i/o timeout這發(fā)生在我們指向集群的本地開發(fā)機(jī)器或用于臨時(shí)環(huán)境的 AWS 主機(jī)上。由于 Mongo 集群來自 Mongolabs，我將假設(shè)他們已經(jīng)正確配置了所有內(nèi)容。TBH的代碼有點(diǎn)無聊：它實(shí)際上只是在主函數(shù)中打開會(huì)話并維護(hù)對它的引用，然后有多個(gè)具有這種基本結(jié)構(gòu)的goroutine：   sess := session.Clone()   defer sess.Close()   // make requests to Mongo在測試期間，我什至限制它一次只運(yùn)行一件事（即在任何給定時(shí)間只有一個(gè) goroutine 處于活動(dòng)狀態(tài)），它仍然以同樣的方式失敗。有沒有人遇到過這個(gè)？我需要以特定方式配置 upper.io/db 嗎？也許直接使用mgo？我對此無能為力:(