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

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

因此，我們在系統(tǒng)的架構上做了一些改進。我們在整個服務器這一層做了一些新的部署。首先我們需要在一個cluster環(huán)境下構件一個DataCenter，用它來保證數(shù)據(jù)的可靠性。比如現(xiàn)在的使用系統(tǒng)Amazon Simple Service Storage。它就擁有兩個DataCenter，其可靠性能在4個9以上。我們試想一下，在P2P的架構中，對于同樣都是0.9的可用性的服務器上，當他們進行全相連時，而且其每個服務器上都有一定的數(shù)據(jù)備份時，它的可靠性有多高？（這是我們現(xiàn)階段需要建模研究的，還沒有明確的概率值），但可以肯定一點的是，它的可靠性是達不到4個9以上的。

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

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