golang：mgo剖析之Session

判官007

　　golang操作mongo使用的包是"gopkg.in/mgo.v2"，coding过程中需要并发读写mongo数据库，简单观摩了下源码，记录下自己的一些理解，如有错误，敬请斧正。　
　　一般来说，我们直接这样创建一个session：
　　Session, err = mgo.Dial(URL)
　　if err != nil {
　　log.Println(err)
　　}
　　来看看Dial这个函数做了什么：
　　func Dial(url string) (*Session, error) {
　　session, err := DialWithTimeout(url, 10*time.Second)
　　if err == nil {
　　session.SetSyncTimeout(1 * time.Minute)
　　session.SetSocketTimeout(1 * time.Minute)
　　}
　　return session, err
　　}
　　调用DialWithTimeout函数设置默认的超时时间是10秒。该函数中调用了DialWithInfo这个函数，而DialWithInfo函数中比较重要是是调用了newSession，看看这个函数做了什么操作：
　　func newSession(consistency Mode, cluster *mongoCluster, timeout time.Duration) (session *Session) {
　　cluster.Acquire()
　　session = &Session{
　　cluster_:    cluster,
　　syncTimeout: timeout,
　　sockTimeout: timeout,
　　poolLimit:   4096,
　　}
　　debugf("New session %p on cluster %p", session, cluster)
　　session.SetMode(consistency, true)
　　session.SetSafe(&Safe{})
　　session.queryConfig.prefetch = defaultPrefetch
　　return session
　　}
　　返回的session设置了一些默认的参数，暂时先忽略，直接看看Session的数据结构：
　　type Session struct {
　　m                sync.RWMutex
　　cluster_         *mongoCluster
　　slaveSocket      *mongoSocket
　　masterSocket     *mongoSocket
　　slaveOk          bool
　　consistency      Mode
　　queryConfig      query
　　safeOp           *queryOp
　　syncTimeout      time.Duration
　　sockTimeout      time.Duration
　　defaultdb        string
　　sourcedb         string
　　dialCred         *Credential
　　creds            []Credential
　　poolLimit        int
　　bypassValidation bool
　　}
　　m是mgo.Session的并发锁，因此所有的Session实例都是线程安全的。slaveSocket,masterSocket代表了该Session到mongodb主节点和从节点的一个物理连接的缓存。而Session的策略总是优先使用缓存的连接。是否缓存连接，由consistency也就是该Session的模式决定。假设在并发程序中，使用同一个Session实例，不使用Copy，而该Session实例的模式又恰好会缓存连接，那么，所有的通过该Session实例的操作，都会通过同一条连接到达mongodb。虽然mongodb本身的网络模型是非阻塞通信，请求可以通过一条链路，非阻塞地处理,但是会影响效率。
　　其次mgo.Session缓存的一主一从连接，实例本身不负责维护。也就是说，当slaveSocket,masterSocket任意其一，连接断开，Session自己不会重置缓存，该Session的使用者如果不主动重置缓存，调用者得到的将永远是EOF。这种情况在主从切换时就会发生，在网络抖动时也会发生。
　　mgo的DB句柄需要你做一个copy操作：
　　// Copy works just like New, but preserves the exact authentication
　　// information from the original session.
　　func (s *Session) Copy() *Session {
　　s.m.Lock()
　　scopy := copySession(s, true)
　　s.m.Unlock()
　　scopy.Refresh()
　　return scopy
　　}
　　copySession将源Session浅拷贝到临时Session中，这样源Session的配置就拷贝到了临时Session中。关键的Refresh，将源Session浅拷贝到临时Session的连接缓存指针，也就是slaveSocket,masterSocket置为空，这样临时Session就不存在缓存连接，而转为去尝试获取一个空闲的连接。
　　mgo自身维护了一套到mongodb集群的连接池。这套连接池机制以mongodb数据库服务器为最小单位，每个mongodb都会在mgo内部，对应一个mongoServer结构体的实例，一个实例代表着mgo持有的到该数据库的连接。看看这个连接池的定义：
　　type mongoServer struct {
　　sync.RWMutex
　　Addr          string
　　ResolvedAddr  string
　　tcpaddr       *net.TCPAddr
　　unusedSockets []*mongoSocket
　　liveSockets   []*mongoSocket
　　closed        bool
　　abended       bool
　　sync          chan bool
　　dial          dialer
　　pingValue     time.Duration
　　pingIndex     int
　　pingCount     uint32
　　pingWindow    [6]time.Duration
　　info          *mongoServerInfo
　　}
　　info代表了该实例对应的数据库服务器在集群中的信息——是否master，ReplicaSetName等。而两个Slice，就是传说中的连接池。unusedSockets存储当前空闲的连接，liveSockets存储当前活跃中的连接，Session缓存的连接就同时存放在liveSockets切片中，而临时Session获取到的连接就位于unusedSockets切片中。
　　每个mongoServer都会隶属于一个mongoCluster结构，相当于mgo在内部，模拟出了mongo数据库集群的模型。
　　type mongoCluster struct {
　　sync.RWMutex
　　serverSynced sync.Cond
　　userSeeds    []string
　　dynaSeeds    []string
　　servers      mongoServers
　　masters      mongoServers
　　references   int
　　syncing      bool
　　direct       bool
　　failFast     bool
　　syncCount    uint
　　setName      string
　　cachedIndex  map[string]bool
　　sync         chan bool
　　dial         dialer
　　}
　　mongoCluster持有一系列mongoServer的实例，以主从结构分散到两个数组中。  每个Session都会存储自己对应的，要操作的mongoCluster的引用。
　　前面的描述可以总结成下面这张图：

　　那么我们在使用的时候就可以创建一个Session，然后clone操作，用clone得到的copysession完成操作，结束后关闭这个copysession就可以了。