写在前面
最近有新项目上线,实在太忙了,学习的进度有点拖沓,但会坚持。
第十七天
今天要学的是《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。
最后
今天内容就这些,明天继续。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。