《MongoDB管理与开发精要》11.5.2节，谈到读写分离，利用ReplicaSet主从机集群，写主要在高性能的PRIMARY，读则从一般的SECONDARY，用以分担PRIMARY的高强度读写压力。
但是在ReplicaSet里面，对PRIMARY的写就是对SECONDARY的写，因为OPLOG的同步，那么也就是说，PRIMARY写繁忙，必定会导致SECONDARY的写繁忙，如果SECONDARY不及时写的话，导致跟不上OPLOG，会引起全库同步，结果会更糟糕。
从这点看，个人感觉这个"读写分离"概念应该是有问题的，如此设计的目的，应该仅用于分担读压力，而对于写，其实集群内所有主机的压力都是相同的，至少是相当的，那么再反过来说，SECONDARY不应该被视为性能低于PRIMARY的机器，对于一个RS，集群内的主机性能应该是相当的才对吧？
当然了，PRIMARY的写和SECONDARY的写还是有区别的，SECONDARY的写是不需要逻辑判断的，照搬照抄就可以，PRIMARY的写则需要对数据做校验、过滤等操作。
不知道我理解的对不对……
分享
[quote]《MongoDB管理与开发精要》11.5.2节，谈到读写分离，利用ReplicaSet主从机集群，写主要在高性能的PRIMARY，读则从一般的SECONDARY，用以分担PRIMARY的高强度读写压力。 [/quote]
读写分离：即查询 和 增删改 分离，好处是相互不阻塞，增大吞吐量，缺点是同步有延迟（同步一般是异步完成，数据不实时，比如每隔1秒从主同步一次数据到从）
数据实时性高的需求不满足
[code="java"]
但是在ReplicaSet里面，对PRIMARY的写就是对SECONDARY的写，因为OPLOG的同步，那么也就是说，PRIMARY写繁忙，必定会导致SECONDARY的写繁忙，如果SECONDARY不及时写的话，导致跟不上OPLOG，会引起全库同步，结果会更糟糕。 [/code]
是的，PRIMARY写繁忙，必定会导致SECONDARY的写繁忙：这个是定时异步同步的，造成从写频繁的可能行较小，除非网络慢； 不会全库同步，而是增量
[quote]从这点看，个人感觉这个"读写分离"概念应该是有问题的，如此设计的目的，应该仅用于分担读压力，而对于写，其实集群内所有主机的压力都是相同的，至少是相当的，那么再反过来说，SECONDARY不应该被视为性能低于PRIMARY的机器，对于一个RS，集群内的主机性能应该是相当的才对吧？ [/quote]
读写分离的核心是 查询 和 增删改 分离，好处是相互不阻塞，增大吞吐量，缺点是同步有延迟；
[quote]如此设计的目的，应该仅用于分担读压力，而对于写，其实集群内所有主机的压力都是相同的，至少是相当的[/quote]
写的话，其实从比主要快，那是一个增量OPLog批处理；而且只有主节点保存OPLog，从不保存的；
Replica Sets 是有自动故障恢复功能的主从集群，，，Replica Sets 使用 n 个 Mongod 节点，构建具备自动容错转移(auto-failover)、自动恢复(auto-recovery) 的高可用方案。
[quote]当然了，PRIMARY的写和SECONDARY的写还是有区别的，SECONDARY的写是不需要逻辑判断的，照搬照抄就可以，PRIMARY的写则需要对数据做校验、过滤等操作。 [/quote]
这个没仔细研究过，不知道你说的对数据做校验、过滤什么意思； 都是对库操作，两者都是一致的，如关系型数据库 会进行约束检查的，不管主从，否则可能数据不一致。
[url]http://sishuok.com/forum/blogPost/list/2591.html[/url]
[url]http://www.cnblogs.com/terrylc/archive/2011/12/13/2285955.html[/url]
Replica Sets 是有自动故障恢复功能的[color=red]主从集群[/color]，Replica Sets 使用 n 个 Mongod 节点，构建具备自动容错转移(auto-failover)、自动恢复(auto-recovery) 的高可用方案。
分享
