摘 要： 通過對非集群環(huán)境與集群環(huán)境的比較分析，提出了一種適合集群環(huán)境的CMS最核心部分(發(fā)布、查看新聞，上傳、下載新聞附件)的架構(gòu)設(shè)計，它是對非集群環(huán)境架構(gòu)設(shè)計的改良。通過將文件存儲在數(shù)據(jù)庫服務器中，而應用服務器存儲文件的副本，從而解決了非集群環(huán)境的架構(gòu)移植到集群環(huán)境時導致文件無法正常更新的問題。最后通過引入緩存機制，使得這種架構(gòu)設(shè)計在性能方面有了較大的改進。
　　關(guān)鍵詞： 集群；內(nèi)容管理系統(tǒng)；新聞發(fā)布系統(tǒng)；架構(gòu)；緩存

?

　　CMS的應用相當廣泛，大到門戶或商業(yè)網(wǎng)站，小到個人網(wǎng)站。開源的CMS也非常多，如OpenCMS、Infoglue等。一個功能強大的CMS可以對內(nèi)容進行分類管理，定制內(nèi)容屬性，定制界面，增加、刪除、修改、查看內(nèi)容，增加、刪除、查看附件等。筆者曾經(jīng)開發(fā)過一個具備以上功能的CMS，此系統(tǒng)所使用的技術(shù)與Infoglue十分相似，都是基于J2EE技術(shù)構(gòu)建的。這個CMS先后被2個政府網(wǎng)站所使用，運行在單應用服務器環(huán)境，到目前為止一直運行穩(wěn)定。系統(tǒng)的核心部分，即內(nèi)容管理和附件管理部分還被集成到一個職稱評審系統(tǒng)中，起初在測試環(huán)境(單應用服務器環(huán)境)下運行還很穩(wěn)定，但被部署到生產(chǎn)環(huán)境(集群環(huán)境)時就出現(xiàn)了很多問題，因此需要對系統(tǒng)的架構(gòu)進行重新設(shè)計。
1 非集群環(huán)境下CMS的核心架構(gòu)
　　非集群環(huán)境系統(tǒng)結(jié)構(gòu)如圖1所示。這是1個非常典型的單服務器環(huán)境，由1臺Web服務器、1臺應用服務器和1臺數(shù)據(jù)庫服務器組成。CMS主要被部署到應用服務器上。

?

　　一條新聞通常由標題、作者、更新日期、正文以及附件等部分組成。一種設(shè)計是將所有這些信息都保存到數(shù)據(jù)庫中，當用戶查看新聞時，需要從數(shù)據(jù)庫中讀取新聞的所有信息。這種設(shè)計有2個非常大的缺點：(1)對于新聞正文、附件等大數(shù)據(jù)量的信息(正文長度通常在幾KB到幾十KB之間，附件更大)，在傳輸?shù)接脩魹g覽器的過程中必須從數(shù)據(jù)庫服務器傳輸?shù)綉梅掌?，然后再傳輸?shù)絎eb服務器，最后傳輸?shù)綖g覽器。其傳輸路徑長，經(jīng)過的節(jié)點多，當用戶訪問量大的時候，響應用戶的時間長。(2)不利于建立全文檢索。由于正文或附件等是以字節(jié)流的形式存儲在數(shù)據(jù)庫服務器中，而數(shù)據(jù)庫并不提供針對字節(jié)流數(shù)據(jù)的搜索功能，因此，幾乎不可能為正文或附件建立全文檢索。
　　一種改進的設(shè)計是將新聞正文和附件以文件形式存儲在應用服務器的磁盤中，而新聞的其他信息則存儲在數(shù)據(jù)庫里。這樣，用戶在查看新聞或者下載附件時，獲取正文、附件這些信息就不需要進行數(shù)據(jù)庫操作，而直接從應用服務器磁盤中讀取文件，從而減少了應用服務器與數(shù)據(jù)庫服務器之間的通信量，提高了系統(tǒng)的響應速度。此外，還可以對正文和附件文件建立全文檢索。這種設(shè)計也有缺點，由于存儲在應用服務器的可靠性不如存儲在數(shù)據(jù)庫服務器高，因此，需要經(jīng)常備份應用服務器中存儲的正文、附件等文件。相比于對系統(tǒng)性能的提高和提供全文檢索功能來說，代價還是比較小的，因此筆者開發(fā)的CMS采用第二種設(shè)計。
2?系統(tǒng)部署在集群環(huán)境下時遇到的問題
　　職稱評審系統(tǒng)在正式使用時需要部署在集群環(huán)境中，集群環(huán)境的系統(tǒng)結(jié)構(gòu)如圖2所示。

　　集群環(huán)境通常有多臺Web服務器、多臺應用服務器和多臺數(shù)據(jù)庫服務器。集群環(huán)境能夠提供更高的性能、更可靠的服務。CMS主要部署在應用服務器集群上，每臺應用服務器上都有一個獨立的CMS。假設(shè)如圖3所示情形，設(shè)A、B兩臺應用服務器的時間是同步的。
????????

　　a時刻：管理員請求添加新聞，應用服務器集群中只會有一臺服務器提供服務，即應用服務器A。此時，應用服務器A中就保存了新聞的正文文件、附件文件，而數(shù)據(jù)庫服務器中保存了新聞的標題、作者和更新時間等。
　　b時刻：用戶請求查看新添加的新聞，請求被路由到應用服務器B，此時，可以從數(shù)據(jù)庫中讀取新聞的標題、作者和更新時間等信息，但是新聞的正文和附件卻無法獲取，因為正文和附件存儲在應用服務器A上，而集群環(huán)境下各臺應用服務器是相對獨立的，A服務器的改變并不會影響到B服務器。為此，需重新設(shè)計系統(tǒng)的結(jié)構(gòu)，以適應集群環(huán)境。
3?系統(tǒng)的重新設(shè)計
　　系統(tǒng)在集群環(huán)境下遇到的問題主要是由于正文和附件只保存在應用服務器上，而各個應用服務器之間又是互相獨立的，不能得到同步更新。為解決這個問題，決定將正文和附件保存到應用服務器上的同時，保存到數(shù)據(jù)庫服務器上，在數(shù)據(jù)庫中還必須存儲應用服務器上正文和附件的文件更新時間。當用戶請求查看新聞正文或下載附件時，系統(tǒng)先在應用服務器上查找該文件，如果文件不存在，則到數(shù)據(jù)庫服務器上查找，并將文件從數(shù)據(jù)庫服務器導入到應用服務器上，然后再將應用服務器上的文件傳輸?shù)綖g覽器；如果文件存在應用服務器上，此時是否可以直接將應用服務器上的文件傳輸?shù)綖g覽器？這是一個需要進一步討論的問題。假設(shè)存在如圖4所示一種情況，設(shè)A、B兩臺應用服務器的時間是同步的。

?

?

　　a時刻：管理員請求添加正文，此時正文文件被保存到應用服務器A上，同時保存到數(shù)據(jù)庫服務器上，數(shù)據(jù)庫中記錄的正文文件更新時間是a。
　　b時刻：用戶請求查看管理員在a時刻添加的正文，b必定大于a。用戶被路由到應用服務器B上，由于B上并不存在正文文件，于是系統(tǒng)到數(shù)據(jù)庫服務器上查找正文，并將正文從數(shù)據(jù)庫服務器傳輸?shù)綉梅掌鰾上，保存成正文文件。此時，應用服務器B上就記錄了正文文件的更新時間b。
　　c時刻：管理員請求修改正文，假設(shè)c>b。管理員被路由到應用服務器A上，此時應用服務器A上修改了正文文件，同時數(shù)據(jù)庫服務器上修改正文文件的更新時間為c。
　　d時刻：用戶請求查看正文，假設(shè)d>c。用戶被路由到應用服務器B上，此時B上已經(jīng)存在正文文件。如果直接將這個正文文件傳輸給用戶，則用戶看到的是管理員在a時刻添加的正文，而管理員在c時刻修改了正文，因此用戶看到的并不是最新的正文。
　　解決方案如下：如果系統(tǒng)能夠在應用服務器上查找到正文文件，則需要將正文文件的更新時間與數(shù)據(jù)庫中記錄的正文更新時間進行比較，如果前者大于等于后者，則證明應用服務器中的正文文件是最新的，可以直接傳輸給用戶；否則，證明在應用服務器載入正文文件之后管理員更新了正文，應用服務器中的正文文件不是最新的，如上例中b