最近，因為工作的原因，我們正在使用MongoDB做一些大數(shù)據(jù)量存儲的嘗試。對于MongoDB的復(fù)制功能部署問題，有一些無奈!

　　首先說明一下我們的情況，我們需要使用的項目情況，對于MongoDB的期望，MongoDB的無奈和解決方案。

　　我們的站點是一個7×24h提供服務(wù)的電子商務(wù)網(wǎng)站。海量數(shù)據(jù)存儲，高并發(fā)，實時是我們***的特點，也是我們的需要解決的難點。我們目前的業(yè)務(wù)量一直在增長，所以從架構(gòu)角度出發(fā)，可伸縮性，可替代性是我們追求目標(biāo)。

　　目前需要使用到MongoDB的項目有3個：

　　一個是應(yīng)用信息中心(AIC)，該項目是作用是監(jiān)控線上項目出現(xiàn)異常的情況，該項目的特點在于瞬間并發(fā)無法估計，數(shù)據(jù)量恐怖，讀寫遵循“二八原則”，穩(wěn)定性要求高，實時性一般;

　　另一個是業(yè)務(wù)日志系統(tǒng)(BLS)，該項目主要用來存放站點業(yè)務(wù)操作的日志，目前的做法是將日志存放在DB中，我們認(rèn)為這不是***的解決方案，所以我們準(zhǔn)備把該部分日志移植到MongoDB環(huán)境中。該項目的特點是數(shù)據(jù)增量大，每天增量大概有7g左右，數(shù)據(jù)無法刪除，高并發(fā)，穩(wěn)定性，實時性要求高，99%寫，1%讀取;

　　***一個是搜索用戶行為分析系統(tǒng)(UBA)，該項目主要是記錄一些我們需要分析的用戶使用搜索行為的日志，該項目的特點是數(shù)據(jù)量大，并發(fā)要求高，穩(wěn)定性，實時性要求一般，但是要求讀寫盡量分開。三個方案都要考慮成本的問題，否則硬件的投入將是***的軟肋。

　　仔細(xì)了解MongoDB后，先說一下能滿足我們需求的點。

　　***：可以存放海量數(shù)據(jù);

　　第二：能承受高并發(fā);

　　第三：可以使用廉價存儲;

　　第四：單服務(wù)器穩(wěn)定性可以滿足要求;

　　不能滿足我們的點：

　　***：net的客戶端除了完成了協(xié)議外，別的實在夠差勁，

　　第二：MongoDB的集群功能實在無語。如果選擇pair模式，對于slave只能等待master down機(jī)，不能讀;選擇M-M-S模式，不能保證實時性，只能保證***一致性，并且可能存在數(shù)據(jù)重疊問題;選擇M-S模式，slave倒是可以讀了，但是當(dāng)master down機(jī)時無法自動切換到slave。實在很無語!

　　解決辦法：

　　***：net客戶端比較容易解決，自己開發(fā)一個就基本上沒問題;

　　第二：對于AIC，我們選擇存儲使用M-M-S模式，我們保證海量數(shù)據(jù)的存儲和并發(fā)性，實時性在這個系統(tǒng)中并不是重點，穩(wěn)定性要去也一般，所以選擇M-M-S應(yīng)該問題不大;對于BLS，穩(wěn)定性是我們的***要求，并發(fā)，海量，快速是我們的第二需求，所以我們選擇了pair模式，寧愿浪費一點硬件設(shè)備，也要保證穩(wěn)定性;UBA系統(tǒng)我們選用M-S模式，原因是保證高并發(fā)，海量存儲的基礎(chǔ)上，我們還要保證讀寫分離，***的原因就是slave需要對BI提供原始數(shù)據(jù)源。

　　對于MongoDB的應(yīng)用，目前我們只使用了那么多，從測試的情況看，應(yīng)該問題不大。***的問題就是在于復(fù)制的功能上，如果pair模式能支持slave可讀，那可將無敵了。看過源碼后，也沒覺得在pair上加入讀的功能對于MongoDB會有多大的影響啊!也可能在設(shè)計的時候有不得已的苦衷吧?不知道MongoDB的架構(gòu)師怎么想的?!

　　原文鏈接：http://www.cnblogs.com/seapeak/archive/2010/06/28/1767091.html