現(xiàn)在在回過頭來(lái)看看，我們的應(yīng)用無(wú)非是收集現(xiàn)在生活中的閑散資源，然后對(duì)其進(jìn)行整合，再提供給別的用戶或者企業(yè)來(lái)使用，中間通過付費(fèi)的機(jī)制來(lái)保證數(shù)據(jù)的可靠性，激勵(lì)提供資源方能長(zhǎng)時(shí)間的在線，從而減少數(shù)據(jù)的復(fù)制量，達(dá)到數(shù)據(jù)分發(fā)的快速有效的目的。

現(xiàn)在我們覺得作為一個(gè)P2P系統(tǒng)，要做出使用的系統(tǒng)，至少得保證以下3個(gè)方面：可靠性、高效性、可擴(kuò)展性。但是我們可以看出其實(shí)這是一個(gè)矛盾體，在你保證可靠性的同時(shí)，就不可避免的保證不了高效和可擴(kuò)展，反之亦然，除非你要花很大的代價(jià)，比如可以加大復(fù)制因子，但這很明顯需要更多的存儲(chǔ)空間，更大的網(wǎng)絡(luò)開銷，更實(shí)效的管理策略。

因此，我們?cè)谙到y(tǒng)的架構(gòu)上做了一些改進(jìn)。我們?cè)谡麄€(gè)服務(wù)器這一層做了一些新的部署。首先我們需要在一個(gè)cluster環(huán)境下構(gòu)件一個(gè)DataCenter，用它來(lái)保證數(shù)據(jù)的可靠性。比如現(xiàn)在的使用系統(tǒng)Amazon Simple Service Storage。它就擁有兩個(gè)DataCenter，其可靠性能在4個(gè)9以上。我們?cè)囅胍幌拢赑2P的架構(gòu)中，對(duì)于同樣都是0.9的可用性的服務(wù)器上，當(dāng)他們進(jìn)行全相連時(shí)，而且其每個(gè)服務(wù)器上都有一定的數(shù)據(jù)備份時(shí)，它的可靠性有多高？（這是我們現(xiàn)階段需要建模研究的，還沒有明確的概率值），但可以肯定一點(diǎn)的是，它的可靠性是達(dá)不到4個(gè)9以上的。

以上是我們服務(wù)器的Back-end，現(xiàn)在我們是在p2p的環(huán)境下，所以還得融合p2p的架構(gòu)，所以我們?cè)O(shè)計(jì)了一個(gè)Front-end。在保證了可靠性的基礎(chǔ)上，我們得考慮高效性和可擴(kuò)展性，在Front-end，我們?cè)趶V域網(wǎng)內(nèi)部署很多的服務(wù)器，來(lái)實(shí)現(xiàn)一些復(fù)制策略，從而可以使用戶能高效的就近訪問服務(wù)器，在這里，我們的復(fù)制策略就可以有所改變，不是以往的那種對(duì)于每樣數(shù)據(jù)都必須有很多的Backup，才能保證數(shù)據(jù)的可靠、穩(wěn)定。

但在這里，back-end是否會(huì)成為瓶頸是一個(gè)值得研究的問題，復(fù)制策略的具體算法是什么樣也有待繼續(xù)考慮。新的進(jìn)展會(huì)及時(shí)的寫入。