Golang MongoDB 驱动 mgo 的若干问题

mgo 是 MongoDB 的 Golang 驱动。

连接池

我们通过 Dial 函数创建一个新的 session：

session, err := mgo.Dial(url)

创建的 session 能够和 MongoDB 集群中的所有服务器通讯。需要注意的是，对于一个集群只需要调用一次 Dial，通过此 Dial 返回的 session 的 New 和 Copy 方法能够创建更多的 session 出来，这些 session 共用底层的连接池（Dial 创建的多个 session 之间使用不同的连接池）。

更为具体的来看下 Strong session（Strong 为一种一致性模式，这里讨论 Strong session 是因为其相对简单，详见下文）。一个 Strong session 会使用一个固定的连接，换而言之，mgo 不会帮你创建更多的连接出来。我们可以通过 session 的 New、Copy 创建出更多的 session 来，这意味着更多的连接能够被建立，且这些连接能够通过内部的连接池被重用。

mgo 提供了一个方法 SetPoolLimit 用于控制正在使用的连接的最大数量，但是实际建立的连接数很可能大于此值。官方文档特别指出，不要使用此来定义应用程序的并发限制（It is a bad practice and an unsupported use case to use the database driver to define the concurrency limit of an application）。SetPoolLimit 无法控制实际建立的连接数，如果希望进行控制，较为稳妥的做法是直接控制 session 的数量。

一致性模式（consistency mode）

每个 session 都可以设置一致性模式（ consistency mode ）：

1. Strong 一致性模式（默认使用）
2. Monotonic 一致性模式
3. Eventual 一致性模式

Strong 一致性模式

session 的读写操作总向 primary 服务器发起并使用一个唯一的连接，因此所有的读写操作完全的一致（不存在乱序或者获取到旧数据的问题）。

Monotonic 一致性模式

session 的读操作开始是向某个 secondary 服务器发起（且通过一个唯一的连接），只要出现了一次写操作，session 的连接就会切换至 primary 服务器。由此可见此模式下，能够分散一些读操作到 secondary 服务器，但是读操作不一定能够获得最新的数据。官方更为详细的说明：

In the Monotonic consistency mode reads may not be entirely up-to-date, but they will always see the history of changes moving forward, the data read will be consistent across sequential queries in the same session, and modifications made within the session will be observed in following queries (read-your-writes).

In practice, the Monotonic mode is obtained by performing initial reads on a unique connection to an arbitrary secondary, if one is available, and once the first write happens, the session connection is switched over to the primary server. This manages to distribute some of the reading load with secondaries, while maintaining some useful guarantees.

Eventual 一致性模式

session 的读操作会向任意的 secondary 服务器发起，多次读操作并不一定使用相同的连接，也就是读操作不一定有序。session 的写操作总是向 primary 服务器发起，但是可能使用不同的连接，也就是写操作也不一定有序。Eventual 一致性模式最快，其是一种资源友好（resource-friendly）的模式。

有疑问加站长微信联系（非本文作者）