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