mgo 的 session 与连接池

简介

       mgo是由Golang编写的开源mongodb驱动。由于mongodb官方并没有开发Golang驱动，因此这款驱动被广泛使用。mongodb官网也推荐了这款开源驱动，并且作者在github也表示受到了mongodb官方的赞助。但由于作者的个人安排原因，该驱动的更新、bug修复、issue维护略微受到诟病。

       mgo在功能方面还是比较完善的，api使用也方便。由于mongodb丰富的玩法，mgo代码庞大，其中大部分是与mongodb的协议代码。核心的处理连接和请求的结构，逻辑上还是比较清晰的。

简单的使用

func dial() {
	session ,_ := mgo.Dial("mongodb://127.0.0.1")
}

mgo面向调用者的核心数据结构是mgo.Session，dial函数演示了如何获取一个session

func foo1() {
	session.DB("test").C("coll").Insert(bson.M{"name":"zhangsan"})
}

foo1函数通过生成的session，向test数据库的coll集合写入了一条数据。

但mgo的正确使用方法并非如此，而是应该在每次使用时从源session拷贝

func foo2() {
	s := session.Copy()
	defer s.Close()
	s.DB("test").C("coll").Insert(bson.M{"name":"zhangsan"})
}

foo2函数从源session拷贝出了一个临时的session，使用临时session写入一条数据，在函数退出时关闭这个临时的session。

session的拷贝与并发

       为什么要在每次使用时都Copy，而不是直接使用Dial生成的session实例呢？个人认为，这与mgo.Session的Socket缓存机制有关。来看Session的核心数据结构。

type Session struct {
	m                sync.RWMutex
	...
	slaveSocket      *mongoSocket
	masterSocket     *mongoSocket
	...
	consistency      Mode
	...
	poolLimit        int
	...
}

这里列出了mgo.Session的五个私有成员变量，与Copy机制有关的是，m,slaveSocket,masterSocket。

m是mgo.Session的并发锁，因此所有的Session实例都是线程安全的。

slaveSocket,masterSocket代表了该Session到mongodb主节点和从节点的一个物理连接的缓存。而Session的策略总是优先使用缓存的连接。是否缓存连接，由consistency也就是该Session的模式决定。假设在并发程序中，使用同一个Session实例，不使用Copy，而该Session实例的模式又恰好会缓存连接，那么，所有的通过该Session实例的操作，都会通过同一条连接到达mongodb。虽然mongodb本身的网络模型是非阻塞通信，请求可以通过一条链路，非阻塞地处理；但经过比较简陋的性能测试，在mongodb3.0中，10条连接并发写比单条连接的效率高一倍（在mongodb3.4中基本没有差别）。所以，使用Session Copy的一个重要原因是，可以将请求并发地分散到多个连接中。

以上只是效率问题，但第二个问题是致命的。mgo.Session缓存的一主一从连接，实例本身不负责维护。也就是说，当slaveSocket,masterSocket任意其一，连接断开，Session自己不会重置缓存，该Session的使用者如果不主动重置缓存，调用者得到的将永远是EOF。这种情况在主从切换时就会发生，在网络抖动时也会发生。在业务代码中主动维护数据库Session的可用性，显然是不招人喜欢的。

func (s *Session) Copy() *Session {
	s.m.Lock()
	scopy := copySession(s, true)
	s.m.Unlock()
	scopy.Refresh()
	return scopy
}

以上是Copy函数的实现，解决了使用全局Session的两个问题。其中，copySession将源Session浅拷贝到临时Session中，这样源Session的配置就拷贝到了临时Session中。关键的Refresh，将源Session浅拷贝到临时Session的连接缓存指针，也就是slaveSocket,masterSocket置为空，这样临时Session就不存在缓存连接，而转为去尝试获取一个空闲的连接。

Session的连接从哪里来？连接池

明确了使用Session Copy机制的必要性，那么问题来了，Copy出来的临时Session是怎么获取一个到mongodb的物理连接的。答案就是连接池。mgo自身维护了一套到mongodb集群的连接池。这套连接池机制以mongodb数据库服务器为最小单位，每个mongodb都会在mgo内部，对应一个mongoServer结构体的实例，一个实例代表着mgo持有的到该数据库的连接。来看该连接池的定义。

type mongoServer struct {
	sync.RWMutex
	...
	unusedSockets []*mongoSocket
	liveSockets   []*mongoSocket
	...
	info          *mongoServerInfo
}

其中，info代表了该实例对应的数据库服务器在集群中的信息——是否master，ReplicaSetName等。而两个Slice，就是传说中的连接池。unusedSockets存储当前空闲的连接，liveSockets存储当前活跃中的连接，Session缓存的连接就同时存放在liveSockets切片中，而临时Session获取到的连接就位于unusedSockets切片中。

每个mongoServer都会隶属于一个mongoCluster结构，相当于mgo在内部，模拟出了mongo数据库集群的模型。

type mongoCluster struct {
	sync.RWMutex
	...
	servers      mongoServers
	masters      mongoServers
	...
	setName      string
	...
}

如定义所示，mongoCluster持有一系列mongoServer的实例，以主从结构分散到两个数组中。

每个Session都会存储自己对应的，要操作的mongoCluster的引用。

长途跋涉的Session

       以下描述一个Copy出来的临时Session是如何获取到一个mongodb物理连接的。

当临时Session被Copy出来，并且通过调用一系列api，将一次数据库操作设置到了Session内部后，此时万事俱备，只差连接。新生的Session首先会检查自己的缓存里是否有连接可用，初来乍到的他当然不知道自己是一个一无所有的光杆司令。由于mgo的实现，可怜的他还要去检查两次，一次使用读锁，一次使用写锁。作者的意图应该是期望在对同一个session并发操作时，能在第二次排他锁检查之前，恰巧缓存到一条连接，那么就可以减少一次对连接池的操作。但这次，这种好事没有发生在这个Session身上，“摸”了两次“口袋”反复确认以后，他终于还是发现自己身无分文。没有连接的他向组织求救，也就是这个session所要操作的mongodb集群，也就是所提到的mongoCluster结构。

“组织”问了这个Session一系列问题，其中最主要的是两个问题，一是”你要主库连接还是从库连接”，二是“你期望的连接池最大大小是多少”。第一个问题，Session很好回答，他首先看了看自己的模式，是必须到主库还是必须到从库，还是两者皆可看情况而定。再看了看自己手里的操作是读还是写，写操作当然不可能到从库去完成。第二个问题就有点强人所难，但是他不用自己思考，因为这是从源Session那里拿过来的配置，也算是一点祖产吧。

这个Cluster此时表现得像一个掌柜，他先根据主从，从自己手下的mongoServer里挑出了一个，然后问他，你现在手里有没有空闲的连接。如果有，那幸运的Session就可以顺利地获取到这个空闲的连接，高高兴兴的揣到兜里回家干活。但如果不巧，正好unusedSockets为空，那么掌柜会问另一个问题，你有没有超过这个家伙的期望的最大连接数。如果没有超过，那还好，作为伙计的mongoServer就干活了，他会跑到他负责的数据库服务器那里去申请一条全新的连接，亲手交到Session的手里。但如果这个伙计算了算，还去申请新连接的话，恐怕就超限了，那就Session同学对不起了您，您等吧。每100ms,伙计自旋一次，等着unusedSockets里出现可用的连接。

当然有人会问，那这么自旋下去，如果连接一直被其他Session占用，会不会就死循环了呢，答案是不会。这个伙计作为一个数据库服务器的管理员吧可以说，他自己也要常常去确认他负责的这个服务器是不是还活着。因此，伙计同学每15s会给服务器发一个ping命令。作为管理员，伙计可就不管什么连接池大小超不超的问题了，那是他们那些普通session要考虑的琐事。伙计同学要ping的时候，也去unusedSockets里看，如果有最好，就拿一个来用；没有的话，直接去问服务器要新的。ping完之后，新的连接就会被放入unusedSockets中。这样的话，自旋中的获取连接请求，就可以拿到连接了。

经过摸口袋，找组织，问伙计，伙计再干点小活，临时Session终于拿到了梦寐以求的数据库物理连接，把他放到了自己的口袋里（当然有些模式的Session不会这么干）。心满意足地将自己手里的操作通过这条连接写了出去，等到数据库给了他想要的应答，他的生命也就结束了。通过Close方法，我们剥夺了他口袋里的得之不易的连接，放回到了对应mongoServer的unusedSockets中。不久之后，GC又杀死了这个Session。

为什么我司的代码没有使用Copy也没有出问题？

看过我司Go项目代码的同学可能知道，我司的服务端代码中并没有使用Copy，而是类似如下的使用

func Dial(){
	localSession ,_ := mgo.Dial(mongoUrl)
	localSession.SetMode(mgo.Eventual)
	globalDatabase = localSession.DB("db")
}

func Insert() {
	globalDatabase.C("coll").Insert(...)
}

使用了一个全局的mgo.Database实例，所有的对该db的操作，都通过这个实例完成。 原因就在于，我们使用的是模式是mgo.Eventual，该模式最大的特点就是不会缓存连接，拒绝持有mongodb的一针一线。通过该mgo.Database实例的操作，每次都会发现自己的口袋里一无所有，都会经过一次上一节所述的长途跋涉获取连接，因此也规避了不使用Copy带来的两个副作用。一并发效率问题，Eventual的Session每次操作都从连接池取连接，相当于分散在连接池中完成了操作，二连接可用性问题，连接池机制确保了，从mongoServer取得的连接，都是活的连接。

Copy机制或Eventual模式的并发模型的问题

并发锁效率

Copy机制或Eventual模式的共同点是，每次的数据库操作都要经过一次代码路径略深的获取连接的过程。而这个路径中，会操作多个线程安全的结构体，包括mongoServer、mongoCluster等，线程安全的代价就是并发锁冲突带来的性能下降。举个例子，假设有十个写操作并发，无论使用Copy还是Eventual，最终都会走到cluster的masterServer，请求一个主库连接；而完成这个请求，需要写两个slice，将连接从unusedSockets删除，并加入liveSockets，对切片的更新势必要加排他锁，因此这十个请求很有可能会产生锁冲突。

连接池上限与冲击数据库

mgo对Session有一个poolLimit配置，也就是上文中所说的cluster问session的第二个问题——代表了对连接池连接数的上限限制。默认配置的连接数上限是4096，显然对生产环境来说太过大了。但这个配置我以为非常的鸡肋，属于设置也不好，不设置也不好；个人认为这是被mgo的并发模型所拖累了。

假设高并发场景，若设置的连接池上限为4096，并发为10000，那么理论上，一瞬间，mgo可能会产生4096个到mongodb的物理连接，而剩下的六千的请求会自旋等待。4096个连接对mongodb来说，首先意味着4096 * 10M的内存消耗，如此高的连接会导致各种各样的问题。那么加入设置连接池上限为100，并发为10000，9900个等待的请求每次100个排队完成，对应用的效率又是不小的消耗。况且实际测试中，poolLimit的设置也无法严格地限制住连接数。

连接池只伸不缩

mgo另一个问题是连接池连接不释放，一旦由于并发原因，连接池的数量被撑大，之后再也不会变小，除非客户机或服务器重启。

M:1? 1:1 ? M:N!

排除连接可用性问题，全局缓存连接的Session的问题是M个数据库操作通过1个连接完成。通过Copy、Eventual完成数据库操作的问题是，取到一个连接后，只做一件事情就归还了连接。这两种并发模型都存在问题。因此，最好的模型是M:N，有M个数据库操作需要完成，一次性取N个连接，分散到N个连接中完成，此后无论有多少批请求，都可以在N个连接中分散完成。第一可以规避连接池锁冲突，第二不会大规模产生真实连接，充分利用已建立的连接。

SessionPool

M:N的模型无法通过mgo原生支持完成，api也无法支持用户获取到物理连接。

可以利用Session会缓存连接的特性，通过一些小技巧实现一个SessionPool。例如，有M个写操作，则可以一次性生成N个StrongSession，每个StrongSession自己会缓存一条masterSocket；于是，之后的写操作，可以以某种方式负载均衡到这N个由Strong模式的Session缓存的连接中。

mgop简单实现了上述的StrongSessionPool，以轮询的方式负载。对从库连接的缓存以及动态负载还有待实现。

实现SessionPool要特别注意的问题是刷新问题，缓存Session中的连接随时可能会失效，mgop的方式是遍历发送isMaster命令，第一确认连接存活，第二确认连接确实是到主库的。若发现问题，则马上重置缓存。

空闲连接释放

mgo的连接池释放问题，在我的mgo fork中做了一个简单的实现解决这个问题。github.com/JodeZer/mgo

在mongodb url标准中，有两个option：minPoolSize，maxIdleTimeMS。mgo没有支持这两个选项，通过实现这两个选项可以达到释放连接的目的。官网描述：

minPoolSize
The minimum number of connections in the connection pool. The default value is 0.

maxIdleTimeMS
The maximum number of milliseconds that a connection can remain idle in the pool before being removed and closed.

实现方式是，将mongoServer中的unusedSockets类型改造为timedMongoSocket(fork中自定义的类型)

type timedMongoSocket struct {
	soc          *mongoSocket
	lastTimeUsed *time.Time
}

每次有连接被重置到空闲池时，打一个时间戳。在轮询goroutine中每隔一段时间review空闲连接的空闲时长，当时长大于maxIdleTimeMS时，就释放连接，将空闲池的大小控制在minPoolSize。

实现中，没有特地写设置函数，可以通过在mongo url中写入选项设置，如：mongodb://127.0.0.1?minPoolSize=0&maxIdleTimeMS=3000，若maxIdleTimeMS不设置或为0，则默认为不进行释放

 转自：https://cardinfolink.github.io/2017/05/17/mgo-session/