文件共享管理系統的設計與實現

摘要：本文件共享管理系統解決了用戶在搜索文件不需要下載文件到本地硬盤后才能查看文件的詳細內容的弊端；解決用戶在搜索關鍵字不明確條件下無法搜索到自己需要的文件弊端；解決了系統用戶并發量增加后服務器宕機而無法提供服務的弊端；解決服務器面對大量業務處理數據讀取速度過慢的弊端；解決用戶登錄密碼在 http 協議下被輕易竊取的弊端。

本文件共享管理系統，通過構建服務器集群和分布式數據庫集群來滿足互聯網用戶的并發訪問，提高用戶請求的響應時間；系統依賴于緩存服務器提高對數據的訪問速度；通過對用戶上傳文件的處理使得文件可以被用戶在線瀏覽；保證用戶文件的安全性采用單獨的服務器進行存儲；通過使用全文檢索框架對用戶輸入關鍵字智能分析。

本系統采用恰當的技術來解決上述問題從而為用戶提供良好的操作體驗。

關鍵字：全文檢索；安全；在線預覽；文件存儲

項目背景

隨著計算機技術的飛速發展，計算機應用的普及，計算機軟件系統對社會，經濟帶來越來越重要的影響，極大程度上提高了人們的工作效率。尤其近些年來，隨著互聯網 + 的提出，我國政府將互聯網作為當前信息化發展的核心特征并與工業，商業，金融等服務業全名融合。不僅提高了各行各業的服務質量和工作效率，而且降低了各行各業的不必要的成本開銷，這對促進整個社會的良性發展有著推動作用。

馬云說過計算機所處的時代正由 IT 轉向 DT 時代，現在的軟件系統已經不僅僅是為局部的幾十個人使用了，而是面對整個互聯網用戶提供服務，傳統的架構模式已經無法滿足時代的需要，如何設計一個良好的軟件架構面向整個互聯網用戶提供服務，這就是本系統的研發所在。

開發目的與意義

一個系統要想獲得用戶的青睞和高比例的留存率，能否為用戶提供滿意的服務是一個很重要的因素，本系統做到想用戶所想，在頁面上減少用戶對本系統的學習成本，高質量的響應用戶的搜索內容，使得用戶能夠搜索到符合自己滿意的文件減少用戶不必要的下載和流量消耗。互聯網系統必須保證用戶信息的安全性，如果不能給用戶安全感，這個系統就是一個失敗的項目，系統的開發目的就是有人愿意使用。傳統系統我們經常會遇到當有很多人和自己同時登陸系統操作時，自己的操作結果往往要等待幾分鐘才有響應，這樣的系統在設計上就已經是失敗的，一個好的系統必須在任何情況下都可以在用戶可以等待的范圍內及時響應。

本系統的開發就是對為了響應互聯網 + 的號召，對傳統系統的一次改變；保證用戶的信息的安全性，防止用戶的的個人信息在網絡傳輸中被人截取利用；保證用戶的響應都可以在合理的時間內進行響應；保證用戶能夠在下載文件前就充分知道文件內容是自己所需要的等。

系統開發工具與技術

本文件共享管理系統的開發工具使用 Eclipse，數據庫采用的是 MySQL，服務器采用 Tomcat6.0，Nginx。在開發中采用 Java 語言進行開發，項目整體使用 Struts2，hibernate，Spring 三大框架作為開發的基本環境，使用 Lucene 全文檢索框架進行文件的搜索，MyCat 中間件處理分布式數據庫和分布式事務問題等問題，OpenOfiice 技術對 office 文件轉換為 swf 文件時數據內容的提取，頁面采用 JSP+HTML+CSS+DIV 等技術，AJAX 進行請求的異步發送，Java Mail 技術對用戶賬號進行驗證，Memached 技術實現內存級緩存，同時在項目開發中使用 SVN 進行項目的版本控制。下面經對這些平臺和技術進行簡單的介紹。

MySQL 數據庫

MySQL 是一個采用了關系模型來組織數據的關系型數據庫，而且它的源代

碼是開放的，誰都可以在一定的條件下無償使用，而且可以對應用程序進行改造。它使用普及率廣泛；對數據的處理十分迅速；支持在多種 OS 中運行；支持多種開放語言。

Memcached 技術

Memcached 是一個性能很高的內存對象緩存系統，它通過在內存里維護一個統一的巨大的 hash 表，來存儲各種格式的數據，包括圖像、音頻以及數據庫檢索的結果等。簡單的說 Memcached 就是將數據調用到內存中存儲起來，然后需要對應數據時從內存中讀取而不是從硬盤中讀取，從而大大提高讀取速度。

Memcached 以守護程序的方式可以運行在一個或多個服務器上，隨時接收客戶端的連接和操作。

Lucene 技術

Lucene 是一個開放源代碼的全文檢索引擎框架，它提供了完整的查詢引擎和索引引擎，部分文本分析引擎。全文檢索是計算機程序通過掃描文章中的每一個詞，對每一個詞建立一個索引，指明該詞在文章中出現的次數和位置。當用戶查詢時根據建立的索引查找，類似于通過字典的檢索字表查字的過程.

Nginx 技術

Nginx 是一個高性能的 HTTP 和反向代理的服務器，反向代理方式是指以代理服務器來接受 internet 上的連接請求，然后代理服務器將請求轉發給內部網絡上的服務器，并將從服務器上得到的結果返回給 internet 上請求連接的客戶端，此時代理服務器對外部網絡的客戶端而言像為一個服務器。

Servlet 技術

servlet 是一個用 Java 編寫的服務器端程序。servlet 運行在 Java 服務器上。Java servlet 可以動態的擴展服務器的能力，采用請求-響應模式提供 Web 服務。

當 Web 服務器接收到一個 http 請求時，他會先判斷請求內容,如果請求的內同是靜態網頁數據，Web 服務器會自行處理并返回響應信息;如果請求的內容涉及動態數據，Web 服務器會將請求轉給 servlet 容器，servlet 容器就會找到對應的處理該請求的 servlet 實例，最后 serlvet 實例將結果送回 Web 服務器，再由 Web 服務器傳回客戶端。

JSP 技術

JSP 全稱是 Java Server Pages，它是一種用于開發動態 Web 資源的技術。

JSP 技術的特點在于，開發者寫 JSP 就像在寫 HTML，但它相比 HTML 只能為用戶提供靜態數據，JSP 技術允許在頁面中嵌套 Java 代碼，為用戶提供動態數據。

不管是在開發中使用 JSP 或是 Servlet，它們都可以用于開發動態 Web 資源。但由于這 2 門技術各自的特點，在長期的軟件開發中，工程師逐漸把 servlet 作為 Web 應用中的控制器組件來使用，而把 JSP 技術作為數據顯示模板來使用。

Struts 技術

struts2 是一個遵循 MVC 結構的框架，采用了更加松耦合的設計，使得系統的 action 不與 servlet API 耦合，使系統可以從 B/S 結構轉換為 C/S 結構；action 不需要與 WebWork 耦合，代碼的重用率更高；對 JSP,Velocity,FreeMarker 等表現層技術提供支持；使用攔截器作為增強處理，以用戶的業務邏輯控制為目標，創建一個控制器代理。

Hibernate 技術

hibernate 是輕量級 javaEE 應用的持久層解決方案。Hibernate 對 JDBC 訪問數據庫的代碼做了封裝，負責 Java 對象的持久化，大大簡化了數據訪問層繁瑣的重復性代碼；Hibernate 是一個基于 JDBC 的主流持久化框架，是一個優秀 的 ORM 實現，建立面向對象的域模型和關系數據模型之間的映射，連接 Java 應用和數據庫的中間件，它很大程度的簡化了 dao 層編碼工作，封裝對數據庫的訪問細節，使業務邏輯層更專注于實現業務邏輯；Hibernate 的性能非常好，因為它是一個輕量級框架。映射的靈活性很出色。它支持很多關系型數據庫，跨平臺性很強，從一對一到多對多的各種復雜關系；hibernate 的一級緩存，二級緩存，查詢緩存，使訪問數據的效率提高很大。

Spring 技術

Spring 是根據大量開發中出現的通用步驟對這些通用步驟進行抽取的框架，因此它完成了，他留給開發者的僅僅是與特定應用相關的部分，開發者不需要再編寫系統開發中需要解決的通用問題，從而大大提高開發者的開發效率。

Spring 為企業應用的開發提供了一個輕量級的解決方案。該解決方案包括：基于依賴注入的核心機制，基于 AOP 的聲明式事務管理，與多種持久層技術的整合，以及優秀的 Web MVC 框架等。Spring 致力于 Java EE 應用各層的解決方案，而不僅僅是專注于某一層的方案。

Sping 具有低侵入式的設計，代碼的污染極低；獨立于各種應用服務器，基于 Spring 框架編寫的應用，可以真正實現一處編寫，到處運行的承諾；Spring 的 DI 容器降低了業務對象替換的復雜性，提高了組件之間的解耦；Spring 的 AOP 支持允許將一些通用任務如安全，事務，日志等進行集中式處理，從而提供了更好的復用；Spring 的 ORM 和 DAO 提供了與第三方持久層框架的良好整合，并簡化了底層的數據庫訪問。

系統規劃與系統分析

系統的總體結構

根據文件共享管理系統的設計需求，確定本系統平臺的整體運作模式要求用戶通過 Web 端進入文件共享系統的首頁系統搜索自己需要的文件，用戶根據系統呈現的數據選擇滿足自己需要的，進而點擊該文件在線預覽以驗證該文件是否符合自己的需要，從而再進行文件的下載。最后用戶也可以上傳自己的文件資源供其他用戶檢索下載，從而達到資源共享的目的。

按照每個用戶可以操作的功能來理清系統整體功能，系統功能模塊圖如圖所示的。

圖 3.1 系統功能圖

數據庫需求分析

開發應用系統創建一個合格的數據庫是一個復雜而有重要的任務，數據庫表設計的好壞直接影響到系統進入開發階段的開發效率。所以我們設計一個完整的數據庫應用環境時這要求我們更加廣泛關注問題本身。同時針對數據設計本身，我們要避免兩個方面的缺陷，即冗余和完整性，一個好的設計方案不可能或者很少有重復的信息，當然，也不可能使單位的某個方面難以建模。作為數據庫設計的概念階段，充分考慮系統數據需求，保證設計的數據完整刻畫用戶對系統的數據的需求，還需要以系統的方式定義數據庫用戶的數據需求，并定義滿足這些需求的數據庫結構。

本系統的概念設計如下：

• ·實體：共有 8 個實體，分別是用戶、管理員、文件、文件地址、評論、舉報、用戶文件狀態和注冊。
• ·聯系：各個實體通過主外鍵屬性關聯。
• ·屬性：各個實體屬性如表 3.1 所述。
  表 3.1 文件管理系統實體屬性表

通過對文件管理系統的數據概念描述，根據其中的實體，聯系和屬性，構建

文件管理系統數據實體聯系圖，如圖 3.2 所示。

圖 3.2 數據庫實體 ER 圖

系統設計與實現

系統用戶功能設計系統用戶分為三種角色：游客、用戶、管理員。這三個角色的功能如下所述：

游客

搜索資料：游客可以在搜索框輸入要搜索文件的關鍵字進行搜索；

查看文件信息：游客可以點擊搜索結果列表的文件查看該文件的詳細信息以及其他用戶對該文件的評論；預覽文件：游客可以對查看的文件進行在線預覽；

用戶

搜索資料：用戶可以在搜索框輸入要搜索文件的關鍵字進行搜索；

查看文件信息：用戶可以點擊搜索結果列表的文件查看該文件的詳細信息以及其他用戶對該文件的評論；

下載文件：用戶可以下載該文件；

評論文件：用戶可以評論下載過的文件，但只能評論一次；舉報文件：用戶可以舉報下載過的文件，但只能舉報一次；

上傳文件：用戶可以上傳 office 文件供其他用戶下載；用戶注冊：用戶通過郵箱驗證的方式進行注冊；

用戶登錄：用戶登錄成功的同時系統會向用戶手機發送短信告知；查看個人信息：用戶可以查看個人信息；修改個人信息：用戶可以修改個人信息；找回密碼：用戶通過注冊的郵箱信息重設密碼；

管理員

查看投訴列表：管理員查看用戶投訴列表；

處理投訴：對用戶的投訴信息進行查看并處理；

用戶登錄：用戶登錄成功的同時系統會向用戶手機發送短信告知；查看個人信息：用戶可以查看個人信息；

數據庫表存儲設計

在第三節介紹了數據庫表的概念設計之后，接下來講解每個表的實際業務意

義。各信息實體具體描述如下：

• 管理員表(見表 4.1 所示)：用于存儲管理員的賬戶信息。管理員表有 4 個字段，分別是 adminId，賬號，密碼，昵稱，其中 adminId 為數據庫自增字段，也
• 用戶表(見表 4.2 所示)：用于存儲用戶的賬戶信息。用戶表有 9 個字段，分別是 userId，賬號，密碼，昵稱，頭像，生日，電子郵箱，賬號是否凍結（用戶是否可以登錄進系統），惡意行為次數（記錄用戶違規操作，上傳不健康文件），其中 userId 為數據庫自增字段，也是該表主鍵。
  表 4.2 用戶表 USER

文件表(見表 4.3 所示)：用于存儲用戶的上傳的文件信息。文件表有 10 個字段，分別是 fileId，文件標題，文件介紹，下載次數，好評次數，差評次數，上傳時間，文件總大小，文件是否被封（文件是否可以被所有用戶檢索到），上傳用戶，其中 fileId 為數據庫自增字段，也是該表主鍵。

表 4.3 文件表 FILE

文件地址表(見表 4.4 所示)：用于存儲文件信息的實際存儲地址。文件地址表有 6 個字段，分別是 fileresourceId，文件名稱，文件鏈接地址，文件預覽地址，文件大小，文件（這個文件地址屬于哪一個文件的），其中 fileresourceId 為數據

庫自增字段，也是該表主鍵。

表 4.4 文件地址表 FILERESOURCE

評論表(見表 4.5 所示)：用于用戶對文件的評論信息。評論表有 6 個字段，分別是 commentId，評論內容，評論等級（該文件時好或差），評論時間，評論用戶，評論文件，其中 commentId 為數據庫自增字段，也是該表主鍵。

表 4.5 文件評論表 COMMENT

舉報表(見表 4.6 所示)：用于用戶對文件的舉報信息。舉報表有 4 個字段，分別是 reportId，舉報用戶，被舉報文件，舉報內容，其中 reportId 為數據庫自

用戶文件狀態表(見表 4.7 所示)：用于記錄用戶是否下載過對應文件且是否對文件進行過評論或舉報。保證只有下載過對應文件的用戶可以舉報和評論且只能舉報或評論一次。用戶文件狀態表有 5 個字段，分別是 usestateId，用戶，文件，是否評論，是否舉報，其中 usestateId 為數據庫自增字段，也是該表主鍵。表 4.7 文件文件狀態表 USESTATE

注冊表(見表 4.8 所示)：用于保存用戶注冊但是還未生效的賬號信息，當注冊表的數據超過 24 小時將會刪除，保證賬號的可用性。注冊表有 5 個字段，分別是 usereamilId，注冊賬號，注冊密碼，郵箱地址，創建時間，其中 usereamilId 為數據庫自增字段，也是該表主鍵。

系統的架構設計

表 4.8 注冊表 REGIST

本系統的后臺集群架構的設計如圖 4.1 所示。

圖 4.1 系統架構模塊圖

用戶請求發送到負載均衡主機，主機把請求分發到后臺的應用服務器進行處理，服務器對文件的下載和上傳操作通過文件服務器進行存儲。當用戶搜索文件時，服務器向 lucene 服務器發出請求搜索數據，而不是搜索數據庫。當用戶對數據字典的數據訪問通過緩存服務器獲取，不再通過數據庫獲取。

系統 Web 界面設計

系統首頁：所有用戶包括登錄用戶和未登錄用戶都可以訪問系統首頁，系統首頁以百度搜索為參考，用戶可以在首頁輸入框輸入自己要檢索的文件信息。系統會根據用戶輸入的關鍵字來檢索系統中已經上傳的文件的文件標題和文件簡介是否有符合用戶搜索的，并將滿足的記錄以列表的形式顯示給檢索的用戶，并對關鍵字進行高亮顯示，排序方式會根據文件被搜索的權重進行相關對排序。原型圖如圖 4.2，4.3 所示。

圖 4.2 系統首頁

圖 4.3 系統搜索列表首頁

文件簡介頁面：任何人都可以點擊搜索返回文件列表的某一條數據進入該文件的信息頁面，可以查看文件大小，文件好評和差評數量，文件簡介，文件名稱，文件作者，用戶對文件評論，文件上傳時間，文件的下載路徑，用戶可以對文件進行舉報和評論。如果是未登錄的用戶點擊舉報和評論，下載文件按鈕。系統會自動跳轉到系統登錄頁面，要求用戶只能登錄后才可以舉報，下載和評論文件。

如圖 4.4 所示。

圖 4.4 文件簡介頁面

文件預覽頁面：所有用戶都可以在文件信息頁面點擊預覽按鈕來線預覽文件的內容，不需要下載。如圖 4.5 所示。

圖 4.5 文件預覽頁面

文件舉報頁面：只有登錄的用戶且下載了對應的文件的用戶才可以進入舉報頁面，同時該用戶只能舉報該文件一次，隨后管理員將會對用戶舉報的文件進行審核。如圖 4.6 所示。

圖 4.6 文件舉報頁面

文件舉報頁面：在文件信息頁面，登錄過，且下載該文件的用戶可以評論該文件一次。評論后，將在該文件的評論列表看見評論信息。如圖 4.7 所示。

圖 4.7 文件評論頁面

文件上傳頁面：已經登錄的用戶可以進行文件上傳操作，否則點擊跳轉到用戶登錄頁面。可以上傳多個文件，但是文件類型必須是 office 類型，否則提示上傳失敗，同時必須注明上傳文件的標題和簡介。如果用戶輸入的標題和簡介中含有敏感詞匯會被和諧。文件上傳成功后，會跳轉到文件信息頁面。如圖 4.8 所示。

圖 4.8 文件上傳頁面

登錄頁面：驗證用戶的信息是否正確，正確就進入系統首頁，否則返回該頁，提示登錄錯誤信息。這里驗證用戶信息包括賬號和密碼是否正確以及該用戶的狀態是否是有效，如果無效就無法登錄。只有登錄的用戶才可以下載，舉報和評論下載的文件以及上傳文件，當未登錄的用戶點擊上傳文，下載，評論和舉報按鈕，系統會跳轉到登錄頁面。如圖 4.9 所示。

圖 4.9 系統登錄頁面

注冊頁面：用戶輸入用戶名和郵箱，系統通過 AJAX 異步查詢數據庫，如果用戶名和郵箱已經存在了，則在頁面提示已經被使用，否則提示可以使用（如圖 4.10 所示）。注冊信息通過后，點擊立即注冊，就向注冊郵箱發送激活信息（如圖 4.11 所示），這時候就會跳轉到郵箱頁面。點擊進入郵箱（如圖 4.12 所示），點擊激活鏈接就成功激活了（如圖 4.13 所示）。

圖 4.10 注冊頁面

圖 4.11 郵箱激活頁面

圖 4.12 郵箱頁面

圖 4.13 注冊成功頁面

密碼找回：如果用戶忘記密碼，可以通過注冊時綁定的郵箱進行密碼的重設。

如圖 4.14 所示。操作流程同 4.10 用戶注冊。

圖 4.14 密碼找回頁面

個人信息頁面：登錄用戶可以查看并修改個人信息，用戶只能修改自己的昵稱，頭像，生日。同時用戶可以看見自己的違規次數。如果昵稱含有敏感詞將會被系統和諧掉以*替換。如果上傳的頭像不是圖片類型則提示上傳失敗。如圖 4.15 所示。

圖 4.15 個人信息頁面

管理員登錄頁面：系統有一個單獨的頁面面向管理員，管理員可以登錄系統。

如圖 4.16 所示。

圖 4.16 管理員頁面

投訴處理頁面：管理員登錄系統后，將會看到未處理的用戶舉報列表，管理員選擇查看被投訴的文件，看文件是否符合投訴條件，符合則點擊受理，該文件的所有舉報都被處理，該文件無法被用戶查詢到了，同時記錄上傳該文件者的不良行為，當不良行為到達一定次數后，就會被封號。點擊拒絕，該文件的所有舉報都被處理了。如圖 4.17 所示。

圖 4.17 管理員受理頁面

系統測試

性能測試

網站性能測試的主要衡量指標包括網站的請求響應時間，網站的并發數，網站的吞吐量等。

1，響應時間：系統執行一個完成操作整體消耗的時間，這個時間包括從客戶端發出請求開始到服務器上的系統收到然后把響應數據發出去所需要的時間。

2，并發數：系統能夠同時處理來自客戶端的請求數目，這個指標反映系統的負載特性。

3，吞吐量：指系統在單位時間內處理的請求數量，這個指標可以反應出系統的整體處理能力。

性能測試結果

使用如上的測試方法本系統的性能測試結果如表 5.1 所示。

表 5.1 性能測試結果報告

功能測試

在測試中，根據系統的需求分析說明書以及系統的詳細設計說明書，理解不同模塊的輸入輸出條件和邏輯結構，準備每個功能的測試用例，來驗證每個功能模塊的執行結果是否正確。

功能測試結果

由于系統的模塊可限制多，這里主要對部分關鍵功能進行測試用例的描述，具體測試結果如下：

對登錄過程的測試用例表如表 5.2 所示。

表 5.2 登陸測試用例表

對文件下載過程的測試用例表如表 5.3 所示。

表 5.3 下載文件測試用例表

對文件舉報過程的測試用例表如表 5.4 所示。

表 5.4 舉報文件測試用例表

對密碼找回過程的測試用例表如表 5.5 所示。

表 5.5 密碼找回測試用例表

軟件開發中主要解決的問題

本系統是一個面向互聯網用戶的項目，本系統不僅要保證用戶的賬號安全不被盜用，還有保證本系統中內容的健康性，不散播低俗淫穢內容和用戶體驗的友好和及時性。另外本系統是一個分布式系統，相比以往的傳統系統有很多挑戰需要解決。

帳號登錄的安全性

因為系統的網絡連接采用基于 socket 的 http 協議，所以用戶的輸入的賬號密碼在網絡傳輸過程中存在被人劫持而暴露用戶密碼的風險。采用傳統方式 Web 頁面對前端用戶輸入的明文密碼進行加密，然后在網絡中傳輸加密后的密碼，服務器接收到加密碼后與數據庫中的加密的密碼進行比較來驗證用戶是否可以登錄，但是這種方式下盜號者完全不需要知道用戶的明文密碼是多少，只需要劫持到網絡傳輸中的加密后密碼，以后直接發加密密碼即可登錄系統。

因為以上原因，我們想到的是，用戶在登錄頁面，服務器根據用戶存在與服務器的 session 生成一個隨機碼保存在服務器中，同時把這個值傳給登錄頁面，登錄頁面獲取這個值后拼接到用戶的密碼明文后面進行加密后通過網絡傳輸到服務器，服務器接受到加密后密碼后，通過服務器存儲的隨機值與數據庫的原始密碼也拼接起來加密后進行比較來驗證用戶登錄，這樣就可以保證用戶每一次登錄時通過網絡發送的加密密碼不一樣，這樣就算被劫持，也無法被人使用。

搜索的精準與快速

如何人性化為用戶提供精準服務，采用全文檢索——垂直化搜索引擎主要針對系統內部的自有數據的檢索，通過對系統內部數據建立索引提供給用戶進行檢索。

它既能滿足用戶對全文檢索，模糊匹配的需求，解決數據庫 like 查詢效率低

下的問題，又能夠解決分布式環境下，由于采用分庫分表或使用 NoSQL 數據庫，導致無法進行多表關聯或者進行復雜查詢的問題。

lucene 將文檔中的詞作為關鍵字，建立詞與文檔的映射關系，通過對倒排索引的檢索，可以根據詞快速獲取包含這個詞的文檔列表。

能對句子或段落進行切割，從中取出包含固定語義的詞。

當輸入一個關鍵字進行搜索時，可能會命中許多文檔，搜索引擎給用戶的價

值就是快速地找到需要的文檔，根據排序算法，將相關度更大的內容排在前面，命中多次的文檔比命中一次的文檔有更高的相關性。

文件的處理

傳統系統用戶只能下載文件后才能查看文件內容，并不能讓用戶在文件下載

之前就能查看文件的內容，經常導致用戶下載文件后發現文件不是自己想要的，不僅影響用戶的體驗，同時也給網站帶來流量開銷和連接的壓力。為了實現文件預覽，我們需要將文件轉換為 swf 文件，實現 flash 播放達到預覽，在這里面我們不僅要考慮不用版本 office 文件處理問題，還要考慮如果文件里面有圖片如何準確提取出來把數據正確的存儲到 swf 文件中。在這我們通過 Java 代碼使用 OpenOffice 服務把文件轉換為 swf 文件，使用 FlexPaper，swfTools 在線預覽，從而達到用戶不需下載文件就能看到文件內容。

敏感詞過濾

由于本系統收錄的敏感詞庫中包含上萬個敏感詞，系統要對用戶輸入的文件信息進行處理，檢查用戶輸入的信息是否含有敏感詞，但是這里帶來一個效率問題，采用傳統思路，系統會對用戶輸入的一個文本數據比對上萬次，來驗證文本數據是否包含敏感詞庫的詞。顯然這是十分耗時的。NFA 是非確定性的狀態機，

DFA 是確定性的狀態機。確定性和非確定性的最大區 別就是：從一個狀態讀入一個字符，確定性的狀態機得到一個狀態，而非確定性的狀態機得到一個狀態的集合。如果我們把 NFA 的起始狀態 S 看成一個集合{S} 的話，對于一個狀態集合 S’，給定一個輸入，就可以用 NFA 計算出對應的狀態集合 T’。因此我們在構造 DFA 的時候，只需要把起始狀態對應到 S’，并且找 到所有可能在 NFA 同時出現的狀態集合，把這些集合都轉換成 DFA 的一個狀態，那么任務就完成了。因為 NFA 的狀態是有限的，所以 NFA 所有狀態的集合的 冪集的元素個數也是有限的，因此使用這個方法構造 DFA 是完全可能的。

網站高并發

一臺 Tomcat 服務器最大能支持的穩定并發數在 100—120 之間，因為本系統是面向互聯網用戶的，所以在同一時刻本系統面對的并發數遠遠大于 120，當實際并發數大于 Tomcat 服務器的支持數量后，會導致服務器因為壓力過大而無法及時處理其他請求，甚至導致服務器宕機。考慮到高并發訪問的情況，本系統使用 Nginx 服務器的負載均衡技術構建一個由多臺服務器組成的服務器集群，將來自客戶端的并發訪問請求分發到多臺服務器上處理，避免單一服務器出現負載壓力過大的情況。

為了保證當任意一臺或多臺服務器宕機，Nginx 服務器將請求提交給集群中其他任意一臺可用服務器能夠正確處理處理，本系統需要設置每一臺服務器不保存請求的狀態，這樣所有的服務器完全對等，服務器就可以成功處理其他服務器之前處理的請求了。

服務器集群下狀態共享

集群中所有的應用服務器都是無狀態的，但是在業務上系統總是有狀態的，因為系統需要記錄用戶當前的登錄狀態來確定用戶是否可以執行接下來的操作。 Web 應用中將這些多次請求使用的上下文對象稱作會話（session），單機情況下， session 可由部署在服務器上的 Web 容器管理。在使用負載均衡的集群環境中，請求由負載均衡服務器分發到集群上任意一臺應用服務器上，如何保證任意一臺應用服務器對每次請求依然能夠獲得正確的 session 是一個挑戰。

通過將一部分數據存儲在 cookie 中，來解決分布式環境下 session 操作同步的問題。但是這樣做的弊端有很多，比如 cookie 的安全性，cookie 存儲數據的大小的限制。

本系統的解決方案是將 session 統一存儲在緩存集群 memcache 上，這樣保證較高的讀，寫性能，再從安全性上看，利用緩存的失效機制，達到控制 session 有效期的的作業。

高并發下磁盤讀寫速度

系統在面對高并發的情況下，大量的讀，寫請求涌向數據庫，磁盤的處理速度與內存顯然不在一個量級，為了能提高系統對數據的讀取速度，通常將常用的數據放在內存中，這樣就避免了應用程序讀取硬盤而增加時間開銷。

memcache 是一個高性能的內存對象緩存系統，為了提高在內存中查找數據的速度，memcache 在內存中維護一張巨大的 HashTable，使得對數據查詢的時間復雜度降低到 O(1)。內存的空間總是有限的，當內存沒有更多的空間來存儲新數據時，memcache 會使用 LRU 算法，將最近不常訪問的數據淘汰掉，以騰出空間來存放新的數據。

分布式數據庫事務一致性

軟件系統對單個數據庫內部的多個 DML 操作都會組成一個局部事務，因為這些操作不會跨越多個事務性資源，軟件系統可以直接使用底層數據庫的事務支持；但是當軟件系統的功能操作涉及對多個數據庫的修改時，就面臨多個數據庫事務的一致性問題，這些數據庫的操作要么全部成功要么全部不成功，這就是分布式事務，分布式事務處理的對象是全局事務。

使用 JTA 編程就可以用一種與事務管理器無關的方式來開始，提交或回滾事務，Java EE 應用服務器通過 Java 事務服務來實現事務管理器。JTA 事務由 Java EE 事務管理器負責控制，它可以保證多個數據庫更新的一致性，通過 JTA 即可實現全局事務控制。

集群下 quartz 協調處理

在集群環境下，大家會碰到一直困擾的問題，即多個應用程序下如何用 quartz 協調處理自動化工作。比如現在有 A，B，C 三臺服務器同時作為集群服務器對外統一提供服務；A，B，C 三臺臺機器上各有一個 Quarzt，他們會按照即定的時間頻率自動執行各自的任務。這樣的架構其實有點像多線程，那多線程里就會存在“資源競爭”的問題，即可能產生臟讀，臟寫，由于三臺應用服務器里都有 Quarzt，因此會存在重復處理任務的現象。quartz 的任務實例化如數據庫，基于數據庫引擎及 High-Available 的策略（集群的一種策略）自動協調每個節點的 quartz，當任一一節點的 quartz 非正常關閉或出錯時，另幾個節點的 quartz 會自動啟動；這樣每臺作為集群點的應用程序上都可以布署 quartz；無需開發人員更改原已經實現的 quartz，使用 Spring 類反射的機制對原有程序作切面重構。

結論

去年 10 月我拿到論文題目，第一反應就是做一個類似百度文庫，面向所有互聯網用戶的系統，而不是一個內部系統。確定了目標之后，在后面的兩個月我遇到了很多挑戰，同時也開闊了我的視野。

我意識到僅僅對登錄的密碼進行加密并不能提高密碼的安全性，我也意識到當從操作一個數據庫到操作多個數據庫的挑戰，也意識到如何提高系統的并發能力，在系統集群的環境下會遇到哪些問題。在這個過程中我參考了很多架構設計的書，吸取了很多有豐富經驗的架構師的架構心得。

最后我明白了我們在開發一個系統時不要一開始就企圖去設計一個大型的網站。大型網站不是設計出來的，而是逐步根據不同的情況下發展演化出來的。每一種架構都沒有好壞之分，只存在是否在當前系統面臨的壓力下是最好的一種方式。就像阿里巴巴去 IOE，并不是 IOE 不適合阿里巴巴的系統，而是阿里巴巴的系統在發展到一定程度后，IOE 在很多業務情況下已經無法滿足阿里巴巴系統的需要了。

我們以后在開發軟件系統時不要為了技術而技術，不能因為某個技術很火就盲目的在系統中采用該技術，我們要記住網站技術是為了業務而存在的。

六、參考文獻

王志剛,江友華.MySQL 高效編程.北京:人民郵電出版社,2011.01:9-10.

苗澤.nginx 高性能 Web 服務器詳解[M].北京:電子工業出版社,2013.10.

陳康賢.大型分布式網站架構與設計實踐[M].北京:電子工業出版社,2014.09. [4]羅剛.解密搜索引擎技術實戰:lucene&java 精華版[M].第二版.北京:電子工業出版社,2014.01.李智慧.大型網站技術架構:核心原理與案例分析[M].北京:電子工業出版社,2013.09.劉瓊. Peer-to-Peer 文件共享系統的測量研究[D].北京:中國科學院軟件研究所,2011 年.倪高鵬.基于 Memcached 的緩存系統設計與實現[D].大連理工大學:丁鋒,2012 年. [8]王利萍.基于 Nginx 服務器集群負載均衡技術的研究與改進[D].山東大學:袁東風,2015年.李永春;丁華福.Lucene 中文分析器在書目搜索應用中的比較研究[J].業務研究,2014 年,4期:23-25.劉志鵬;衛晨;丁華福.基于 Quartz 與 Spring 的動態任務調度系統的設計與實現[J].計算機光盤軟件與應用,2014 年,13 期:44-45.李汝光;徐駿;丁華福.基于 JTA 的跨數據庫分布式事務的實現[N].常州工學院學報,2012 年,4 期.Charles A.Bell,Mats Kindahl,Lars Thalmann .MySQL High Availability[M].北京:東南大學出版社,2015.02.

附：開題報告正文

文件共享管理系統的設計與實現

文件共享管理系統研究背景在日常生活中，通常會遇到很多問題需要獲得相應的知識進行解決。比如想要寫一個勞動合同，但是不知道具體的格式，從而導致寫的合同不規范，影響工作效率。因此，我設計了能夠滿足這種需求的系統——文件共享管理系統。

通過文件共享管理系統，廣大用戶可以上傳自己的資料供其他需要的用戶進行搜索并下載作為參考模板。這樣可以極大的提高用戶在日常生活中解決問題所耗費的精力，提高用戶效率并為用戶提供專業的知識科普。

本課題的開發思想與解決方案

文件共享系統不僅能要夠存儲用戶文件，提供用戶搜索。在面對互聯網環境下我們要考慮的有如下幾點：

如何人性化為用戶提供精準服務，采用全文檢索，進行相關度排序，把相關度高的搜索結果排在上面，對存儲文本數據和用戶搜索關鍵詞進行智能分詞提高搜索命中率。

如何存儲海量的數據單獨的文件服務器存儲海量數據，緩解應用服務器的存儲壓力。

如何屏蔽不健康信息，使用 DFA 算法，根據系統收錄的敏感詞詞庫中智能屏蔽用戶上傳數據中含有的敏感詞。

如何避免必要的流量開銷，減少用戶不必要的下載次數。使用 FlexPaper， swfTools，OpenOffice 實現 office 文件的在線預覽，從而達到用戶不需下載文件就能看到文件內容。

如何提高系統的并發量而不宕機，一個應用服務器支持的穩定的并發連接是有限的，當客戶端的請求并發量超過了一個應用服務器提供的穩定連接后，該系統通過架構 nginx 服務器做反向代理來搭建應用服務器集群，這樣系統支持的穩定連接就隨著應用服務器的增加線性上升。

如何避免不必要的數據（硬盤）查詢次數，用戶對系統的操作就是對數據庫數據的獲取操作，傳統單機系統就是通過把一些常用，少變得數據放到緩存（內存）中，比起直接再從數據庫（硬盤）中獲取數據，以指數級提高了效率。但是在本應用服務器集群中，采用傳統方案會導致各自服務器中緩存的數據不一致，導致從緩存獲取數據的命中率降低。這時候我們使用 Redis 技術，搭建 Redis 集群，把應用服務器集群要存儲到緩存的數據存儲到 Redis 服務器中，以后獲取緩存數據從 Redis 服務器中獲取，這樣就保證了緩存數據的一致。

如何在集群服務下 session 共享，使得用戶在第一次連接 A 服務器后，第二次連接 B 服務器后，服務器還能夠記住用戶。這里同樣要把 session 存儲到 Redis 服務器中。

如何提高數據庫的執行效率，系統的業務不同，不同的表的查詢次數壓力不同，為了提高數據庫的執行效率，高效響應各種查詢語句，根據業務壓力，把不同的表劃分到不同的數據庫，從而分拆數據庫的壓力。

如何保證保證一個業務邏輯處理中對每個獨立數據庫的操作能夠同時回滾或執行成功保持一致性。該系統采用 JTA 分布式事務規范，可以保證數據庫的跨源操作的一致性問題。

如何保證管理員能夠準時執行某些功能保證系統的可控性，該系統在某些業務功能上使用任務調度框架定時進行處理。

如何保證用戶賬號安全性，該系統通過使用 javaMail 技術進行用戶密碼修改和找回密碼的驗證，通過第三方短信驗證接口在該賬號登陸系統時向用戶手機發送短信告知。

參考文獻

• 王志剛,江友華.MySQL 高效編程.北京:人民郵電出版社,2011.01:9-10.
• 苗澤.nginx 高性能 Web 服務器詳解[M].北京:電子工業出版社,2013.10.
• 陳康賢.大型分布式網站架構與設計實踐[M].北京:電子工業出版社,2014.09.
• 羅剛.解密搜索引擎技術實戰:lucene&java 精華版[M].第二版.北京:電子工業出版社,2014.01.
• 李智慧.大型網站技術架構:核心原理與案例分析[M].北京:電子工業出版社,2013.09.
• 劉瓊. Peer-to-Peer 文件共享系統的測量研究[D].北京:中國科學院軟件研究所,2011 年.
• 倪高鵬.基于 Memcached 的緩存系統設計與實現[D].大連理工大學:丁鋒,2012 年.
• 王利萍.基于 Nginx 服務器集群負載均衡技術的研究與改進[D].山東大學:袁東風,2015 年.
• 李永春;丁華福.Lucene 中文分析器在書目搜索應用中的比較研究[J].業務研究,2014 年,4 期:23-25.
• 劉志鵬;衛晨;丁華福.基于 Quartz 與 Spring 的動態任務調度系統的設計與實現[J].計算機光盤軟件與應用,2014 年,13 期:44-45.
• 李汝光;徐駿;丁華福.基于 JTA 的跨數據庫分布式事務的實現[N].常州工學院學報,2012 年;4 期.
• Charles A.Bell,Mats Kindahl,Lars Thalmann .MySQL High Availability[M].北京:東南大學出版社,2015.02.