最近，因?yàn)楣ぷ鞯脑?，我們正在使用MongoDB做一些大數(shù)據(jù)量存儲的嘗試。對于MongoDB的復(fù)制功能部署問題，有一些無奈!

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

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

　　目前需要使用到MongoDB的項(xiàng)目有3個(gè)：

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

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

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

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

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

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

　　第三：可以使用廉價(jià)存儲;

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

　　不能滿足我們的點(diǎn)：

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

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

　　解決辦法：

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

　　第二：對于AIC，我們選擇存儲使用M-M-S模式，我們保證海量數(shù)據(jù)的存儲和并發(fā)性，實(shí)時(shí)性在這個(gè)系統(tǒng)中并不是重點(diǎn)，穩(wěn)定性要去也一般，所以選擇M-M-S應(yīng)該問題不大;對于BLS，穩(wěn)定性是我們的***要求，并發(fā)，海量，快速是我們的第二需求，所以我們選擇了pair模式，寧愿浪費(fèi)一點(diǎn)硬件設(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è)計(jì)的時(shí)候有不得已的苦衷吧?不知道MongoDB的架構(gòu)師怎么想的?!

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