最近由于工作原因，正在使用MongoDB尝试存储一些海量的数据。关于部署MongoDB的复制功能，我有些无奈！ 首先说明一下我们的情况，需要用到的项目情况，对MongoDB的期望，MongoDB的无奈和解决办法。 本站是一个7×24小时提供服务的电子商务网站。海量数据存储、高并发、实时是我们最突出的特点，也是我们需要解决的难点。我们现在的业务量一直在增长，所以从架构上来说，可扩展性和可替代性是我们追求的目标。 目前有3个项目需要用到MongoDB： 一个是应用信息中心（AIC），用于监控线上项目的异常情况。这个项目的特点是瞬时并发无法估计。数据量大，读写遵循“28原则”，稳定性要求高，实时性一般；它是将日志存储在数据库中。我们认为这不是最好的解决方案，所以我们准备将这部分日志移植到MongoDB环境中。本项目的特点是数据增量大，每天7g左右，数据不能删除，高并发，稳定，实时性要求高，99%写，1%读； ***一个是搜索用户行为分析系统（UBA），这个项目主要是记录一些我们需要分析的用户搜索行为的日志。本项目的特点是数据量大，并发要求高，稳定性和实时性要求一般，但是要求读写尽量分开。三种方案的成本都要考虑，否则硬件的投入将是最大的软肋。 在仔细了解了MongoDB之后，我来说说能满足我们需求的点。 ***：可存储海量数据； 第二：能承受高并发； 第三：可以使用便宜的存储； 第四：单机稳定性能满足要求；不能满足我们的点： ***：除了完成协议，网客户端真的够烂了。 其次：MongoDB的集群功能真是无语。如果选择pair模式，对于slave只能等待masterdown，无法读取；如果选择M-M-S模式，不能保证实时性，只能保证数据的一致性，可能会出现数据重叠的问题；如果选择M-S模式，slave可以读取，但是当master宕机时，不能自动切换到slave。真是无语！ 解决方案： ***：net客户端比较容易解决，自己开发一个基本没问题； 第二：对于AIC，我们选择使用M-M-S模式进行存储，我们保证海量数据的存储和并发，实时性在这个系统中不是重点，稳定性也一般，所以选择M-M-S应该问题不大；对于BLS来说，稳定性是我们的第一要求，并发、质量、速度是我们的第二要求，所以我们选择了pair模式，宁愿浪费一点硬件设备，也要保证稳定性；UBA系统我们选择M-S模式，原因是为了保证高并发，在海量存储的基础上，我们还需要保证读写分离，唯一的原因是slave需要为BI提供原始数据源。 对于MongoDB的应用，目前我们只用到这么多。从测试情况来看，应该问题不大。最大的问题在于复制功能。如果pair模式能够支持slave可读性，那就无敌了。看完源码，我觉得pair中加入read函数对MongoDB影响不大！或许在设计上有不可避免的困难？不知道MongoDB的架构师是怎么想的？！ 原文链接：https://img.ydisp.cn/news/20220804/o0vbuqlhjt1.html
