【问题标题】:Best practice to maintain a mgo session维护 mgo 会话的最佳实践
【发布时间】:2017-12-22 20:55:54
【问题描述】:

我目前正在将 mongodb 与 mgo lib 用于 Web 应用程序,但我不确定我使用它的方式是否是好的 ..

package db

import (
    "gopkg.in/mgo.v2"
)

const (
    MongoServerAddr = "192.168.0.104"
    RedisServerAddr = "192.168.0.104"
)

var (
    MongoSession, err = mgo.Dial(MongoServerAddr)

    MDB  = MongoSession.DB("message")
    MCol = MDB.C("new")
    MSav = MDB.C("save")

    UDB  = MongoSession.DB("account")
    UCol = UDB.C("user")
)

我初始化数据库会话并创建获取集合和文档值的变量, 所以当我需要查询一个集合时,我使用变量来制作它。

像这样:

func UserExist(username string) bool {
    user := Users{}
    err := db.UCol.Find(bson.M{"username": username}).One(&user)
    if err != nil {
        return false
    } else {
        return true
    }
}

那么有没有最佳实践或者这个很好..? 谢谢

【问题讨论】:

  • 使用函数来设置数据库会话比使用变量声明更好。使用函数的一个原因是您可以处理从 Dial 返回的错误。对于 UserExist,我将使用 count of documents in the result set 来确定文档是否存在。无需获取实际文档。
  • 感谢 UserExist 函数的提示!但是使用初始化会话连接的功能,我可以使用 db 包中的“func init()”来执行此操作,并使用返回会话为 db 和集合分配全局变量吗?我只是不确定如何在打开数据库的情况下保持我的会话,而不是每次我需要它时都创建一个“mgo.Dial()”,并且我的数据库和集合已经初始化......

标签: mongodb go mgo database


【解决方案1】:

我建议不要使用这样的全局会话。相反,您可以创建一个负责所有数据库交互的类型。例如:

type DataStore struct {
    session *mgo.Session
}

func (ds *DataStore) ucol() *mgo.Collection { ... }

func (ds *DataStore) UserExist(user string) bool { ... }

这种设计有很多好处。一个重要的一点是它允许您同时运行多个会话,因此,例如,如果您有一个 http 处理程序,您可以创建一个由独立会话支持的本地会话,仅针对该一个请求:

func (s *WebSite) dataStore() *DataStore {
    return &DataStore{s.session.Copy()}
}    

func (s *WebSite) HandleRequest(...) {
    ds := s.dataStore()
    defer ds.Close()
    ...
}

mgo 驱动程序在这种情况下表现良好,因为会话在内部缓存并重用/维护。每个会话在使用时也将由独立的套接字支持,并且可以配置独立的设置,并且还将具有独立的错误处理。如果您使用单个全局会话,这些是您最终必须处理的问题。

【讨论】:

  • 许多 理由来进行您所说的这种设置。 session.Copy() 调用特别重要,而且对于在 Go 中使用 Mongo 驱动程序的人来说压力不够大,因为它允许驱动程序充分利用并发性。但是然后 - 你知道这一切.. :P +1
  • 快速提问。您使用的网站类型是什么?你知道任何演示这种方法的教程吗?
  • 让我直截了当:如果我处理 5000reqs/sec 我每秒打开 5000 个 db 会话?对吗?
  • @GustavoNiemeyer 你没有解释第一个会话应该在哪里初始化,WebSite 的定义是什么
  • @codepushr 不,它没有。 mgo 使用到 mongodb 的内部套接字连接池。在每个 session.Copy() 上,它会从那里取一个。
【解决方案2】:

虽然没有直接回答您的问题,但关于 mgo 会话检查,您必须使用 defer/recover,因为 mgo 调用(甚至是 mgo.session.Ping)恐慌。据我所知,没有其他方法可以检查 mgo 会话状态 (mgo godocs)。您可以使用Gustavo Niemeyer 的建议并在您的DataStore 类型上添加一个方法。

func (d *DataStore) EnsureConnected() {
    defer func() {
        if r := recover(); r != nil {
            //Your reconnect logic here.
        }
    }()

    //Ping panics if session is closed. (see mgo.Session.Panic())  
    d.Ping()
}

【讨论】:

  • 您可以在处理程序中使用恢复器中间件进行恢复,而无需此操作。
  • @inanc 中间件是如何做到这一点的?数据存储.Ping?
  • 当它出现恐慌时,查看错误信息然后重新连接。
  • 你有恢复器中间件的例子吗?
  • 我为 MongoDb 编写了自己的,但是有一个通用示例 here
【解决方案3】:

使用 go 1.7,在 web 服务器上处理 mongo 会话最惯用的方法是使用新的标准库包 context 编写一个中间件,该中间件可以在调用请求上下文 Done() 时附加 defer session.Close() .所以你不需要记住关闭

AttachDeviceCollection = func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            db, err := infra.Cloner()
            if err != nil {
                http.Error(w, err.Error(), http.StatusInternalServerError)
                return
            }
            collection, err := NewDeviceCollection(db)

            if err != nil {
                db.Session.Close()
                http.Error(w, err.Error(), http.StatusInternalServerError)
                return
            }
            ctx := context.WithValue(r.Context(), DeviceRepoKey, collection)
            go func() {
                select {
                case <-ctx.Done():
                    collection.Session.Close()
                }
            }()

            next.ServeHTTP(w, r.WithContext(ctx))
        })
    }

【讨论】:

  • 上下文并不意味着用于像 mongo 会话这样的长期存在的事情。这是一个臭名昭著的反模式。
  • @InancGumus 哪种方法是处理 mongo 会话的最佳方式?我看到很多关于使用上下文和 mongo 会话的示例。
  • 您可以从注入的结构成员中复制会话,例如下线。
  • @InancGumus 但这里的上下文不是为短期处理程序提供会话吗?
猜你喜欢
  • 2018-08-26
  • 1970-01-01
  • 2010-09-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-01-26
  • 2023-03-12
相关资源
最近更新 更多