摘 要： 通過對非集群環境與集群環境的比較分析，提出了一種適合集群環境的CMS最核心部分(發布、查看新聞，上傳、下載新聞附件)的架構設計，它是對非集群環境架構設計的改良。通過將文件存儲在數據庫服務器中，而應用服務器存儲文件的副本，從而解決了非集群環境的架構移植到集群環境時導致文件無法正常更新的問題。最后通過引入緩存機制，使得這種架構設計在性能方面有了較大的改進。
關鍵詞： 集群；內容管理系統；新聞發布系統；架構；緩存
?
CMS的應用相當廣泛，大到門戶或商業網站，小到個人網站。開源的CMS也非常多，如OpenCMS、Infoglue等。一個功能強大的CMS可以對內容進行分類管理，定制內容屬性，定制界面，增加、刪除、修改、查看內容，增加、刪除、查看附件等。筆者曾經開發過一個具備以上功能的CMS，此系統所使用的技術與Infoglue十分相似，都是基于J2EE技術構建的。這個CMS先后被2個政府網站所使用，運行在單應用服務器環境，到目前為止一直運行穩定。系統的核心部分，即內容管理和附件管理部分還被集成到一個職稱評審系統中，起初在測試環境(單應用服務器環境)下運行還很穩定，但被部署到生產環境(集群環境)時就出現了很多問題，因此需要對系統的架構進行重新設計。
1 非集群環境下CMS的核心架構
非集群環境系統結構如圖1所示。這是1個非常典型的單服務器環境，由1臺Web服務器、1臺應用服務器和1臺數據庫服務器組成。CMS主要被部署到應用服務器上。
?
一條新聞通常由標題、作者、更新日期、正文以及附件等部分組成。一種設計是將所有這些信息都保存到數據庫中，當用戶查看新聞時，需要從數據庫中讀取新聞的所有信息。這種設計有2個非常大的缺點：(1)對于新聞正文、附件等大數據量的信息(正文長度通常在幾KB到幾十KB之間，附件更大)，在傳輸到用戶瀏覽器的過程中必須從數據庫服務器傳輸到應用服務器，然后再傳輸到Web服務器，最后傳輸到瀏覽器。其傳輸路徑長，經過的節點多，當用戶訪問量大的時候，響應用戶的時間長。(2)不利于建立全文檢索。由于正文或附件等是以字節流的形式存儲在數據庫服務器中，而數據庫并不提供針對字節流數據的搜索功能，因此，幾乎不可能為正文或附件建立全文檢索。
一種改進的設計是將新聞正文和附件以文件形式存儲在應用服務器的磁盤中，而新聞的其他信息則存儲在數據庫里。這樣，用戶在查看新聞或者下載附件時，獲取正文、附件這些信息就不需要進行數據庫操作，而直接從應用服務器磁盤中讀取文件，從而減少了應用服務器與數據庫服務器之間的通信量，提高了系統的響應速度。此外，還可以對正文和附件文件建立全文檢索。這種設計也有缺點，由于存儲在應用服務器的可靠性不如存儲在數據庫服務器高，因此，需要經常備份應用服務器中存儲的正文、附件等文件。相比于對系統性能的提高和提供全文檢索功能來說，代價還是比較小的，因此筆者開發的CMS采用第二種設計。
2?系統部署在集群環境下時遇到的問題
職稱評審系統在正式使用時需要部署在集群環境中，集群環境的系統結構如圖2所示。
集群環境通常有多臺Web服務器、多臺應用服務器和多臺數據庫服務器。集群環境能夠提供更高的性能、更可靠的服務。CMS主要部署在應用服務器集群上，每臺應用服務器上都有一個獨立的CMS。假設如圖3所示情形，設A、B兩臺應用服務器的時間是同步的。
????????
?
a時刻：管理員請求添加新聞，應用服務器集群中只會有一臺服務器提供服務，即應用服務器A。此時，應用服務器A中就保存了新聞的正文文件、附件文件，而數據庫服務器中保存了新聞的標題、作者和更新時間等。
b時刻：用戶請求查看新添加的新聞，請求被路由到應用服務器B，此時，可以從數據庫中讀取新聞的標題、作者和更新時間等信息，但是新聞的正文和附件卻無法獲取，因為正文和附件存儲在應用服務器A上，而集群環境下各臺應用服務器是相對獨立的，A服務器的改變并不會影響到B服務器。為此，需重新設計系統的結構，以適應集群環境。
3?系統的重新設計
系統在集群環境下遇到的問題主要是由于正文和附件只保存在應用服務器上，而各個應用服務器之間又是互相獨立的，不能得到同步更新。為解決這個問題，決定將正文和附件保存到應用服務器上的同時，保存到數據庫服務器上，在數據庫中還必須存儲應用服務器上正文和附件的文件更新時間。當用戶請求查看新聞正文或下載附件時，系統先在應用服務器上查找該文件，如果文件不存在，則到數據庫服務器上查找，并將文件從數據庫服務器導入到應用服務器上，然后再將應用服務器上的文件傳輸到瀏覽器；如果文件存在應用服務器上，此時是否可以直接將應用服務器上的文件傳輸到瀏覽器？這是一個需要進一步討論的問題。假設存在如圖4所示一種情況，設A、B兩臺應用服務器的時間是同步的。
?
?
a時刻：管理員請求添加正文，此時正文文件被保存到應用服務器A上，同時保存到數據庫服務器上，數據庫中記錄的正文文件更新時間是a。
b時刻：用戶請求查看管理員在a時刻添加的正文，b必定大于a。用戶被路由到應用服務器B上，由于B上并不存在正文文件，于是系統到數據庫服務器上查找正文，并將正文從數據庫服務器傳輸到應用服務器B上，保存成正文文件。此時，應用服務器B上就記錄了正文文件的更新時間b。
c時刻：管理員請求修改正文，假設c>b。管理員被路由到應用服務器A上，此時應用服務器A上修改了正文文件，同時數據庫服務器上修改正文文件的更新時間為c。
d時刻：用戶請求查看正文，假設d>c。用戶被路由到應用服務器B上，此時B上已經存在正文文件。如果直接將這個正文文件傳輸給用戶，則用戶看到的是管理員在a時刻添加的正文，而管理員在c時刻修改了正文，因此用戶看到的并不是最新的正文。
解決方案如下：如果系統能夠在應用服務器上查找到正文文件，則需要將正文文件的更新時間與數據庫中記錄的正文更新時間進行比較，如果前者大于等于后者，則證明應用服務器中的正文文件是最新的，可以直接傳輸給用戶；否則，證明在應用服務器載入正文文件之后管理員更新了正文，應用服務器中的正文文件不是最新的，如上例中b
4?系統性能的改進
系統經過重新設計之后，已經可以在集群環境下正常地運行。但是，當用戶請求查看新聞正文或請求下載附件時，假定系統能夠在應用服務器上直接命中正文文件或附件文件(絕大多數情況下也正是如此)，系統還需要比較文件在應用服務器上的更新時間和數據庫服務器中記錄的文件更新時間，這樣就需要一次數據庫查詢操作。用戶每查看一次新聞正文或請求下載附件就需要查詢一次數據庫，增加了數據庫的負擔。為了減少數據庫訪問次數，可以為系統添加緩存組件，用于緩存數據庫中的數據。對于CMS來說，緩存中存儲的就是新聞對象和附件對象，前者包含標題、作者和正文更新時間等屬性，后者包含文件名和文件更新時間等屬性。緩存組件被添加到系統后，當用戶請求查看新聞正文或下載附件時，緩存組件的活動如圖6所示。
????????
當需要比較文件在應用服務器上的更新時間與數據庫中記錄的文件更新時間時，就向緩存組件請求新聞對象或附件對象。圖6所示為請求新聞對象時緩存組件的活動，請求附件對象時緩存組件的活動與此類似。
使用緩存容易產生臟數據。為了保證緩存中的對象能夠得到更新，可以設定緩存的過期時間，例如5 min。經過這番改進，能夠有效地減少數據庫的訪問次數，減輕數據庫的負擔，提高系統的響應速度。
本文所介紹的CMS核心架構設計可以用于構建大型的門戶或商業網站，能夠在集群環境下穩定運行。當用戶訪問量增加時，并不會明顯增加數據庫服務器的負擔，系統的負載能力主要和應用服務器集群中的服務器數量有關。由于系統的所有數據都存儲在數據庫服務器中，應用服務器中的文件只不過是數據庫中數據的副本，因此數據的可靠性和安全性都有了很大的提高，同時，還可以對應用服務器中的文件建立全文檢索以提供更強大的搜索功能。系統穩定運行的一個前提是應用服務器集群中的各個服務器的時間必須同步，目前已經有技術可以保證這一需求。
參考文獻
[1]?ARLOW J, NEUSTADT I.UML 2 and the unified process[M].Addison-Wesley Professional, 2005.
[2]?孫衛琴.精通Hibernate—Java對象持久化技術詳解[M].北京：電子工業出版社，2005.
[3]?吳少剛，陳曉玲.J2EE應用服務器集群性能研究[J].計算機工程與設計，2007，28(18)：4410-4412.
[4]?叢林，楊揚，李曉東，等.基于企業服務總線的內容管理系統的研究應用[J].計算機應用研究,2007(1):255-257.
[5]?夏純中.輕量級企業內容管理系統的設計與實現[J].計算機工程與設計，2007，28(17)：4233-4236.