近因为工作的原因我们正在使用MongoDB做一些大数据量存储的尝试。对于MongoDB的复制功能部署问题有一些无奈首先说明一下我们的情况我们需要使用的项目情况对于MongoDB的期望MongoDB的无奈和解决方案。我们的站点是一个7×24h提供服务的电子商务网站。海量数据存储高并发实时是我们最大的特点也是我们的需要解决的难点。我们目前的业务量一直在增长所以从架构角度出发可伸缩性可替代性是我们追求目标。目前需要使用到MongoDB的项目有3个一个是应用信息中心AIC该项目是作用是监控线上项目出现异常的情况该项目的特点在于瞬间并发无法估计数据量恐怖读写遵循“二八原则”稳定性要求高实时性一般另一个是业务日志系统BLS该项目主要用来存放站点业务操作的日志目前的做法是将日志存放在DB中我们认为这不是最好的解决方案所以我们准备把该部分日志移植到MongoDB环境中。该项目的特点是数据增量大每天增量大概有7g左右数据无法删除高并发稳定性实时性要求高99%写1%读取最后一个是搜索用户行为分析系统UBA该项目主要是记录一些我们需要分析的用户使用搜索行为的日志该项目的特点是数据量大并发要求高稳定性实时性要求一般但是要求读写尽量分开。三个方案都要考虑成本的问题否则硬件的投入将是最大的软肋。仔细了解MongoDB后先说一下能满足我们需求的点。第一可以存放海量数据第二能承受高并发第三可以使用廉价存储第四单服务器稳定性可以满足要求不能满足我们的点第一net的客户端除了完成了协议外别的实在够差劲第二MongoDB的集群功能实在无语。如果选择pair模式对于slave只能等待master down机不能读选择M-M-S模式不能保证实时性只能保证最后一致性并且可能存在数据重叠问题选择M-S模式slave倒是可以读了但是当master down机时无法自动切换到slave。实在很无语解决办法第一net客户端比较容易解决自己开发一个就基本上没问题第二对于AIC我们选择存储使用M-M-S模式我们保证海量数据的存储和并发性实时性在这个系统中并不是重点稳定性要去也一般所以选择M-M-S应该问题不大对于BLS稳定性是我们的第一要求并发海量快速是我们的第二需求所以我们选择了pair模式宁愿浪费一点硬件设备也要保证稳定性UBA系统我们选用M-S模式原因是保证高并发海量存储的基础上我们还要保证读写分离