写在前面

最近有新项目上线，实在太忙了，学习的进度有点拖沓，但会坚持。

第十七天

今天要学的是《20 | 事务开发：读操作事务之一》章节。主要讲解的是怎么哪里读取数据的问题。

readRreference 参数

值有5个，如下图，默认为primary，即从主结点读数据。

应用场景场景举例

以电商订单，举了一个实际的例子，干货。

• 用户下订单后马上将用户转到订单详情页——primary/primaryPreferred。因为此时从节点可能还没复制到新订单；
• 用户查询自己下过的订单——secondary/secondaryPreferred。查询历史订单对时效性通常没有太高要求；
• 生成报表——secondary。报表对时效性要求不高，但资源需求大，可以在从节点单独处理，避免对线上用户造成影响；
• 将用户上传的图片分发到全世界，让各地用户能够就近读取——nearest。每个地区的应用选择最近的节点读取数据。

控制多个结点

这部分通过给结点打标签，可以控制从哪一组来读。

readPreference 配置

通过 MongoDB 的连接串参数：

• mongodb://host1:27107,host2:27107,host3:27017/?replicaSet=rs&readPreference=secondary

通过 MongoDB 驱动程序 API：

• MongoCollection.withReadPreference(ReadPreference readPref)

Mongo Shell：

• db.collection.find({}).readPref( “secondary” )

readPreference 实验: 从节点读

• 主节点写入 {x:1}, 观察该条数据在各个节点均可见

• 在两个从节点分别执行 db.fsyncLock() 来锁定写入（同步）

• 主节点写入 {x:2}

• db.test.find({a: 123})
• db.test.find({a: 123}).readPref(“secondary”)

• 解除从节点锁定 db.fsyncUnlock()

• db.test.find({a: 123}).readPref(“secondary”)

注意事项

• 指定 readPreference 时也应注意高可用问题。例如将 readPreference 指定 primary，则发生故障转移不存在 primary 期间将没有节点可读。如果业务允许，则应选择 primaryPreferred；

• 使用 Tag 时也会遇到同样的问题，如果只有一个节点拥有一个特定 Tag，则在这个节点失效时将无节点可读。这在有时候是期望的结果，有时候不是。例如：

  • 如果报表使用的节点失效，即使不生成报表，通常也不希望将报表负载转移到其他节点上，此时只有一个节点有报表 Tag 是合理的选择；
  • 如果线上节点失效，通常希望有替代节点，所以应该保持多个节点有同样的 Tag；
• Tag 有时需要与优先级、选举权综合考虑。例如做报表的节点通常不会希望它成为主节点，则优先级应为 0。

最后

今天内容就这些，明天继续。