集群节点间的延迟问题
mongoDB 一个弱点，就是最终一致性，这也是所有NoSQL 的一个问题。
在CAP 理论中，数据库在 (C)onsistency、(A)vailability和(P)artition-tolerance
三者只能满足两个。比如MongoDB 有更好的 高可用性，分布式。就不可避免的牺牲了 [一致性]
前段时间开发组的反映说一条记录在插入后，再查询，没有查询到，这问题还不少。
但后面测试又到重现这个问题。但延迟肯定是有的，但一直不知道具体有多严重。这里暂时先
解决办法肯定是有的，但肯定也不能完全解决。
------------------------------------------------------------------------------------------------------
一、监测网络是否有瓶颈，并解决。
这点我们网络，如果是全部放在云服务器内网进行，几乎不存在，但也不能完全排除。
二、确认硬件配置上，主从是否一致（cpu,mem,io)
现在很多的集群中，已基本上一致的。比如[业务库]，[统计库],[日志库],
但也有例外： [标准版 正式库] 集群：[nginx101,db112,db115]，nginx101 服务器的性能更好，
但跑了其它的应用。
这些问题有历史原因。个人是一直建议，数据库服务器数据节点上，不要跑其它的应用。以免出现
相互干扰问题(io,net,cpu争用)。
三、oplog 大小配置，不知会不会对延迟有影响，现在配置值为10G，数据保存大约20天左右的日志量。
个人认为应该可以减少到 3 - 5G
四、使用 readpreference 读策略
在确实遇到有些读有延迟的问题时，可以使用读策略，把一致性强的读，放到主库进行读
#python code
mon_conn = pymongo.MongoClient(['mongodb://192.168.20.11:28000,192.168.20.19:28000,192.168.20.13:28000,192.168.20.15:28000,192.168.20.17:28000'],
read_preference=pymongo.ReadPreference.PRIMARY)
（就我们当前版本来说，也就只有上面3种方法可以做为解决问题的处理方式了，所以建议还是优先把升级放在前位）
（以下的方法，只在3.2版本可用，当然，使用时也有利有弊，一般在日志类数据保存时也不会去使用 WriteConcern ）
四、使用WriteConcern 机制把数据同步写到多个从机
1. 3个节点的集群中，保证2个节点插入成功，超时设置为5秒
db.products.insert(
{ item: "envelopes", qty : 100, type: "Clasp" },
{ writeConcern: { w: 2, wtimeout: 5000 } }
)
2.在集群配置中设置多数插入成功才为成功。
cfg = rs.conf()
cfg.settings = {}
cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 }
rs.reconfig(cfg)
3.使用TAG ，给各个集群节点设置标签，在插入，更新时，保证某个TAG 成功才为成功（insert,update 返回1）
3.1 先配置节点tag
conf = rs.conf()
conf.members[0].tags = { "dc": "east", "use": "production" }
conf.members[1].tags = { "dc": "east", "use": "reporting" }
conf.members[2].tags = { "dc": "west","use": "production" }
rs.reconfig(conf)
3.2 设置错误
conf.settings = { getLastErrorModes: { MultipleDC : { "dc": 1, "use": 1 } } }
3.3 插入数据时，指定保存到某个tag 对应的节点（可能多个）， 才算成功(insert,update 返回1)
db.users.insert( { id: "xyz", status: "A" }, { writeConcern: { w: "MultipleDC" } } )
智能推荐
注意！
本站转载的文章为个人学习借鉴使用，本站对版权不负任何法律责任。如果侵犯了您的隐私权益，请联系我们删除。