012.MongoDB读写分离

一 读写分离概述

1.1 读写分离描述

从应用程序角度来看,使用Replica Set 和使用单台mongo很像。默认的驱动程序会连接primary节点,并且将所有读写请求都路由到主节点。但也可以通过设置驱动程序的Read Preferences 配置其他选项,将读请求路由到其他节点。
通常官网中建议不使用向从节点取数据。原因如下:
  1. 所有的从节点拥有与主节点一样的写入负载,读的加入会增加其负载;
  2. 对于分片的集合,在平衡器的关系下,数据的返回结果可能会缺失或者重复某部分数据;
  3. 相对而言,官方建议使用shard来分散读写请;
  4. 一致性的考虑,对一致性要求比较高的应用程序是不应该从备份节点读取数据,备份节点通常由于加载问题,网络等原因,而落后于主节点几毫秒,几秒,几分钟甚至更多。如果应用程序需要读取它自己的写操作(比如,先插入一个文档,再去查询它),那么不应该从备份节点去读取数据,除非针对写操作,使用Write Concern定义w数值,在复制到所有备份节点之后,再返回执行成功与否。总之,如果从一个落后的备份节点读取数据,就要牺牲一致性。如果希望写入操作返回之前被复制到所有的副本集成员,就要牺牲写入速度。
  5. 如果路由到的备份节点,其中一台挂了,那么其他节点将承担其相应的压力,需要注意此时在线节点的负载压力。
因此一般是不建议做读写分离,通常对于写操作很少,大量的读请求的业务,实现读写分离来分担服务器压力,然后逐步过度到分片模式。
注意:副本集不是为了提高读性能存在的,在进行oplog的时候,读操作是被阻塞的;
提高读取性能应该使用分片和索引,它的存在更多是作为数据冗余,备份;
尤其当主库本来就面临着大量的写入压力,对于副本集的节点,也同样会面临写的压力。

1.2 使用的场景

通常官方不推荐使用从节点实现读写分离,但可能存在以下场景需要使用读写分离:
  • 异地的分布式部署
  • 故障切换,在紧急情况下向从节点读数据

1.3 延伸读写分离思考

该思考来源:https://github.com/smallnewer/bugs/issues/22
个人总结如下:
主从的写压力基本一样;
  • MongoDB从不会受到主写锁的影响,可通过mongotop 或者 mongostat查看写锁状态;
  • MongoDB从会在主写锁后,在恢复oplog时,进行写锁;
  • 从优先读,而且读太多会影响写;
  • 从节点读的权限比写锁优先级高(注:主节点反之,应该是写贪婪的),建议当从节点的读太高从而影响了oplog的恢复时,改用分片方案。
因此在以下情景下适合使用读写分离:
读写比例要大,即读多写少。如果写多读少,从库也会有大量写锁,阻塞读。
读多写少,从库虽然有写锁,但由于优先读的原因,读不受写锁阻塞,读的速度会加快。
不过从库读压力大的时候,只是暂时把写滞后,如果写滞后的很多,超过了主的oplog上限,会触发整体同步,造成主库压力过大,产生雪崩。
在从能轻松顶住读压力的时候,且读写比例是读多写少,可以考虑读写分离,提高读的速度。
若从节点不能顶住读压力,最好放弃读写分离,换用分片,将热数据分散到不同的机器上。

二 读写分离部署

2.1 正常部署副本集

参考《006.MongoDB复制(副本集)》。

2.2 开启Sencondary可读状态

  1 [root@mongodb02 ~]# mongo --host 172.24.8.72 -u clusteradmin -p clusteradmin
  2 my_rep:SECONDARY> db.getMongo().setSlaveOk()
  3 [root@mongodb02 ~]# mongo --host 172.24.8.73 -u clusteradmin -p clusteradmin
  4 my_rep:SECONDARY> db.getMongo().setSlaveOk()        #分别连接两个Sencondary节点服务器,设置为可读状态
 

2.3 客户端设置读取方式

通过修改客户端读取方式实现从节点的读,具体方式包括:
Read Preference模式
中文解释
primary
默认,只从主节点读取数据
primaryPreferred
在主节点不可用时,从副节点读取数据
secondary
所有的读操作,从副节点读取数据
secondaryPreferred
在副节点不可用时,从主节点读取数据
nearest
从网络延迟最小的节点获取数据
该模式不关注成员的类型,不管是primary还是secondary成员。
客户端演示:略。
参考链接:
https://docs.mongodb.com/manual/applications/replication/
https://www.cnblogs.com/magialmoon/p/3268963.html
http://www.gaozhy.cn/blog/2018/01/18/%E5%9F%BA%E4%BA%8E%E5%89%AF%E6%9C%AC%E9%9B%86%E7%9A%84%E8%AF%BB%E5%86%99%E5%88%86%E7%A6%BB/
posted @ 2019-06-17 19:33 木二 阅读(...) 评论(...) 编辑 收藏