最近，因为工作的原因，我们正在使用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模式，原因是保证高并发，海量存储的基础上，我们还要保证读写分离，***的原因就是slave需要对BI提供原始数据源。
对于MongoDB的应用，目前我们只使用了那么多，从测试的情况看，应该问题不大。***的问题就是在于复制的功能上，如果pair模式能支持slave可读，那可将无敌了。看过源码后，也没觉得在pair上加入读的功能对于MongoDB会有多大的影响啊!也可能在设计的时候有不得已的苦衷吧?不知道MongoDB的架构师怎么想的?!
原文链接：http://www.cnblogs.com/seapeak/archive/2010/06/28/1767091.html
